AgentRoom

Overview

Deja lo que una organización ofrece —productos, servicios, soporte, información— en un formato que los agentes de IA entienden, y publica su agente donde puedan encontrarlo. No es solo para tiendas: comercio, servicios, software e instituciones. Es complemento de las superficies, nunca competidor: no hay app de consumidor ni marca frente a la persona.

Landing

agentroom.io

Bilingüe es/en, tema claro y oscuro. Indexable a propósito.

Análisis gratis

/analiza

Informe de brechas: 24 puntos, 3 capas, con evidencia.

Tarifas

/tarifas

Paga el comercio, y solo el comercio. En ARU, aún TBD.

Qué es, en una línea

El análisis te muestra qué ve un asistente de IA cuando busca lo que ofreces. Si hay brechas, armamos tu agente —lo que el motor llama gemelo digital— y lo publicamos donde los asistentes lo encuentren. Los asistentes de las personas preguntan, tu agente responde, y cuando corresponde, transacciona.

Dónde vive cada cosa

Pieza	Ubicación
Landing, motor, funciones y CLI (un solo repo)	`Proyectos/AgentRoom/01-agentroom-web/`
Repo remoto	`junngla-tech/agentroom`
Proyecto en Vercel	`agentroom-web`
Reglas del repo (glosario, reglas duras)	`01-agentroom-web/CLAUDE.md`
Repo original de VADO (intacto)	`Proyectos/Comprable/01-comprable-web/` → vado.junngla.com

AgentRoom absorbió a VADO el 20-ago-2026. Un gemelo digital es un agente en AgentRoom. Este repo es ahora uno solo —landing, motor, funciones y CLI—, copiado del de VADO, que quedó intacto y sigue sirviendo vado.junngla.com. El cutover es una decisión aparte (AR-01). Por eso la historia técnica del motor (jul–ago) vive en la bitácora de VADO, y aquí empieza el 20-ago.

Glosario — una cosa, un nombre

Término	Qué es	Regla
asistente de IA	El de la persona: donde pregunta. Ajeno a nosotros.	Nunca llamarlo agente.
agente	El de la organización, el que se publica en AgentRoom.	Nombre público de lo que el motor llama gemelo.
gemelo digital	El mismo objeto, nombre interno del motor.	Prohibido en copy visible.
organización	El cliente. Paraguas de los cuatro perfiles.	«Tienda» solo en ejemplos de comercio.
catálogo	Uno de los objetos publicables, entre otros.	Nunca como si fuera el único.

Overview

Modelo y niveles

Desde el 23-ago el camino se recorre por industria, y el precio sube por niveles. Dos son gratis; desde el tercero se paga en ARU (Agent Room Unit). El comprador nunca paga, y el asistente tampoco: paga el comercio, porque el comercio recibe la venta.

Tres industrias, un mismo camino

El análisis y quedar legible van para las tres. Lo que cambia es qué significa el catálogo del nivel 02 y los ejemplos individualizados de 03 y 04.

Industria	Qué es	Qué es su catálogo
Retail	Tiene checkout: carro y posibilidad de comprar.	Productos, con precio y stock.
Servicios	Presta un servicio, tangible o intangible.	Servicios disponibles — sin stock, necesariamente.
Sistemas	Da software: licencias o servicios relacionados.	Servicios y licencias — sin stock.

Cuatro niveles

Analizamos tu sitio

Informe de brechas con evidencia. El gancho de adquisición. Es tuyo aunque nunca sigas.

Gratis

Armamos tu gemelo y quedas legible

Info, políticas, procedimientos y catálogo, en formato que los agentes leen. Todo genérico, aún sin agente que responda a una persona.

Gratis · 3 meses

Tu agente responde por cada persona

Agente publicado en AgentRoom, respuesta individualizada. Tráfico de información, no transacción. Aquí parten Handshake, auditoría, monitoreo, reportes, sala cerrada y control de fraude.

Con tarifa · ARU

Tu agente hace transacciones

Compras, pagos, reservas, tickets, documentos, visitas. Verificar antes de comprometer, siempre.

Con tarifa · ARU

La frontera del cobro vive en tres archivos que hay que mantener en sync: src/data/how-it-works.ts (industrias y niveles), src/components/LineaTarifa.tsx (el corte dibujado) y src/config/pricing.ts (freeTier.notes). Gratis el 01 y el 02; la tarifa en ARU empieza en el 03, cuando hay un agente que responde por cada persona.

