Por qué reemplacé n8n por un agente propio para tareas con estado, HERMES

Empecé automatizando con n8n: WhatsApp, Gmail, algunas tools internas conectadas por webhooks. Funciona bien para lo que n8n fue diseñado — flujos de pasos definidos, disparados por un evento, ejecutados una vez, de principio a fin. El problema apareció en cuanto necesité que el sistema recordara contexto entre mensajes y tomara decisiones distintas según ese contexto acumulado, no según un flujo fijo dibujado de antemano.

Dónde n8n se queda corto

n8n modela automatización como grafo de nodos: A dispara B, B dispara C. Eso funciona perfecto para "cuando llega un email con este asunto, crea una tarea en Asana". No funciona igual de bien cuando la pregunta es "¿qué debería hacer el sistema ahora, dado todo lo que pasó en esta conversación hasta este punto?" — porque esa decisión no es un flujo fijo, es una evaluación dinámica que cambia según el estado acumulado.

Tres límites concretos que encontré:

1. Estado entre ejecuciones. n8n trata cada ejecución de workflow como aislada. Mantener contexto de una conversación de WhatsApp que dura horas o días — quién preguntó qué, qué se resolvió, qué sigue pendiente — significa pelear contra el modelo de ejecución del propio n8n, no usarlo a favor.
2. Decisión dinámica de siguiente paso. Un flujo de n8n define de antemano qué nodo sigue a cuál. Cuando quieres que un LLM decida en tiempo real cuál de N herramientas usar según el contenido del mensaje — no un if/else fijo, sino una decisión genuina basada en razonamiento — terminas construyendo un intérprete de decisiones LLM dentro de un nodo de código, y en ese punto ya no estás usando n8n para lo que sirve, lo estás usando como wrapper de tu propio código.
3. Control fino sobre el contrato de salida. Cuando el output del LLM tiene que cumplir un esquema estricto (para no romper la integración con WhatsApp o Gmail downstream), necesitas capas de validación y reintento con contexto del error — lógica que en n8n vive dispersa entre nodos de función, difícil de testear y de versionar como una unidad coherente.

Por qué construí Hermes en vez de forzar n8n

Hermes es un agente persistente corriendo en EC2, con:

• Catálogo cerrado de tools vía MCP (WhatsApp en modo self-hosted, Gmail por OAuth, herramientas internas), en vez de nodos sueltos conectados por webhooks.
• Contrato estricto de entrada/salida: el LLM (deepseek-v4-flash vía OpenRouter) responde dentro de un esquema validado, con reintento automático si no cumple.
• Estado persistente de conversación, no ejecuciones aisladas — el agente sabe qué pasó antes en el mismo hilo de WhatsApp.

La diferencia de fondo: n8n orquesta pasos que tú ya decidiste de antemano. Hermes decide el próximo paso en tiempo real, dentro de límites que tú definiste (el catálogo de tools, el esquema de salida), pero sin que tú hayas dibujado el grafo completo por adelantado.

Cuándo SÍ usaría n8n

Si la tarea es de verdad un flujo fijo — "cuando pase X, siempre haz Y, sin variación" — n8n sigue siendo la opción más rápida de montar y mantener. El error habría sido forzar a n8n a hacer razonamiento dinámico con estado. Ahí es donde vale la pena construir algo propio, no antes.

Resumen para copiar y pegar

1. n8n = flujos fijos, disparo → pasos predefinidos → fin. Excelente para eso.
2. Estado persistente + decisión dinámica de siguiente paso = necesitas un agente, no un workflow tool.
3. Contrato de esquema + validación + reintento es más fácil de mantener como código propio que disperso en nodos de función.
4. No reemplaces n8n por capricho — reemplázalo cuando el flujo deja de ser un flujo y se vuelve una decisión.