perla|Roadmap del agente 20 mayo 2026 · documento vivo

Lo que el agente va a poder hacer.

Los hitos del producto, en lenguaje de capability. Cada hito describe qué puede hacer el agente, el customer o el owner cuando se cierra. Al expandir cada hito aparecen las tareas técnicas que lo construyen, con sus dependencias y estimaciones.

Capítulo 01

Mapa de horizontes

Tres fases consecutivas. Cada fase tiene bloqueantes técnicos que mandan más que la prioridad de producto. Cuando un hito depende de otro, está marcado explícito en su card.

  • Fase A · piloto. Lo que cierra el piloto con 3-10 negocios reales y soporte alto del equipo.
  • Fase B · deploy comercial. Lo que cierra el ciclo vendible al público, self-serve.
  • Capas independientes. Seis hitos autónomos que se construyen sobre el MVP estable, sin competir con la Fase A.
Capítulo 02 · piloto

Hitos del piloto

Ocho capabilities concretas que cierran el piloto con 3-10 negocios reales. Cada hito describe qué puede hacer el agente, el customer o el owner cuando cierra — y abajo, las tareas técnicas que lo construyen.

H0 · estado actual Lo que ya vive en main

Lo que el runtime ya tiene cableado y funcionando. No es un ítem pendiente — es el punto de partida del roadmap. Los hitos siguientes se construyen sobre esto.

punto de partida

Lo que ya está

  • DBMulti-tenant con RLS sobre 35+ tablas, schema validado
  • AGT8 tools agente cableadas: get_services, get_staff, list_appointments, list_conversations, create/cancel/reschedule_appointment, take_conversation
  • WAWebhook WhatsApp con HMAC + dispatch automático vía scheduleAgentDispatchForInboundTarget
  • TGWebhook Telegram funcional (modo customer always)
  • MPMódulo Mercado Pago backend al 70%
  • DSHDashboard mobile v0 en producción
  • AUTAuth + onboarding + tenant context completos

Gap único hoy: falta el cable del despacho final a Meta (lo cubre H1)

Próximos hitos en orden de prioridad

H1 · próximo El agente responde

Hoy el agente entiende, busca en la base y compone respuesta. Lo que falta es enviar esa respuesta al teléfono del customer. Este hito cierra el ciclo conversacional — el customer recibe el mensaje del agente.

motor vivo

Lo que lo construye

  • A1Cableo del envío outbound a Metacrítico

Estimación: 1 sprint · Bloqueado por: decisión arquitectural sobre cómo despachar (inline / waitUntil / queue)

H2 El agente opera turnos de punta a punta

El customer puede sacar, mover o cancelar un turno desde WhatsApp y recibir confirmación natural. Si Meta reintenta el webhook (cosa que hace por diseño), el agente no duplica turnos ni dispara la lógica dos veces. La analítica del negocio distingue turnos creados por el agente de los cargados a mano.

operación end-to-end del turno

Lo que lo construye

  • A1Cableo del envío outboundcrítico
  • #88Hardening tenant scope + audience filter + take_conversation runtimealta
  • #89Idempotencia + gate handoff + reactivación 12halta
  • A6Columna source en appointments (no contaminar analítica)media

Depende de: H1 · Estimación: 1-2 sprints post-H1

H3 El customer paga la seña por WhatsApp

El customer recibe el link de Mercado Pago en la conversación, paga, y el turno se confirma solo. El booking_hold se libera cuando el webhook MP confirma el pago. Sin esto no hay producto vendible para casos como Suri, que operan solo con seña.

producto comerciable

Lo que lo construye

  • A2Tool create_payment_link + flujo hold → succeeded → confirmedcrítico
Asterisco · realidad de producción La estimación cubre el camino feliz. La realidad de producción suele ser más compleja: escenarios de devolución, políticas de uso del proveedor, edge cases de fallos parciales del webhook, idempotencia de notificaciones MP, manejo de retries. Sumado al stack paralelo de escenarios del dashboard que estarán resolviéndose en simultáneo, este hito puede inflar bastante en la práctica. Anotar como riesgo de cronograma — no para frenar, sí para no sorprenderse.

Depende de: H1 · Estimación: 2 sprints en teoría, más en la práctica

H4 El agente sabe cuándo escalar al humano

Cuando el agente detecta un intent fuera de scope (queja compleja, situación delicada, pedido raro), le pide al owner que tome la conversación. El owner ve la cola de pedidos en el dashboard y agarra cuando puede. La parte de owner-pull ya vive con la tool take_conversation; falta el push del agente.