Reglas de precio que no se rompen

Nunca hardcodear una tarifa en un componente: todo sale de pricing.ts vía formatARU(). Sin publicar = null = TBD.
Paga el comercio, y solo el comercio. La tabla de pricing tiene una columna. El modelo bilateral C-ARU / P-ARU quedó archivado por si vuelve el caso B2B.
Mostrar sí, prometer no. El catálogo vive en la Room, pero precio y stock se verifican contra el comercio antes de cobrar. Nunca publicar un precio inferido.

Overview

Las cinco etapas

El producto se recorre en cinco etapas, y cada una lleva su estado real a la vista (StageStatus en types/models.ts). Nada se rotula «disponible» si no está en producción, y una etapa «parcial» está obligada a decir qué parte funciona y cuál no.

Etapa	Qué resuelve
Ver	Que un asistente entienda qué ofreces. Es la capa de legibilidad del análisis.
Existir	Quedar publicado y encontrable: JSON-LD, feed, `llms.txt`, servidor MCP.
Responder	El agente contesta por cada persona. Aquí empieza la tarifa (nivel 03).
Operar	Transacciones: comprar, pagar, reservar, resolver (nivel 04).
Colaborar	Agentes que se coordinan entre organizaciones. El horizonte.

Énfasis por inversión, no por color. Los colores de marca significan lados de una conversación: ámbar --color-customer = quien pregunta (persona y asistente), azul --color-provider = el comercio. Para distinguir estados —disponible, parcial, en construcción— se usa peso, opacidad o borde, nunca los colores de marca.

Técnico

Arquitectura

Un solo repo Next.js con la landing, el motor heredado de VADO, las funciones y el CLI. La fusión del 20-ago se hizo sin reescribir lo que ya corría en producción.

Pieza	Dónde y cómo
Landing (secciones, copy, config)	`src/` — el copy vive en `data/` y `config/`; `app/page.tsx` solo compone.
Motor de análisis y gemelo	`motor/`
Funciones (route handlers)	`src/app/api/`
CLI	`cli/`

Decisiones que la definen

Los handlers no se reescribieron. Los nueve venían corriendo con la firma (req, res) de Vercel; viven en motor/handlers/ y src/lib/handler-vercel.ts los adapta a route handlers. Reescribir 900 líneas probadas era riesgo innecesario.
Dos tsconfig a propósito: tsconfig.json valida la web, tsconfig.node.json valida motor y CLI. npm run typecheck corre los dos.
La mudanza es por configuración, no por código: motor/marca.ts lee AGENTROOM_BASE, AGENTROOM_RUTA_D, AGENTROOM_NOMBRE y AGENTROOM_SLUG. Sin variables, todo responde como antes.
/apps/vado se sirve para siempre. Hay Puertas D desplegadas en dominios de clientes apuntando ahí. Las nuevas usan /apps/agentroom. Nunca renombrar la vieja.

Dominio: agentroom.io desde el 21-ago-2026. agentroom.junngla.com redirige con 308 permanente y no se apaga: hay enlaces publicados. La dirección vive en AGENTROOM_BASE, así que mudarse de nuevo no exige tocar código.

Técnico

Auditoría As-Is / To-Be

Corrida con el skill SuperArqDev el 20-ago-2026 sobre el commit inicial del repo. El diagnóstico completo —con diagramas C4, secuencia y modelo de datos— vive en bbp.agentroom.io/arquitectura. Acá va el resumen.

Score

68/100

SQALE C. Baja por ausencia de pruebas y CI, no por la calidad del código.

Cobertura de pruebas

Cero tests sobre un motor que ya corre en producción.

Piezas por construir

14 son bloqueantes para la promesa de la landing.

El diagnóstico en una línea: un motor maduro con una casa a medio construir. Lo que analiza y publica está en producción (~6.400 líneas documentadas, con ADRs dentro del código); lo que transacciona no existe todavía, y nada se puede construir con seguridad hasta que exista la red de pruebas. Por eso la Fase 0 no construye producto.

La regla que ordena todo el plan: verificar precio y stock en vivo antes de crear cualquier orden (P9 antes que P11). Prometer desde una copia es vender lo que no existe — y con agentes eso escala más rápido que con personas.

Hallazgos

