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.

¿Cómo estructurar un sistema multiagente empresarial sin multiplicar costos de infraestructura?

La clave consiste en desacoplar el motor de razonamiento de los canales de contacto, centralizando lógica, memoria vectorial y herramientas en una sola API backend. En lugar de desplegar agentes aislados con bases de datos duplicadas, un único orquestador gestiona el contexto e inyecta instrucciones dinámicas según el origen de la interacción comercial o técnica.

Cuando cada canal opera como un silo independiente, el costo de cómputo y mantenimiento se dispara de forma lineal. Unificar la lógica bajo un mismo servicio permite reutilizar conexiones de base de datos, optimizar la caché de embeddings y concentrar la telemetría en un único punto de observación. La siguiente comparativa, basada en métricas internas de SCRAM AI Lab y tarifas estándar del mercado de nube a inicios de 2025, ilustra las diferencias operativas:

Criterio de evaluación	Plataformas SaaS No-Code	Agentes aislados por canal	Cerebro unificado (SCRAM)
Costo mensual base de plataforma	Medio a alto (cobro por asiento o mensaje)	Alto (múltiples servicios e instancias)	Bajo (reutiliza la infraestructura existente)
Consistencia de respuestas entre canales	Baja (bases de conocimiento separadas)	Media (sincronización manual requerida)	Total (mismo repositorio RAG y ERP)
Acceso a transacciones en tiempo real	Limitado a webhooks básicos	Variable y difícil de auditar	Nativo mediante herramientas tipadas
Tolerancia a fallas de proveedores LLM	Dependiente del proveedor SaaS	Riesgo de fallo dispar entre canales	Centralizada con circuit-breaker propio
Riesgo de alucinación en datos contables	Alto si consulta texto desactualizado	Alto si lee vectores en lugar de BD	Cero: delegación a funciones SQL/código

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.

Retos operativos de la IA conversacional en América Latina

Implementar agentes autónomos en mercados latinoamericanos exige resolver restricciones que los tutoriales internacionales suelen ignorar:

• Latencia transfronteriza: los centros de datos de los principales proveedores de modelos fundacionales operan predominantemente en Estados Unidos o Europa. Cada llamada de inferencia suma entre 120 y 250 milisegundos únicamente en trayecto de red. Si el sistema encadena múltiples llamadas de herramientas sin optimización, el usuario percibe retrasos inaceptables. Para contrarrestarlo, ejecutamos paralelismo de llamadas a herramientas y streaming de tokens inmediato al frontend.
• Economía de WhatsApp: según la estructura de precios de Meta Cloud API para México y la región, los cargos por conversación de servicio o autenticación exigen una gestión estricta de las ventanas de 24 horas. Desperdiciar interacciones por respuestas redundantes incrementa los costos operativos mensuales en dólares.
• Procesamiento de audio local: la transcripción de mensajes de voz en WhatsApp no puede depender de modelos anglocéntricos sin afinación. En México conviven regionalismos, modulaciones de velocidad y ruidos de entorno que demandan pipelines de audio con modelos Whisper optimizados para dialectos locales antes de pasar el texto al razonador.

Modos de falla en producción y cómo mitigarlos

El diseño de agentes autónomos exige anticipar dónde se rompe el flujo determinístico frente a la probabilidad del modelo:

• Timeouts en herramientas de datos: cuando una consulta al ERP toma más de tres segundos debido a bloqueos de transacciones, el agente puede alucinar una disculpa o reintentar indefinidamente. La solución implementada es un candado temporal estricto (timeout de 2,500 ms) que, al activarse, fuerza un mensaje de contingencia solicitando reintentar o canalizando a soporte humano.
• Deriva del juez evaluador (LLM drift): con las actualizaciones continuas de los modelos subyacentes, las evaluaciones del juez pueden volverse más permisivas o hipercríticas sin previo aviso. Por ello, la calibración con el coeficiente kappa de Cohen sobre la muestra de control humana se repite de manera periódica en el pipeline de CI/CD.
• Agotamiento de cuotas de tokens: un pico de tráfico no anticipado puede congelar la operación si no existe redundancia. Nuestra capa de red cuenta con fallback automático hacia proveedores secundarios cuando se detecta un código HTTP 429 persistente.

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.