Un agente de n8n recibió 200 OK, pero el cliente vio un chat vacío: análisis del bug del silencio

Nodos en verde, 200 OK de Meta y un chat vacío para la clienta. Así se presenta el segundo «bug del silencio» en un agente de IA sobre n8n, al que está dedicado un nuevo análisis en Habr. Es la segunda historia de este tipo que cuenta el autor, y la formulación deja clara la clave: el sistema creía haber cumplido, pero la persona se quedó sin respuesta. El anuncio es breve, así que a continuación solo se recoge lo que declara, junto con los mecanismos generales por los que esto suele ocurrir en agentes para mensajería.

Qué se sabe del análisis

El anuncio aporta pocos datos, pero son reveladores. El workflow de n8n se ejecutó sin errores: todos los nodos se pusieron en verde. La solicitud a la API de Meta devolvió 200 OK. Aun así, la usuaria no vio la respuesta del agente y el chat estaba vacío. El anuncio no precisa qué canal se utilizó ni en qué punto de la cadena desapareció el texto. Los detalles quedan en la versión completa del artículo en Habr.

Para los agentes de IA, este es el tipo de fallo más incómodo. No hay excepción, no salta ninguna alerta y los logs están limpios. La única forma de enterarse del problema es por el propio cliente, si no se ha marchado antes.

Dónde suele esconderse el silencio

Este síntoma tiene varias causas habituales. No se sabe cuál de ellas se dio en este caso, pero todas producen la misma imagen: «todo en verde y sin respuesta».

• Un código 200 significa recepción, no entrega. Las API de mensajería suelen aceptar el mensaje en una cola e informan del resultado de la entrega más tarde, mediante webhooks de estado independientes.
• Salida vacía o corrupta del modelo. Un LLM puede devolver una cadena vacía, un JSON truncado o un marcador de servicio en lugar de texto. Para n8n son datos válidos, y el nodo de envío trabaja con normalidad.
• Restricciones de la plataforma. Los servicios de mensajería tienen ventanas de respuesta, requisitos de plantillas y reglas de moderación. Un mensaje puede ser aceptado y, aun así, no mostrarse al usuario.
• Campo incorrecto en la expresión. Si el nodo de envío toma el texto de una ruta que no existe en los datos, n8n sustituye el valor por uno vacío sin lanzar ningún error.
• Condiciones de carrera y duplicados. Los webhooks repetidos, las ejecuciones paralelas y la memoria compartida de la conversación pueden sobrescribir la respuesta antes de que salga.

Todos estos puntos tienen algo en común: el éxito se mide en el lado de la infraestructura, no en el de la persona.

Cómo detectar estos bugs

Lo primero que conviene hacer es añadir una comprobación del contenido antes del envío. Un simple nodo de filtro que descarte la cadena vacía, el texto demasiado corto o el que contenga marcadores de servicio cierra toda una clase de errores. Si la comprobación falla, el workflow debe desviarse a la rama de error en lugar de seguir su camino en verde.

Segundo: no tratar el 200 OK como el final. Los estados de entrega recibidos por webhook hay que guardarlos y cotejarlos con los mensajes salientes mediante su identificador. Cualquier mensaje sin confirmación de «entregado» pasado un tiempo determinado se convierte en un incidente.

Tercero: introducir una métrica a nivel de conversación. La proporción de mensajes entrantes a los que no ha salido ninguna respuesta no vacía en N segundos refleja el estado real del agente mejor que la estadística de ejecuciones exitosas. También sirve de base para una alerta en el chat de trabajo del equipo.

Cuarto: configurar un Error Workflow en n8n y un fallback independiente. Si el agente calla, el cliente recibe un breve «Hemos recibido su mensaje y le responderemos en breve», y el operador recibe una notificación con el contexto de la conversación.

Quinto: ejecutar conversaciones sintéticas. Una cuenta de prueba que escriba periódicamente al agente y espere la respuesta detecta el silencio antes que las personas reales. Para un negocio en el que el chat con el bot es el principal canal de ventas o soporte, esta comprobación cuesta menos que una sola solicitud perdida.

La historia de Habr ilustra bien una lección general sobre la operación de agentes: la fiabilidad la determina lo que ve el usuario, no lo que muestra el panel del orquestador.