Sev.	Hallazgo
Alta H1	Dependencias vulnerables. 4 high + 1 moderate. `next` se arregla sin salto mayor (16.2.12 → 16.3.1).
Alta H2	Cero pruebas automatizadas. Ni un test, incluidos los 16 checks que producen el puntaje que se le vende al comercio.
Alta H3	Sin CI/CD. No hay `.github/`; el deploy es manual, sin gate de typecheck, lint ni auditoría.
Media H4	Fixtures fuera de control de versiones. 78 MB de capturas reales que serían el insumo para escribir los tests de H2 sin tocar la red.
Media H5	El motor estuvo en producción sin repositorio. Corregido el 20-ago con el commit inicial.
Baja H6	Deuda de nombres tras la absorción. Quedan referencias a la marca anterior; ojo con el user-agent `VadoBot/1.0`, puede estar en listas de permitidos.

Lo revisado a mano y limpio: guardas de destino y presupuesto (SSRF tratado como superficie hostil, ADR-0016), corte de servicio (410 verificado en vivo, ADR-0008), promociones emitidas en servidor, y cero secretos (gitleaks limpio, fuente única en Infisical). Herramientas ausentes en el equipo (semgrep, trivy, checkov): la revisión de inyección fue manual sobre los nueve puntos de entrada, sin afirmar exhaustividad.

Plan de migración por fases

Fase	Qué
0 · 30d	La red de seguridad. No construye producto: hace que construir sea seguro. Next a 16.3.1, tests de los 16 checks con las fixtures reales, CI con typecheck de ambos `tsconfig`. (Cierra H1, H2, H3.)
1 · 60d	Que la adhesión exista. Cuenta del comercio (P1), ingesta continua (P2), frescura con vencimiento (P3), declaración `.well-known` en el dominio del comercio (P7) y métricas de distribución (P18).
2 · 90d	La caja. Registro de agentes (P5), postventa y atención (P16, P15) —la demanda que ya existe—, vínculo cliente-tienda (P14), recibo verificable (P13) y metering (P19), para que la tabla de precios deje de ser decorativa.
3 · 6-12m	La transacción. Verificación en vivo (P9) y reserva (P10), en ese orden; checkout y orden (P11); persistencia real (P17); MCP ampliado y adaptadores (P6, P8).

Estrategia 7R: el motor y el gemelo se retienen (funcionan y están documentados); las nueve funciones se replataformaron con un adaptador en vez de reescribirlas; la persistencia se refactoriza por Branch by Abstraction (almacen.ts ya es la interfaz); las superficies crecen por Strangler Fig (/apps/agentroom junto a /apps/vado); y los pagos se recompran —se integran, no se construyen— para no entrar al perímetro regulado.

Técnico

El análisis

El informe de brechas mide 24 puntos en 3 capas. Cada capa pregunta algo distinto y numera sus puntos con su propia letra. La tercera capa se agregó el 22-ago: las dos primeras solo sabían preguntarle a una tienda, y a un banco o un ministerio les aplicaban cuatro puntos de dieciséis. El instrumento estaba mal, no los sitios.

Capa	Pregunta	Códigos
Legibilidad	¿Puede un asistente entender qué vendes?	L01–L09
Transaccionabilidad	¿Puede un agente cerrar la compra?	T01–T08
Resolución	¿Puede un agente resolver algo contigo?	R01–R08

Puntaje siempre con denominador. Se calcula solo sobre los puntos aplicables y nunca se publica sin decir sobre cuántos. Ningún hallazgo existe sin evidencia citable, y un sitio que no deja entrar a los rastreadores sale sin evaluar, no reprobado.

Técnico

Señales de IA

Son las mismas señales que el motor le exige a los sitios que audita. Si se caen, el producto se contradice: un producto que vende ser legible para las IA no puede estar ciego para ellas.

robots.txt con los trece rastreadores de IA nombrados.
sitemap.xml al día.
JSON-LD en las seis páginas.
/llms.txt.
/.well-known/agent-card.json.

El sitio es indexable y así debe quedarse. Estuvo con noindex desde el primer día «hasta que sea público» y nadie lo sacó. Si alguna vez hay que volver a cerrarlo, que sea una decisión con fecha de término.

Técnico

Backlog técnico

El trabajo de ingeniería que separa lo que el motor ya hace de lo que la landing promete. Son las 21 piezas del catastro de SuperArqDev —con su estado real y la fase en que tocan— más la deuda que dejaron los hallazgos. El backlog de Gestión contiene las decisiones; este contiene la construcción.

Piezas

