La promesa que casi no cumplimos
Un sábado por la tarde, después de configurar credenciales de Google Cloud, integrar OpenAI con n8n y cargar un prompt de 2,000 palabras escrito con cuidado quirúrgico, encendimos por primera vez a ArIA — el agente IA que iba a vivir en el sitio web de EDM.
Las cinco primeras conversaciones de prueba fueron un desastre.
ArIA respondía con frases genéricas. No capturaba ni un solo dato del usuario. Cuando un lead pedía agendar una llamada, contestaba con entusiasmo pero no tenía con qué agendar. Cinco mensajes después, seguía preguntando lo mismo en bucle.
El stack era impecable: n8n self-hosted, GPT-4o, Google Sheets, Google Calendar, Telegram para handoffs, prompt engineering serio. Sobre el papel, debería funcionar.
No funcionaba.
Este es el caso de estudio de cómo encontramos los tres bugs en cadena que rompían todo, cómo los resolvimos, y por qué la lección sirve a cualquier empresa que esté pensando en implementar un agente IA real, no un chatbot disfrazado.
Por qué un agente IA no es un chatbot
Antes de entrar al diagnóstico técnico, vale la pena precisar.
Un chatbot sigue árboles de decisión. “Si el usuario dice X, responde Y”. Llevan en el mercado desde 2018 y la mayoría de gente los ha sufrido en bancos y aseguradoras. Funcionan para preguntas frecuentes pero se rompen ante cualquier matiz.
Un agente IA conversacional entiende contexto, interpreta intención, mantiene memoria de la conversación y toma decisiones autónomas en función de objetivos. La diferencia técnica es enorme: detrás hay un modelo de lenguaje (en este caso GPT-4o) orquestado por un sistema que mantiene estado, persiste datos, valida acciones y se conecta con APIs reales.
ArIA debía ser esto último. Su trabajo era específico: atender a quien llegara al sitio web de EDM, entender su negocio, asesorar como consultora real, capturar seis datos clave (nombre, empresa, email, WhatsApp, dolor principal, presupuesto) y agendar una llamada de diagnóstico de 30 minutos en el calendario del director de la agencia.
Sobre el papel, sencillo. En la práctica, tres bugs silenciosos lo estaban rompiendo.
Los tres bugs en cadena
Lo que hace que un bug sea silencioso es que el sistema no se rompe del todo. Sigue respondiendo. Sigue pareciendo que funciona. Pero internamente algo está mal y el síntoma es difícil de aislar porque cada bug enmascara al siguiente.
Bug 1: La memoria que nunca se guardó
ArIA debía guardar cada mensaje del usuario en una hoja de Google Sheets para poder consultar la conversación previa al responder al siguiente turno. Esto es lo que le da memoria.
El problema: el nodo encargado de guardar nunca lo hizo. No había error visible. Ningún mensaje rojo, ningún warning, ningún log. La operación reportaba “éxito” pero la hoja de cálculo seguía vacía.
La causa fue una opción de configuración aparentemente trivial: el método de mapeo automático estaba desfasado con el esquema actual de la tabla. El sistema cacheaba un esquema viejo, intentaba escribir contra él, fallaba sin avisar y reportaba success.
Síntoma para el usuario: ArIA olvidaba todo entre mensaje y mensaje, pero respondía con apariencia de coherencia gracias al modelo de lenguaje.
Bug 2: El contador de turnos siempre en cero
ArIA tenía una directiva clave en su prompt: “al tercer mensaje del usuario, si todavía no tienes su nombre, pídelo de forma natural.” Esto evitaba que la conversación se quedara en bucle exploratorio sin progresar.
El problema: el sistema calculaba qué turno era a partir del contador de mensajes guardado en Google Sheets. Y como el Bug 1 hacía que Sheets nunca recibiera datos, el contador siempre era cero. Para ArIA, todas las conversaciones eran “el primer mensaje”.
La directiva del tercer turno nunca se disparaba. ArIA se quedaba indefinidamente en modo exploración, preguntando sobre el problema una y otra vez sin avanzar a la captura de datos.
Síntoma para el usuario: la conversación que daba vueltas sin progresar.
Bug 3: Sin transcripts, sin contexto
Como Sheets nunca se escribía (Bug 1) y los turnos siempre estaban en cero (Bug 2), el sistema no podía reconstruir el historial de la conversación para mandárselo a GPT-4o como contexto.
Cada nuevo mensaje del usuario llegaba al modelo de lenguaje como si fuera el primero. Sin memoria del intercambio previo, ArIA no podía recordar lo que ya había preguntado, lo que el usuario ya había respondido, ni avanzar el flujo natural de captura.
Síntoma para el usuario: la sensación de hablar con una IA con amnesia.
Por qué fueron difíciles de detectar
Los tres bugs estaban enmascarados unos por otros. Cada uno individualmente parecía el problema central. Si uno solo arreglaba el Bug 1 sin tocar los otros dos, el sistema seguía aparentando “no funcionar igual”. Si arreglaba el Bug 3 sin atender Bug 1, el contador seguía en cero y la directiva no disparaba.
Adicionalmente, ninguno de los tres lanzaba errores explícitos. Los logs de n8n marcaban todo como exitoso. El modelo de lenguaje seguía respondiendo. Las APIs no devolvían fallas. Visualmente, todo parecía estar funcionando — solo que mal.
Este tipo de bugs es característico de los sistemas distribuidos modernos donde múltiples APIs se comunican entre sí. El éxito no es binario, es sistémico. Una pieza puede reportar OK mientras secuestra el comportamiento de toda la cadena.
La solución: tres ajustes quirúrgicos
Una vez identificados los tres bugs, los fixes fueron mínimos en código pero precisos en concepto.
Para el Bug 1 se cambió el método de mapeo del nodo de Google Sheets a uno que no dependiera del esquema cacheado. Esto eliminó la incompatibilidad silenciosa.
Para el Bug 2 se cambió la fuente del contador de turnos. En lugar de leerlo desde Sheets (que estaba vacío), se calculó dinámicamente a partir de la longitud del transcript real de la conversación.
Para el Bug 3 este se resolvió automáticamente al fixear los dos anteriores. Con Sheets escribiendo correctamente y los turnos calculándose bien, el sistema volvió a tener contexto completo en cada turno.
Las cinco pruebas finales
Después de los fixes corrimos cinco escenarios de prueba que simulaban perfiles distintos de prospecto.
Prueba 1. Un lead llega y describe su problema sin preámbulo. ArIA responde directo al problema en lugar de saludar genéricamente. Pasa.
Prueba 2 y 3. Conversación que avanza dos turnos sin que el usuario haya dicho su nombre. ArIA dispara la directiva al tercer turno y pide nombre de forma natural, mezclado en una respuesta de valor. Pasa.
Prueba 4. Usuario describe su negocio en detalle. ArIA captura cuatro datos en flujo natural: nombre, empresa, email y WhatsApp. Sin formularios. Sin interrogatorios. Pasa.
Prueba 5. Usuario pide agendar una llamada. ArIA confirma que tiene los datos mínimos requeridos, consulta Google Calendar en tiempo real para verificar disponibilidad, propone tres horarios reales del director, el usuario elige uno. ArIA crea el evento en Calendar con link de Google Meet automático. Pasa.
Las cinco pruebas pasaron sin intervención manual. La cita real quedó agendada en el calendario del director con un link de Meet activo. Google Sheets registró la conversación completa. El sistema funcionó end-to-end.
Lecciones replicables
Este caso es solo una implementación interna, pero las lecciones aplican a cualquier empresa que esté pensando seriamente en agentes IA para su operación.
Primera lección: el agente solo es la cara visible
Detrás de cada agente IA conversacional que funciona, hay una arquitectura de orquestación, persistencia, observabilidad y validación que pesa diez veces más que el prompt mismo. Si una empresa solo invierte en “el chatbot” pero ignora la arquitectura, va a tener un problema parecido a este — pero sin nadie que lo identifique.
Segunda lección: los bugs silenciosos son el enemigo real
No son los errores explícitos los que rompen sistemas en producción. Son los fallos que se reportan como éxitos. Cualquier proyecto serio de IA conversacional necesita observabilidad granular: logs por nodo, métricas por turno, alertas cuando la persistencia falla en silencio. Sin eso, el sistema funciona “más o menos” durante meses antes de que alguien note que está mal.
Tercera lección: el prompt no es el sistema
Pasamos diez horas afinando el prompt de ArIA. Era un buen prompt — específico, con personalidad clara, con anti-patrones documentados. Pero un buen prompt sobre una arquitectura rota produce el mismo resultado que un prompt malo: nada útil. La calidad de la conversación es el producto, sí, pero la calidad de la conversación depende del 95% que no se ve.
Cuarta lección: probar con escenarios realistas
Las cinco pruebas finales no fueron casos felices. Eran simulaciones de prospectos reales con dudas, presiones, intentos de saltarse el flujo y pedidos fuera de contexto. Solo así se valida que un agente está listo para producción. Probar con “hola, quiero información” es engañarse.
Lo que esto significa para cualquier empresa
Si tu empresa está pensando en agentes IA, la pregunta correcta no es “¿cuánto cuesta el chatbot?”. Las preguntas correctas son:
¿Quién va a operar el sistema cuando un nodo silencioso falle a las 3 AM un sábado? ¿Cómo vas a detectar que un agente está fallando en silencio antes de que pierdas 50 leads sin enterarte? ¿Qué tan rápido se puede iterar el comportamiento del agente cuando el negocio cambia? ¿Qué hace el sistema cuando la API de OpenAI tiene caída? ¿Quién se encarga del prompt cuando empiezan a llegar leads de nuevos sectores?
Implementar un agente IA conversacional para producción real no es un proyecto de tres semanas con un freelancer. Es construir un sistema operativo de tu cara comercial. Requiere arquitectura, observabilidad, mantenimiento continuo y capacidad de iterar sobre datos reales.
Esto es exactamente lo que diferencia entre comprar un chatbot y construir un sistema que vende mientras duermes.
EDM lo construye, lo opera y lo escala
En EDM construimos sistemas como el de ArIA para clientes que necesitan agentes IA en producción real, no demos bonitas. Trabajamos con corporativos como GNP Seguros, SOC Kolbe, CCIMA y con PyMEs serias que ya tienen flujo y quieren escalar.
Si te interesa entender cómo se vería un sistema así para tu negocio, agenda 30 minutos de diagnóstico con nuestro director. Sin pitch genérico. Si no hay match, no firmamos.
Agenda tu diagnóstico · 30 minutos · sin compromiso
Por Alfonso Plascencia, Director de EDM (Estrategia Digital México). 20+ años construyendo sistemas digitales en LATAM. Postgrado en IA Generativa por Universitas Europaea IMF (2026).
