Así construimos los chatbots de SCRAM: 4 agentes, un solo cerebro

Por qué contamos esto

La mayoría del contenido sobre chatbots empresariales lo escriben empresas que venden chatbots. Este artículo es distinto: es la radiografía de nuestro propio sistema en producción — el que atiende scram2k.com, el portal de soporte, la operación interna y WhatsApp. Lo contamos con detalle porque creemos que en Latinoamérica falta exactamente esto: casos reales, con arquitectura real, de equipos que construyen en vez de solo integrar. No compramos una plataforma de chatbots: construimos un cerebro y le pusimos cuatro caras.

Los cuatro agentes

• El bot de ventas del sitio (scram2k.com): atiende visitantes con una identidad comercial basada en metodología SPIN — pregunta por situación, problema e implicación antes de proponer. No recita catálogo: califica al visitante y lo conecta con el funnel.
• El bot de soporte público (portal de soporte): otra identidad sobre el mismo motor, con flujos de diagnóstico guiado, un fast-path de preguntas frecuentes que responde sin gastar tokens del modelo, y la capacidad de crear tickets reales en nuestra mesa de ayuda (GLPI).
• Scramteca, el agente interno de nivel 3: la versión con permisos elevados. Consulta ventas, clientes, tendencias y tickets contra el ERP vivo, crea cotizaciones y pedidos, y escribe tareas — siempre con confirmación explícita en dos turnos antes de tocar nada.
• El agente de WhatsApp (Meta Cloud API): un SDR de IA que responde texto y voz — recibe un audio, lo transcribe, razona la respuesta y puede contestarla hablada. Con handoff a humano cuando la conversación lo amerita.

Un solo cerebro: la decisión de arquitectura que definió todo

Los cuatro agentes viven en un mismo módulo de nuestra API NestJS. La personalidad no se duplica: una función buildSystemPrompt() compone el prompt según el origen de la conversación — el dominio de ventas recibe la identidad comercial, el de soporte la identidad de diagnóstico, el portal interno la identidad administrativa. Cambiar una regla de tono se hace una vez y aplica a todos.

Debajo comparten la misma infraestructura:

• RAG sobre pgvector: la base de conocimiento se embebe en PostgreSQL con búsqueda vectorial, con fallback a búsqueda por palabras clave si aún no hay embeddings. Sin servicios de vectores externos: el mismo Postgres del negocio.
• Resiliencia compartida: circuit-breaker, reintentos con fetch resiliente, sanitizador de mensajes y rate-limiting. Cuando el proveedor del modelo tiene un mal día, el bot degrada con gracia en vez de colgar la conversación.
• Memoria común en el CRM: cada conversación —web, soporte o WhatsApp— queda registrada como actividad del contacto. Nuestro tracker propio liga al visitante anónimo con su contacto cuando se identifica, así que el agente de WhatsApp "sabe" lo que el visitante preguntó en el sitio.

Herramientas contra el ERP vivo, no contra vectores

La lección más cara del proyecto: al principio, el agente interno respondía preguntas de negocio leyendo la base vectorial… y contaba 1,160 facturas donde el ERP real tenía 3,155. Los embeddings son para conocimiento, no para datos. Hoy Scramteca opera con un registro de herramientas tipadas —ventas, cliente, desglose, tendencia, tickets— que consultan las tablas reales del ERP en el momento de la pregunta. El modelo decide qué herramienta usar; la herramienta garantiza que el número sea el verdadero.

De ahí salió nuestra regla madre, la que repetimos en cada diseño: lo que se puede decidir en código no se le pregunta al modelo. Permisos, candados, validaciones de precio, formatos de fecha: todo eso vive en TypeScript, no en el prompt. Cada vez que intentamos resolver un comportamiento con instrucciones al modelo y falló dos veces, lo movimos a código y salió a la primera.

Escribir requiere confirmación (y auditoría)

Los agentes que solo leen son fáciles. Los nuestros también escriben: cotizaciones, pedidos, tareas, tickets. Cada acción de escritura usa un patrón de doble confirmación en dos turnos — el agente propone la acción con todos los datos visibles, y solo la ejecuta si el usuario confirma en el turno siguiente. Los montos se calculan con la misma función computeTotals del ERP (no con aritmética del modelo), los permisos se validan por cliente, y la escritura se verifica contando filas después de ejecutar.

El juez: un LLM que califica al LLM

¿Cómo sabemos que los bots responden bien sin leer miles de conversaciones? Un juez LLM evalúa turnos de conversación contra criterios editoriales y de negocio, y alimenta un ciclo de aprendizaje. Y como no confiamos a ciegas ni en el juez, lo estamos calibrando contra etiquetas humanas con una muestra de 120 turnos, buscando un acuerdo kappa ≥ 0.60. Medir al que mide: esa es la parte que casi nadie hace.

El taller detrás: MCPs, Skills y agentes propios

Nada de esto se construyó a mano alzada. Nuestro equipo desarrolla con agentes de coding y construimos nuestras propias piezas del ecosistema:

• MCPs propios — servidores Model Context Protocol que exponen nuestras fuentes de datos (por ejemplo, un MCP de datos INEGI para prospección y otro de memoria semántica del código) a cualquier cliente LLM.
• Skills propias — procedimientos empaquetados que nuestros agentes de desarrollo ejecutan igual cada vez: crear una herramienta de datos para un agente, auditar seguridad, generar portadas de marca.
• Agentes especializados — subagentes de revisión, investigación y despliegue que trabajan en paralelo sobre el mismo repositorio.

El resultado práctico: el mismo estándar que usamos para construir el producto lo usamos para construir las herramientas que construyen el producto.

MiroFish: ensayar el futuro con enjambres de agentes

La pieza más experimental del stack es nuestra instancia propia en español de MiroFish — un Motor de Inteligencia de Enjambre Conciso y Universal. La idea: a partir de un solo documento (un informe, un plan), extrae "semillas de realidad", construye un GraphRAG del entorno, genera perfiles de agentes y simula un mundo paralelo con hasta millones de agentes para ensayar dinámicas de grupo antes de decidir. Un ReportAgent analiza la simulación y puedes conversar con cualquier individuo simulado. Lo operamos en nuestra propia infraestructura, adaptado al español, con simulaciones que cuestan en promedio ~$5. Es la diferencia entre opinar sobre una decisión y ensayarla.

Lo que aprendimos (resumen honesto)

• Un cerebro, muchas caras gana a un bot por canal: la consistencia y el mantenimiento no escalan de otra forma.
• Datos por herramientas, conocimiento por RAG. Mezclarlos produce respuestas seguras de sí mismas y equivocadas.
• Código > prompt para toda decisión determinística. El prompt es para el criterio, no para las reglas.
• Escritura con doble confirmación y verificación posterior, siempre.
• Mide al bot y mide al que mide: juez LLM + calibración humana.

Esto es lo que significa para nosotros integrar IA correctamente desde Latinoamérica: no esperar a que llegue empaquetado, construirlo con ingeniería seria, y contar cómo — con los errores incluidos. Si tu empresa quiere este nivel de integración, así lo aplicamos a operaciones como la tuya.