15 no existen todavía y 6 están a medias.

Bloqueantes

Para la promesa de la landing, según la auditoría. Eje distinto al de existencia: una pieza a medias también puede bloquear.

Sin fase asignada

P4 no aparece en ninguna de las cuatro fases del plan.

Cómo se lee. No existe no hay código todavía. A medias hay base, falta cerrarla. La columna Fase es la del plan de migración, y Por qué sigue ahí es la razón de la postergación, para no rediscutirla desde cero. Al cerrar una línea no se borra: se mueve a la bitácora.

El orden que no se negocia: P21 y P20 antes que cualquier pieza de producto —con 0% de cobertura nada se construye seguro—, y P9 antes que P11: verificar precio y stock en vivo antes de crear una orden. Prometer desde una copia es vender lo que no existe, y con agentes eso escala más rápido que con personas.

Fase 0 · La red de seguridad

ID	Pieza	Estado	Por qué sigue ahí
P21	Pruebas. Tests de los checks del análisis con las fixtures reales. Hallazgo H2.	No existe	El motor lleva meses en producción sin una sola prueba, incluidos los checks que producen el puntaje que se le vende al comercio. No construye producto, pero desbloquea todo lo que sí.
P20	CI/CD. Typecheck de ambos `tsconfig`, lint y auditoría como gate. Hallazgo H3.	No existe	No hay `.github/`: el deploy es manual y nada impide publicar algo que no compila. Se postergó porque el repo nació recién el 20-ago.
D-01	Dependencias vulnerables. 4 high + 1 moderate; `next` 16.2.12 → 16.3.1. Hallazgo H1.	No existe	Es la línea más barata del plan —no hay salto mayor de versión— y sigue abierta solo porque no hay CI que la haga fallar.

Ojo con esta línea: la Fase 0 se escribió el 20-ago hablando de «los 16 checks», pero el 22-ago el análisis pasó a 24 puntos en 3 capas (L01–L09 · T01–T08 · R01–R08). El alcance real de P21 es 24, no 16. El plan de la auditoría quedó congelado en la foto del día que se corrió.

Fase 1 · Que la adhesión exista

ID	Pieza	Estado	Por qué sigue ahí
P1	Cuenta y sesión del comercio.	No existe	Hoy no hay a quién pertenece un gemelo. Es la primera pieza del dominio Comercio y bloquea todo lo demás de la fase.
P2	Ingesta continua. Sincronización, webhooks y conectores de plataforma.	A medias	La captura existe pero es puntual. Se parte con un conector de plataforma, no cinco: el objetivo es probar el flujo continuo, no cubrir el mercado.
P3	Frescura con vencimiento. TTL y marcar lo viejo como no publicable.	A medias	La procedencia ya se registra; falta que caduque. Es la condición para poder prometer algo después: sin vencimiento, publicar dato viejo es indistinguible de publicar dato bueno.
P7	Declaración estándar `.well-known` en el dominio del comercio.	A medias	La pieza de distribución: convierte cada comercio adherido en un nodo en su propio dominio. Va en la Fase 1 porque es lo que hace que adherirse rinda sin esperar la transacción.
P18	Métricas de distribución. Crawlers, citas y conexiones MCP.	No existe	Son las tres señales que prueban la tesis del producto. Sin ellas la Fase 1 se entrega a ciegas: no hay cómo saber si adherirse sirvió.

Fase 2 · La caja

ID	Pieza	Estado	Por qué sigue ahí
P5	Registro de agentes.	No existe	Hoy se publica un catálogo, no agentes —y el agente es justamente lo que se le va a vender al comercio desde el nivel 03. Sin esto la tarifa por ARU no tiene objeto que contar.
P16	Postventa. Estado, devoluciones y reclamos.	No existe	Es la demanda que sí existe hoy, antes que la compra: la gente le pregunta al asistente por un pedido que ya hizo. Entra en la Fase 2 y no en la 3 por eso.
P15	Atención sobre producto.	A medias	Cubierta en parte por el MCP de catálogo. Falta el tramo que necesita contexto del cliente, y ese depende de P14.
P14	Vínculo cliente-tienda.	No existe	Condición de P16: sin saber quién es el cliente para esa tienda no existe el escenario de postventa. Se postergó a la 2 porque antes no había a quién vincular (P1).
P13	Recibo verificable. Qué se ofreció, qué se acordó y qué se cobró.	No existe	El activo defendible del producto. Nace en la Fase 2 aunque la compra llegue en la 3: lo que sostiene es el registro de lo acordado, y eso ya aplica a la postventa.
P19	Metering y billing.	No existe	La tabla de precios de la landing no tiene nada detrás. Cruza con AR-02: medir sin tarifa fijada no cobra, y fijar tarifa sin medir tampoco.

