Un solo orquestador que decide, cuatro capacidades de naturaleza distinta. No son cinco esfuerzos iguales: la mitad ya vive en la base, otra parte son acciones, y una es integración profunda al CRM.
Lo que el director dibujó como 5 esfuerzos iguales, en realidad colapsa en una sola columna de recuperación que ya existe; lo nuevo son las acciones y el CRM.
Un subagente se justifica por necesitar herramientas o lógica propias, no por ser un tema distinto. Bajo esa regla:
Producto, empresa, precios, promos y legal-lectura son la misma operación: leer del RAG. Un solo tool con filtro por categoría, no cinco agentes.
El inventario cambia minuto a minuto. No puede vivir en el RAG: es un query directo a NocoDB, tool dedicado.
Cotizaciones, contratos y canvas RRSS generan algo. Aquí sí van subworkflows como tool — igual que el de RRSS que ya armamos.
La única que escribe en sistemas vivos (DVD, EVO). Necesita identidad de usuario, permisos por rol y confirmación. Otro nivel de riesgo.
El cuello de botella real no es el tono del prompt: es que el agente no siempre llama la búsqueda. Más tools = más decisiones de routing → orquestador en Sonnet.
Filtro de categoría en el RAG, forzar la búsqueda en cada turno, y conectar el inventario en tiempo real como tool dedicado.
Cotizaciones y contractual con el mismo patrón del canvas de RRSS. Esto ya lo puedes mostrar funcionando.
Orvito consulta tareas y áreas del asesor en DVD (NocoDB). Bajo riesgo — casi igual que el inventario.
"Ya hice esta tarea" / "acéptale la tarea": requiere identidad, permisos por rol y confirmación antes de escribir.
Aclaración clave para el director: DVD vive en NocoDB/Supabase, no en Lovable. Lovable es solo el frontend; Orvito se conecta a los datos y al CRM (EVO), no a Lovable.