Migrar de n8n a Bentho: escalar cargas agénticas en producción

No estás aquí porque n8n sea malo. Estás aquí porque los flujos que mueven datos siguen yendo bien y los que tienen un modelo dentro han empezado a despertar a alguien de madrugada.

Esta guía mueve los segundos y deja en paz a los primeros. Cada paso es reversible hasta el último, y el último es una lista de comprobación, no un salto.

1. Por qué n8n se queda corto con agentes LLM en producción

n8n ejecuta un flujo como una ejecución dentro de un proceso, sosteniendo los datos de todos los nodos que ha recorrido. Ese diseño es el correcto para mover registros entre servicios, y es justo lo que se dobla cuando un paso es un agente: la llamada es larga, la carga es grande y la salida no es predecible.

Tres valores por defecto documentados describen la forma de ese techo. Son valores por defecto, no leyes — comprueba los tuyos antes de citárselos a nadie:

• EXECUTIONS_MODE llega como regular: sin tocarlo, los flujos corren dentro del propio proceso principal.
• EXECUTIONS_TIMEOUT llega como -1, o sea sin tope ninguno. El techo que un usuario puede fijarle a un flujo concreto es EXECUTIONS_TIMEOUT_MAX, 3600 segundos.
• Escalar en horizontal significa modo cola, y el modo cola significa Redis, una base de datos que persista (PostgreSQL recomendada; SQLite no está soportada) y varias instancias compartiendo N8N_ENCRYPTION_KEY.

Lee las tres juntas y el problema se enuncia solo: añadir workers multiplica cuántas ejecuciones caben a la vez, no cuánto puede durar una ni cuánto puede sostener en memoria. Un worker ejecutando un agente sigue siendo un proceso cargando con la conversación entera.

2. Mapa de migración: de nodos a herramientas tipadas

La unidad de migración no es el flujo. Es la autoridad: lo que sabe la respuesta de verdad —precios, stock, tarifas de envío, estado de un pedido—. En n8n ese conocimiento está repartido entre nodos y expresiones; en Bentho pasa a ser una herramienta con firma.

Las herramientas van montadas junto a las rutas REST que ya existen, así que un consumidor puede moverse de uno en uno. No hay que apagar nada para que la primera funcione.

3. Sacar el trabajo de la ejecución

Dos cosas tienen que salir del proceso de ejecución, y son problemas distintos:

1. La espera. Un paso que se bloquea durante minutos ocupa una ranura y todo lo que ha acumulado. En cuanto el trabajo es una petición a un servicio que responde a su ritmo, el flujo deja de ser lo que tiene que seguir vivo.
2. El estado. La memoria de una conversación dentro de una ejecución muere con ella y crece con ella. Fuera del proceso pertenece a la sesión y sobrevive a un reinicio.

Hay un tercero, más callado: lo que n8n guarda de las ejecuciones pasadas. EXECUTIONS_DATA_PRUNE llega activo, con una ventana de 336 horas y 10000 ejecuciones conservadas — razonable para registros, pesado cuando cada ejecución arrastra cargas de modelo. Compruébalo antes de concluir que el problema es la base de datos.

4. Pre-validación y dual-run, antes de apagar nada

Esta es la parte que se salta todo el mundo, y es la única que hace seguro el resto. No hagas cutover. Corre los dos, compara, y deja que la comparación decida.

1. Congela el contrato primero. Escribe qué recibe y qué devuelve cada herramienta extraída, con tipos. Si no se puede escribir, no está lista para moverse.
2. Reproduce tráfico real. Dale las mismas entradas a los dos sistemas. No sintéticas: las cargas que ya rompieron algo son las que valen.
3. Compara salidas, no códigos de estado. Dos ejecuciones en verde que discrepan en una cifra es el fallo que toda esta migración existe para atrapar.
4. Primero en sombra, después repartido. Bentho responde en paralelo sin que nadie lo vea, hasta que las diferencias sean aburridas. Solo entonces se mueve una parte del tráfico real.
5. Mantén n8n caliente. Reversible significa que el camino viejo sigue corriendo, no que podrías reconstruirlo.

5. Lista de comprobación del apagado

1. Cada herramienta extraída tiene su firma escrita y su entrada validada en la frontera.
2. El dual-run lleva puesto un ciclo de negocio completo, cierre de mes incluido.
3. La diferencia entre salidas está EXPLICADA, no solo es pequeña. Un patrón que no sabes explicar es un fallo que no has encontrado.
4. La vuelta atrás es un interruptor, y alguien que no eres tú lo ha usado en un simulacro.
5. Las alertas apuntan al camino nuevo, y a la diferencia entre los dos.
6. El flujo de n8n queda desactivado, no borrado, y sus credenciales se rotan en una fecha que escribiste.

6. Errores comunes al reemplazar el nodo AI Agent

• Recrear el grafo uno a uno. Si el sistema nuevo tiene las mismas ramas dibujadas en código, moviste el problema y encima pagaste la mudanza.
• Dejar que el modelo siga decidiendo. La idea es que decida el código y el modelo extraiga, con temperatura 0. Un prompt que devuelve «el siguiente paso» es el nodo AI Agent otra vez, con pasos de más.
• Reintentar una respuesta mala. Un reintento a ciegas sobre un paso no determinista es la misma apuesta, pagada dos veces. Una cifra sin respaldo se descarta, no se vuelve a tirar el dado.
• Migrar los flujos que ya funcionan. Los que no tienen un modelo dentro no son el problema, y moverlos gasta la confianza que vas a necesitar.
• Apagar antes del cierre de mes. Lo que vaya a discrepar, discrepará el día de más trabajo.

De dónde salen las cifras de n8n

Los valores por defecto de n8n que se citan arriba salen de su propia documentación. Cambian entre versiones, así que tómalos como punto de partida y mira lo que dice tu instalación.

• executions — EXECUTIONS_TIMEOUT viene por defecto en -1, que desactiva el tope: una ejecución puede durar lo que dure. EXECUTIONS_TIMEOUT_MAX —el máximo que un usuario puede fijarle a un flujo— viene en 3600 segundos.
• executions — EXECUTIONS_MODE acepta regular o queue y viene por defecto en regular: sin tocarlo, los flujos se ejecutan dentro del propio proceso principal.
• enable-queue-mode — Escalar en horizontal exige el modo cola, y con él Redis como intermediario, una base de datos que persista —PostgreSQL recomendada, SQLite NO soportada— y varias instancias compartiendo N8N_ENCRYPTION_KEY. La concurrencia de cada worker es 10 por defecto, y n8n recomienda no bajar de 5.
• executions — EXECUTIONS_DATA_PRUNE viene activo, con EXECUTIONS_DATA_MAX_AGE en 336 horas y EXECUTIONS_DATA_PRUNE_MAX_COUNT en 10000 ejecuciones conservadas.

Consultado en la documentación de n8n el 2026-09-24. Puede haber cambiado desde entonces: si vas a tomar una decisión con alguno de estos datos, míralo en el tuyo.