Fase 3 · La transacción

ID	Pieza	Estado	Por qué sigue ahí
P9	Verificación en vivo de precio y stock.	No existe	La más crítica de las 21. Sin esto se promete desde una copia y se sobrevende. Es la que manda el orden de toda la fase.
P10	Reserva. Sostiene el ítem mientras se confirma la compra.	No existe	Va inmediatamente después de P9 y antes del checkout: verificar sin reservar deja una ventana en la que el ítem se puede vender dos veces.
P11	CheckoutSession y Order.	No existe	No existe el objeto compra. Se postergó a propósito detrás de P9 y P10: crear órdenes sin verificación en vivo es la falla que el producto promete evitar.
P17	Persistencia real. Hoy Blob.	A medias	ADR-0018 pospuso el esquema a propósito mientras el objeto de dominio podía cambiar. P9–P14 lo van a exigir, y recién ahí se justifica pagarlo. Se refactoriza por Branch by Abstraction: `almacen.ts` ya es la interfaz.
P6	MCP ampliado. Pedido, postventa y disponibilidad en vivo.	A medias	Hoy solo expone catálogo. Cada verbo nuevo depende de que exista la pieza detrás: ampliar el MCP antes que P9–P11 sería publicar una interfaz vacía.
P8	Adaptadores por superficie. Un conector por protocolo, sin tocar el núcleo.	No existe	Multiplicar superficies antes de tener qué ofrecer en ellas multiplica el mantenimiento, no la distribución. Las superficies crecen por Strangler Fig.
P12	Mandato del consumidor. La autorización con límites.	No existe	Territorio de Pepe, no de AgentRoom. Puede que no se construya nunca acá: AgentRoom es el lado del comercio. Queda anotada para que la decisión sea explícita y no un olvido.

Sin fase asignada

ID	Pieza	Estado	Por qué sigue ahí
P4	Agent Room Manager. La administración conversacional que la landing promete.	No existe	Hueco del plan: es la única de las 21 que no aparece en ninguna de las cuatro fases. Está anunciada en la landing y no tiene fecha ni tramo asignado. Hay que ubicarla o sacarla del copy.

Deuda que no es pieza

ID	Qué falta	Estado	Por qué sigue ahí
D-02	Fixtures fuera de control de versiones. 78 MB de capturas reales. Hallazgo H4.	A medias	Son justamente el insumo para escribir los tests de P21 sin tocar la red. Mientras vivan fuera del repo, la red de seguridad depende de una carpeta en un solo computador.
D-03	Deuda de nombres tras la absorción. Quedan referencias a la marca anterior. Hallazgo H6.	A medias	Ojo con el user-agent `VadoBot/1.0`: puede estar en listas de permitidos de comercios, así que renombrarlo no es cosmético y no se toca antes del cutover (AR-01).

Fuente: auditoría SuperArqDev del 20-ago-2026 sobre el commit inicial · catastro completo con diagramas en bbp.agentroom.io/arquitectura · el backlog del motor (B-01…B-30) sigue en vado.junngla.com/bbp hasta el cutover

Comercial

El embudo

Cómo se vende AgentRoom y —lo que más importa hoy— hasta dónde se puede vender. El embudo comercial es el mismo de los cuatro niveles: no hay un recorrido de ventas paralelo al del producto. Lo que cambia por nivel no es el discurso, es qué se puede entregar de verdad.

El gancho

/analiza

Informe de brechas de 24 puntos con evidencia. Gratis y es del comercio aunque nunca siga.

Techo de entrega hoy

Nivel 02

El gemelo publicado y legible. Se entrega a mano, sin medición ni corte automático.

Primera venta

Bloqueada

El nivel 03 no se puede cotizar: la tarifa en ARU sigue en TBD.

La restricción que ordena todo lo comercial: hoy se puede entregar hasta el nivel 02 y no se puede cobrar el 03. No es una decisión de precio pendiente de comunicar: es que no hay número (AR-02) y los servicios que justifican el nivel —Handshake, auditoría, monitoreo, reportes, sala cerrada, control de fraude— están nombrados y no construidos (AR-04). Se prospecta y se adhiere; no se cotiza.