handoff sano

Lo que lo construye

  • A3Tool request_handoff + bandeja de handoff_requests en dashboardcrítico

Depende de: H1 + dashboard mobile (vivo) · Estimación: 1 sprint

H5 El agente protege al owner de errores irreversibles

Si el customer pide cancelar o mover un turno, el agente le pide confirmación explícita antes de ejecutar. Cualquier acción medium/high risk pasa por doble confirmación con el customer. Defensa contra LLM destructivo, el schema ya soporta el patrón con pending_operations.

salvavidas operativo

Lo que lo construye

  • A5Orquestación de pending_operations + flow de confirmaciónalta

Depende de: H1 · Estimación: 1 sprint

H6 El owner controla el negocio sin abrir el dashboard

Todo lo que hoy hace el owner en el dashboard, lo puede hacer chateando con Perla por WhatsApp: crear customers, modificar servicios, asignar staff a tools, cambiar horarios, ajustar settings, declarar modo vacaciones. Mapeo 1:1 entre dashboard y WhatsApp — promesa central de la Fase A.

mapeo 1:1 dashboard ↔ WA

Lo que lo construye

  • A49 tools CRUD: customers, service variants, staff, availability rules, schedule blocks, assistant configs, business settingsalta

Depende de: H1 + decisión de scope (cuáles son los 9 mínimos) · Estimación: 3 sprints (1 por bloque temático)

H7 Cada negocio tiene su propia Perla

Cada business configura desde dashboard cómo responde su agente: tono, restricciones, info propia, casos puntuales. El system prompt mergea esa configuración antes de cada llamada al LLM. Sin redesplegar, sin tocar código — desde la UI del owner.

personalización sin código

Lo que lo construye

  • A7Inyección de assistant_configs al system prompt por businessmedia

Estimación: 1 sprint

H8 El owner prueba el agente desde el dashboard

Antes de mandar el agente a customers reales, el owner puede chatear con la misma Perla desde el dashboard. Para probar, para confiar, para mostrar al equipo. Ya hay endpoint manual; falta la UI.

demo + onboarding interno

Lo que lo construye

  • A8UI chat en dashboard mobile + endpoint que reusa el runtime de WAbaja

Estimación: 2 sprints (UI + integración)

Sub-pendientes operativos no técnicos Voseo rioplatense en el prompt (ajuste detectado en smoke test). display_phone placeholder en channel_connections: actualizar al real +54 9 341 260 5357. Templates Meta a enviar a aprobación (3-7 días) — empezar el trámite ya para no bloquear B1.
Capítulo 03 · deploy comercial

Hitos del deploy comercial

Cinco capabilities que cierran el ciclo vendible al público, self-serve. Se construyen contra el feedback del piloto.

HB1 Perla avisa sin que le pregunten

El customer recibe el recordatorio del turno sin que nadie tenga que mandarlo a mano. Promesa central del producto al cliente final: "Perla te recuerda los turnos automáticamente." Necesita templates aprobados por Meta para poder mandar mensajes fuera de la ventana de 24h.

recordatorios proactivos · venta

Lo que lo construye

  • B1Cron handlers en Workers + tabla scheduled_notifications + templates Meta aprobadoscrítico

Bloqueado por: templates Meta aprobados (trámite externo 3-7 días, empezar ya) · Estimación: 2 sprints + tiempo Meta

HB2 El customer puede mandar audio

El customer manda un audio por WhatsApp y el agente lo entiende como si fuera texto. En LATAM no es edge case — es comportamiento normal de uso. Inclusión + UX natural. Whisper transcribe, el flow sigue igual.

inclusión + UX natural

Lo que lo construye

  • B2Integración Whisper (OpenAI o Cloudflare AI) + flow audio → texto → agente + storage del crudo en messages.media_urlalta

Estimación: 1 sprint

HB3 El agente maneja turnos complejos

El customer puede sacar un turno con varios servicios encadenados ("corte + tintura"), agendar un turno recurrente ("todos los lunes a las 10"), o comprar un paquete de N turnos con descuento. El agente entiende y orquesta. El schema soporta nativamente la mayoría del modelo.

turnos compuestos · recurrentes · paquetes

Lo que lo construye

  • B3Tool create_composite_appointment + availability check cross-staffalta
  • B4Turnos recurrentes (una seña por turno, no bundle) — evaluar complejidad de edge casesmedia
  • B5Paquetes y bundles — va junto con compuestos a nivel modelomedia

Estimación: 3-4 sprints según se cierre el scope de B4/B5

HB4 El ciclo del turno se cierra

Cada turno tiene un cierre claro: confirmación previa del customer si aplica, registro de no-show si el customer no apareció, métrica para el owner. El negocio puede empezar a medir su tasa real de asistencia y ajustar política de seña.

no-show + confirmación post

Lo que lo construye

  • B6No-show + confirmación post-turno (UX a definir: fin de día / turno a turno / dashboard)media
  • B8Confirmación activa de turnos (cuándo confirma, qué pasa si no responde — UX abierta)baja

Pendiente: definir UX de los dos flujos antes de cablear

HB5 El owner controla cuándo lo molesta Perla

El owner define una ventana de notificaciones: "no me avises entre 22hs y 9hs." Distinto al horario de atención de Perla (que sigue siendo 24/7 hacia customers). Es el owner el que descansa, no el agente.

ventana de notificación owner

Lo que lo construye

  • B7Campo notification_window en business + skip de notificaciones a owner fuera de rangobaja

Estimación: 1 sprint chico

Capítulo 04 · capas independientes

Capas que se construyen sobre la base

Seis hitos autónomos que se construyen sobre el MVP estable. Cada uno tiene su propio sprint de definición. No compiten con la Fase A — si en algún sprint hay capacity y el motor está estable, alguno puede arrancar en paralelo (especialmente HP1, la capa más independiente).

HP1 El negocio mide cómo está respondiendo

Perla mide el sentimiento del customer después del turno (NPS), pushea reviews positivas a Google Maps automáticamente, y re-engancha customers silenciosos. El owner deja de adivinar cómo está su negocio.

reviews + reputación

Lo que lo construye

  • P1NPS post-turno + push Google Maps + re-engagement de silenciososmedia
HP2 El owner recibe el resumen sin pedirlo

Cada lunes (o el día que el owner elija) llega un mensaje de Perla con el resumen de la semana: ocupación, ingresos, no-shows, ranking de clientes. El owner deja de tener que abrir el dashboard para saber cómo va.

asistente personal

Lo que lo construye

  • P2Cron handler + template de informe + entrega por WA al ownermedia
HP3 Perla avisa cuando se libera el horario

El customer pide un horario que está lleno. Perla lo anota en lista de espera y lo avisa por WhatsApp cuando se libera. El negocio captura demanda que hoy se le escapa.

lista de espera

Lo que lo construye

  • P3Tool join_waitlist + cron de check de liberación + notificaciónmedia
HP4 Cada negocio con su propio número de WhatsApp

El owner conecta su propio número WABA en vez de usar el compartido de Perla. Branding propio, sin pasar por el número genérico. Requiere onboarding de WhatsApp Business por tenant.

BYO-N · Bring Your Own Number

Lo que lo construye

  • P4Flow de onboarding WABA por tenant + multi-channel routingmedia
HP5 Perla cobra a los negocios automáticamente

El negocio se suscribe a Perla con su tarjeta vía Mercado Pago. Cobro mensual automático. Sin chasear pagos a mano. Modelo de revenue de Perla cierra el círculo comercial.

monetización · suscripción

Lo que lo construye

  • P5Suscripción MP a tenants + gestión de estados (activa, vencida, cancelada) + paywall en dashboardmedia
HP6 Detectar el customer que arrancó y no terminó

El customer empieza a reservar, da algunos pasos y abandona. Perla lo registra como abandono mid-flow, mide la tasa, y opcionalmente lo re-engancha. El negocio recupera ventas perdidas.

tracking de abandono

Lo que lo construye

  • P6Telemetry de mid-flow + métrica de abandono + re-engagement automático opt-inmedia
Capítulo 05 · out of scope

Lo que NO entra (clarity explícita)

Cualquier propuesta que caiga acá → flagearla y pedir justificación antes de aceptar.

  • Multi-modelo por rol (Haiku customer + Sonnet owner). Optimización de costo, post-MVP. Decisión cerrada 16/05.
  • Telegram doble flujo (owner + customer separados como WhatsApp). Fuera por decisión. Mismo razonamiento.
  • Lista de espera dentro del MVP. Pasó a P3.
  • Reviews / NPS dentro del MVP. Pasó a P1.