Del nivel del producto a la etapa comercial

Nivel	Etapa comercial	Qué significa que avanzó	Hoy
01	Adquisición. Se corre el análisis y se entrega el informe de brechas.	La organización recibió su informe con evidencia. No hay compromiso de ninguna parte.	Operativo
02	Adhesión. Se arma el gemelo y la organización queda legible para los agentes.	Hay gemelo publicado y la organización aportó la contraprestación acordada: su información, políticas, procedimientos y catálogo.	A pulso
03	Primera venta. Agente publicado que responde por cada persona, con tarifa en ARU.	Hay contrato y tarifa. Es el primer peso que entra por AgentRoom.	Bloqueada
04	Expansión. El agente transacciona: compras, pagos, reservas, tickets.	La cuenta sube de nivel sin cambiar de proveedor. Es donde el ARU crece.	No aplica aún

Por qué el 02 dice «a pulso». Es gratis por 3 meses a cambio de acciones de la empresa, pero nada mide esas acciones ni corta a los 3 meses (AR-03). Cada adhesión que se cierre hoy es un compromiso que hay que sostener a mano y recordar a mano. Sirve para partir; no escala.

Reglas comerciales que no se rompen

ID	Regla	Por qué
RC-1	Mostrar sí, prometer no. No se compromete con fecha nada que no esté en producción.	Es la misma regla del producto llevada a la conversación de venta. Las etapas ya publican su estado real; el discurso comercial no puede ir más adelante que el backlog técnico.
RC-2	El informe del nivel 01 se entrega igual. Aunque la conversación no siga.	Es el gancho de adquisición y la prueba de que el análisis vale. Condicionarlo lo convierte en otra cosa y quema el activo.
RC-3	No se cotiza el nivel 03 mientras la tarifa sea TBD. Ni con un rango, ni «a confirmar».	Un número dicho en una reunión queda como ancla aunque después se publique otro. Hasta que AR-02 se cierre, la respuesta honesta es que el nivel pagado aún no se vende.
RC-4	Complemento, nunca competidor. AgentRoom no se presenta como alternativa al canal del comercio ni al asistente de la persona.	No hay app de consumidor ni marca frente a la persona. Si la conversación deriva a «reemplazo», se corrige en la reunión: se pierde el encuadre y con él la venta.
RC-5	Paga el comercio, y solo el comercio.	Ni el comprador ni el asistente pagan. El modelo bilateral C-ARU / P-ARU quedó archivado; reabrirlo es una decisión de producto, no una concesión de negociación.

Comercial

Acciones

El registro de lo que se hizo para vender: a quién, por dónde, qué pasó y qué sigue. Igual que la bitácora deja anotada la decisión y no solo el resultado, acá queda anotado qué se aprendió de cada contacto, que es lo que se pierde cuando el seguimiento vive en la cabeza.

Acciones registradas

El seguimiento parte hoy, 23-ago-2026. Nada anterior está documentado.

Cuentas en seguimiento

Sin organizaciones en conversación registradas.

Ventas cerradas

Estructural, no comercial: el nivel 03 todavía no se puede cobrar.

Cómo se alimenta. Francisco avisa la acción —una reunión, un correo, un análisis entregado, una respuesta— y queda anotada acá con su C-xx. Sin cifras inventadas y sin optimismo: si un contacto no contestó, se anota que no contestó. Una acción cerrada no se borra, se marca cerrada con lo que resultó.

Registro

ID	Fecha	Organización	Qué se hizo y qué resultó	Siguiente paso
Sin acciones registradas todavía. La primera queda anotada apenas ocurra.

Cuentas

Organización	Industria	Nivel	Dónde está y qué la traba	Estado
Sin cuentas en seguimiento. La industria se anota como Retail, Servicios o Sistemas, igual que en el producto.

Lo que falta para que esto deje de ser una tabla a mano. No hay cuenta del comercio (P1), ni métricas de distribución (P18), ni metering (P19). Mientras esas tres no existan, el seguimiento comercial y el estado real de una cuenta viven en este documento y en ninguna otra parte.

Seguimiento abierto el 23-ago-2026 · el embudo sale de los cuatro niveles en src/data/how-it-works.ts · la tarifa, de src/config/pricing.ts

Gestión

Backlog

Lo que falta y por qué no se hizo todavía, que es el dato que se pierde con el tiempo. Acá van las decisiones: producto, negocio y orden. La construcción —las 21 piezas y la deuda de los hallazgos— tiene su propia lista en el backlog técnico. El backlog del motor (B-01…B-30) vive en la bitácora de VADO mientras no haya cutover.

Cómo se lee. Bloquea impide vender o cobrar hoy. Importa hay que resolverlo antes de escalar. Cuando toque es deuda consciente. La columna Por qué sigue ahí es la razón por la que se postergó, para no rediscutirla desde cero.

Producto y negocio

ID	Qué falta	Por qué sigue ahí	Prioridad
AR-02	Fijar la tarifa en ARU. Todas las líneas de pricing salen `null` = `TBD`.	Es la decisión comercial que falta, no un bug: el código ya muestra «TBD» a propósito. Sin número no se puede cerrar una venta del nivel 03, y por eso RC-3 prohíbe cotizarlo (embudo).	Bloquea
AR-03	Mecanismo del nivel 02. Es gratis 3 meses «a cambio de acciones de la empresa», pero nada mide esas acciones ni corta a los 3 meses.	Hoy el nivel 02 se sostiene a mano. Sin medición ni corte, el «3 meses» es una promesa de copy, no una regla del sistema: cada adhesión se sostiene a mano (embudo).	Importa
AR-04	Los servicios del nivel 03 están nombrados, no construidos: Handshake, auditoría, monitoreo, reportes, sala cerrada y control de fraude.	Se anuncian en la landing como lo que trae el nivel pagado. «Mostrar sí, prometer no»: mientras no existan, no se cobran ni se prometen con fecha.	Importa
AR-05	Colisión de marca. Hay homónimos de «AgentRoom». Falta verificar registrabilidad y despeje antes de invertir en la marca.	El dominio ya está en vivo y hay enlaces publicados. Cambiar de nombre después cuesta; verificar antes de escalar el gasto en marca.	Importa
AR-06	Las 21 piezas de producto por construir (14 bloqueantes). La landing describe un recorrido cuyo tramo pagado aún es promesa. Desglose pieza por pieza en el backlog técnico.	Es el mapa de lo que separa la narrativa de la operación. Se prioriza por fases (adhesión → caja → transacción), no en bloque.	Importa

Análisis por industria

ID	Qué falta	Por qué sigue ahí	Prioridad
AR-07	Checks propios de Sistemas/SaaS y de perfil financiero. La capa de Resolución (22-ago) cubre servicios e instituciones, pero un banco o un SaaS necesitan puntos propios.	Hereda el B-29 del motor: el clasificador entiende «producto» como bien con precio y carro. La transacción equivalente —simular un crédito, contratar una licencia— necesita checks propios.	Importa

Infraestructura y orden

ID	Qué falta	Por qué sigue ahí	Prioridad
AR-01	Cutover de vado.junngla.com → AgentRoom. Hoy este repo es una copia, no una mudanza; VADO sigue sirviendo su dominio.	Copiar y no mudar fue deliberado: mientras VADO tenga clientes en Puertas D, apagarlo es una decisión aparte que hay que planear, no un efecto colateral de la fusión.	Cuando toque
AR-08	El backlog del motor (B-01…B-30) vive en el BBP de VADO. Cuando haya cutover hay que traerlo o unificar los dos documentos.	Duplicar 30 líneas que aún pueden moverse en VADO invita a que se desincronicen. Se cruza por enlace hasta el cutover (AR-01).	Cuando toque
AR-09	La red de seguridad (Fase 0 de la auditoría): tests de los 16 checks con las fixtures reales, CI/CD con typecheck de ambos `tsconfig`, y subir `next` a 16.3.1. Cierra los hallazgos H1, H2 y H3 (P21, P20, D-01 del backlog técnico).	Es lo primero del plan: hoy hay 0% de cobertura sobre un motor en producción, y ninguna de las 21 piezas se puede construir con seguridad sin esto. No construye producto, pero desbloquea todo lo que sí.	Bloquea

Al cerrar una línea no se borra: se mueve a la bitácora con la fecha y qué se hizo. El backlog dice lo que falta; la bitácora, lo que ya pasó.

Gestión

Bitácora

Lo que ya pasó en AgentRoom, en orden inverso. Cada entrada deja anotada la decisión, no solo el resultado. La historia del motor (jul–ago) está en la bitácora de VADO.

23-ago-2026

Se abre el seguimiento comercial

Nuevo grupo Comercial con dos secciones: El embudo, que mapea los cuatro niveles del producto a etapas de venta, y Acciones, el registro de a quién se contactó, qué pasó y qué sigue. Parte en cero a propósito: no hay nada anterior documentado y no se va a rellenar hacia atrás.

Lo que obligó a escribir el embudo antes que el registro: hoy se puede entregar hasta el nivel 02 y no se puede cobrar el 03. No es precio pendiente de comunicar —no hay número (AR-02) y los servicios que justifican el nivel no están construidos (AR-04)—, así que el cero de ventas es estructural, no comercial. Quedaron fijadas cinco reglas RC-1–RC-5; la más dura es RC-3: no se cotiza el nivel 03 mientras la tarifa sea TBD, ni con un rango, porque un número dicho en una reunión queda de ancla aunque después se publique otro.

23-ago-2026

Backlog técnico: las 21 piezas salen del informe y entran al BBP

El catastro de piezas vivía solo en el informe de arquitectura, y el backlog de Gestión lo resumía en una línea (AR-06). Ahora tiene sección propia en Técnico, ordenada por las fases del plan y con la misma columna que el resto del backlog: por qué sigue ahí. La división quedó explícita —Gestión decide, Técnico construye— y se sumaron D-01–D-03 para la deuda de los hallazgos que no es una pieza de producto.

Dos cosas que aparecieron al ordenarlo. P4, el Agent Room Manager, no está en ninguna de las cuatro fases pese a estar anunciado en la landing: hay que ubicarlo o sacarlo del copy. Y la Fase 0 sigue diciendo «los 16 checks» porque se escribió el 20-ago, un día antes de que el análisis creciera a 24 puntos en 3 capas; el alcance real de P21 es 24. La auditoría no se toca —es una foto fechada—, la corrección va anotada en el backlog.

23-ago-2026

Cómo funciona, por industria; y el scan deja de repetir códigos

«Cómo funciona» ahora se elige por industria —Retail, Servicios, Sistemas— y muestra el camino adaptado: el catálogo del nivel 02 y los ejemplos de 03 y 04 cambian según el rubro. El recorrido se reencuadró en cuatro niveles: 01 y 02 gratis (02 por 3 meses, con acciones de la empresa), y la tarifa en ARU desde el 03, cuando hay un agente que responde por cada persona. La frontera del cobro se movió del 02 al 03 en la línea de tarifa, en pricing.ts y en el panel; Stages y Tarifas ya calzaban.

Bug del análisis: las capas Transaccionabilidad y Resolución imprimían los mismos códigos T09–T16, por una lógica vieja de cuando había dos capas. Ahora el prefijo vive en los datos (scan.ts) y cada capa reinicia en 01: L01–L09 · T01–T08 · R01–R08.

22-ago-2026

Tercera capa del análisis: de 16 a 24 puntos

Se agregó Resolución a las dos capas originales. Las dos primeras solo sabían preguntarle a una tienda: a un banco, un ministerio o una universidad les aplicaban cuatro puntos de dieciséis. El instrumento estaba mal, no los sitios. El análisis quedó en 24 puntos, 3 capas.

21-ago-2026

Dominio propio y redefinición del producto

agentroom.io pasó a ser la dirección; agentroom.junngla.com redirige con 308 permanente sin apagarse. El producto se redefinió: no es solo para tiendas —comercio, servicios, software e instituciones—, y el amarillo señal pasó a vestir también el llamado principal.

20-ago-2026

Fusión con VADO

AgentRoom absorbió a VADO: un gemelo digital es un agente en AgentRoom. El repo pasó a ser uno solo —landing, motor, funciones y CLI—, copiado del de VADO. Los nueve handlers no se reescribieron: se adaptan con src/lib/handler-vercel.ts. Dos tsconfig para validar web y motor por separado. La mudanza es por configuración (motor/marca.ts), no por código. El repo original de VADO quedó intacto y sigue sirviendo vado.junngla.com; el cutover es una decisión aparte (AR-01).

Ese mismo día se corrió SuperArqDev sobre el commit inicial: score 68/100 (SQALE C), 0% de cobertura de pruebas y el catastro de las 21 piezas que faltan con su plan por fases. Ver la auditoría As-Is/To-Be.

Fuente: sesiones de trabajo ago 2026 · reglas del repo en 01-agentroom-web/CLAUDE.md · historia del motor en vado.junngla.com/bbp