Cualquiera puede montar n8n. Casi nadie sabe decirte dónde se queda corto. Ese hueco es justo el trabajo. La automatización de verdad son tres capas, no una herramienta, y la capa que casi todo el mundo construye es la tercera, la fácil. Nosotros corremos las tres en producción, en nuestros propios sistemas y para clientes, y el valor nunca estuvo en la parte que todos ya tienen.
n8n tuvo un año raro. En octubre de 2025 la empresa levantó 180 millones de dólares y cruzó una valoración de 2.500 millones, partiendo de 300 millones cuatro meses antes. Hoy lo usan unas 230.000 personas, tres cuartas partes con los nodos de IA. Cada segundo post de automatización en LinkedIn es un canvas de n8n con un par de cajas y una flecha. La herramienta se ganó el hype. Es genuinamente buena, se puede auto-hospedar y se conecta a casi todo.
Y ahí es justo donde la mayoría de los proyectos de automatización se quedan, en silencio. Alguien monta n8n, cablea un webhook a un mensaje de Slack, lo llama estrategia de automatización y pasa a otra cosa. Funciona hasta que el workflow tiene que tomar una decisión de criterio, o hasta que tiene que sobrevivir cuatro días y un reinicio de servidor sin perder el hilo. Entonces el canvas visual se queda sin camino, y la gente que solo conoce el canvas se queda sin camino con él.
Lo que la automatización necesita de verdad
Quita las herramientas y debajo de toda automatización seria hay tres trabajos. Son problemas distintos, y una herramienta que hace uno bien suele hacer los otros dos mal.
El primer trabajo es conectar cosas. Entra un registro, va un dato al CRM, sale un correo de bienvenida, aterriza una notificación en el móvil de alguien. No hace falta pensar, solo fontanería fiable entre sistemas que nunca se diseñaron para hablar entre ellos. Esto es el grueso de la automatización por volumen, y es el trabajo para el que se construyó n8n.
El segundo trabajo es tomar una decisión de criterio. El workflow tiene que leer algo ambiguo, decidir qué significa y elegir el siguiente paso a partir de esa decisión. Llega un correo y el sistema tiene que juzgar si es un lead real o ruido, y luego enrutar según eso. Se revisa un borrador y el sistema tiene que decidir si está lo bastante bien como para publicarse o si necesita otra pasada. Esto no es fontanería. Esto es razonar, y necesita otro tipo de herramienta.
El tercer trabajo es sobrevivir en el tiempo. Algunos workflows corren durante horas o días. Esperan a que una persona apruebe algo. Llaman a seis servicios externos, cualquiera de los cuales puede fallar, y un fallo a medias no debe corromper a los otros cinco. Si la máquina se reinicia en el paso cuatro de siete, el trabajo tiene que reanudarse desde el paso cuatro, no empezar de cero. Esto es durabilidad, y es el más difícil de los tres de fingir.
Estos tres trabajos son ortogonales. Una herramienta que intenta ser los tres a la vez acaba mediocre en cada uno. Un stack que elige al especialista correcto para cada capa le gana al todo-en-uno siempre. Nuestros tres especialistas son n8n, LangGraph y Temporal.
n8n: la capa que todo el mundo ya tiene
n8n es la capa de conexión, y para ese trabajo es excelente. Más de 400 integraciones prefabricadas, un canvas visual que alguien que no es ingeniero puede leer de verdad, auto-hospedaje en menos de media hora. Lo corremos como el hub de automatización para el trabajo sin glamour que mantiene a un negocio en marcha. Un webhook de registro que crea un lead en el CRM y dispara un correo de bienvenida. Un post de blog nuevo que se reparte en borradores de posts sociales. Un health check programado que pinga una fila de servicios y avisa a un canal cuando uno se queda callado. Un correo entrante que se parsea por intención antes de que lo toque una persona.
Esto es valor real y quiero dejarlo claro. n8n no es un juguete y no es Zapier para power users. Es una plataforma de orquestación seria, con licencia justa, auto-hospedable, y para conectar sistemas suele ser la respuesta correcta más rápida. Si un cliente necesita que su equipo de operaciones edite un workflow sin un ciclo de despliegue, el canvas visual gana por méritos propios.
La honestidad empieza cuando miras lo que n8n no es. Corre los pasos en secuencia por defecto, así que el trabajo paralelo de verdad con state compartido se vuelve frágil rápido. La gente reporta merge nodes que fallan un pequeño porcentaje de las veces por race conditions que sencillamente no existen en código controlado. No es una máquina de estados con replay determinista, así que un crash a media ejecución no se reanuda limpio. No hay testing de primera clase. Y en cuanto un workflow necesita algo fuera de lo común, te metes en un Code node, y el Code node es donde los workflows de n8n acumulan en silencio la deuda técnica que nadie puso en el canvas. Nada de esto es un defecto. Es solo el borde de la capa. El error no es usar n8n. El error es creer que el canvas es el mapa entero.
LangGraph: cuando el workflow tiene que pensar
Cuando un workflow tiene que razonar en vez de solo enrutar, echamos mano de LangGraph. Es un framework code-first del equipo de LangChain que modela un workflow como un grafo de pasos donde el modelo de lenguaje, no un diagrama fijo, decide qué pasa después. Desde que salió LangChain 1.0, los propios agentes de LangChain corren sobre LangGraph por debajo, y la lista de usuarios en producción es un quién es quién, con Uber, LinkedIn, Klarna y Replit en ella.
Las dos características que le ganan su sitio son el state y la pausa. State significa que el workflow recuerda dónde está. Cada paso queda con checkpoint en una base de datos, así que un crash en el paso tres se reanuda en el paso tres en vez de quemar la ejecución entera. La pausa significa que el workflow puede pararse a la mitad, esperar a que una persona apruebe o corrija algo, y luego seguir con esa respuesta incorporada. En LangGraph esto es una primitiva, no un sistema paralelo construido a mano.
Una forma concreta que corremos sobre él: un pipeline de agente multi-paso donde un paso redacta un plan, el siguiente construye contra él, un tercero revisa el resultado y un cuarto lo prueba, con una puerta de aprobación que pausa todo el asunto para una persona cada vez que la revisión vuelve con dudas. Eso es razonamiento más checkpoints más human-in-the-loop, la combinación exacta para la que existe LangGraph y la combinación exacta que el canvas de n8n cuesta expresar sin sub-workflows anidados y trucos de polling.
El compromiso es real y vale la pena decirlo en voz alta. LangGraph es exagerado para un workflow que solo llama a un modelo y publica el resultado en algún sitio. Échale mano demasiado pronto y habrás escrito doscientas líneas de código de framework donde cincuenta líneas de lógica plana se habrían leído más claras. También arrastra una licencia propietaria, que es un riesgo de lock-in que gestionamos a propósito en vez de ignorarlo. La disciplina está en usarlo solo donde el razonamiento y la reanudación de verdad pagan el peso extra.
Temporal: cuando al workflow no se le puede permitir morir
La tercera capa es la que casi nadie del mundillo de n8n ha oído siquiera, y es la que separa un montaje de hobby de la infraestructura. Temporal es un motor de durable execution. Graba cada paso de un workflow como un historial de eventos, así que cuando un servidor crashea levanta un worker fresco, reproduce el historial hasta el estado exacto previo al crash y sigue como si nada hubiera pasado. Los workflows pueden correr durante días o años. Es open source bajo licencia MIT, y se ha vuelto en silencio el estándar para la durable execution de agentes. OpenAI corre Codex sobre él en producción, para agentes que esperan días una aprobación humana y sobreviven a reinicios sin perder el hilo.
Lo que esto desbloquea es la clase de workflow que toca el mundo real y no se puede permitir quedar a medias. Un ciclo de facturación donde una suscripción se renueva, se cobra un pago, y un reembolso tiene que deshacer una cadena de efectos secundarios limpiamente si un paso falla. Un onboarding de cliente que corre durante varios días con temporizadores y esperas integrados. Un trabajo recurrente que agrega trabajo de muchas fuentes y tiene que completarse de forma fiable cada vez. Estas son sagas, transacciones de larga duración con compensación cuando algo se rompe, y son exactamente lo que un canvas visual nunca se pensó para sostener.
Hay una regla práctica limpia en la que el campo ha convergido, y la usamos. Si una tarea es un único paso de solo lectura por debajo de 30 segundos, no necesitas nada de esto. En el momento en que un workflow hace tres o más llamadas externas, espera horas a un evento, o dispara acciones irreversibles como pagos o borrados, la durabilidad deja de ser opcional. Publicamos un conjunto de plantillas de durable workflow como open source para que el patrón no sea una caja negra, disponibles en github.com/studiomeyer-io/temporal-memory-workflows. El coste de Temporal es overhead operativo y unas cuantas reglas sobre cómo escribes el código, que es justo por lo que no le echas mano por debajo del umbral.
Cómo encajan las tres capas
La trampa es preguntar qué herramienta gana. ¿Cuál de las tres gana? Ninguna, porque no están jugando al mismo juego. n8n conecta sistemas y dispara cosas. LangGraph razona y pausa para las personas. Temporal garantiza que el trabajo largo e importante termina. En un montaje maduro se apilan: n8n caza el evento y hace el pegamento, le pasa el pensar a un agente de LangGraph, y envuelve cualquier cosa de larga duración o irreversible en un workflow de Temporal para que un crash sea un no-evento. El lado de observability de esa misma arquitectura, vigilar lo que cada capa hizo de verdad, es una disciplina propia que cubrimos aparte en nuestro artículo sobre el stack de observabilidad de agentes.
El hábito más importante de todos en las tres capas es mantener tu lógica de negocio real fuera del framework. Las reglas de tu dominio viven en código plano y testeado que cualquiera de estas herramientas simplemente llama. Hazlo y cambiar un workflow de una capa a otra es un día de trabajo, no una reescritura, porque la parte que importa nunca dependió de la herramienta. Sáltatelo y te casas con el canvas con el que empezaste, que es como los equipos acaban atrapados dentro de un workflow de n8n que debería haber graduado a código hace un año.
El montaje es un commodity. La arquitectura no.
Aquí está la parte que el mercado entiende al revés. Montar n8n es un commodity ahora. Hay miles de personas que te dibujan un canvas, y el precio de ese trabajo está cayendo porque la herramienta lo hizo fácil, que era todo el punto. Si lo único que compras es el montaje de n8n, compraste la capa que ya era la más barata de construir.
El valor está en las dos decisiones que nadie te vende. Primera, saber cuál de las tres capas necesita de verdad un problema dado, y tener el criterio para resistir los dos modos de fallo: meter a presión un problema de razonamiento en un Code node de n8n hasta que se pudre, y sobre-ingeniar un trabajo de cincuenta líneas en un durable workflow que nunca necesitó. Segunda, construir la frontera tan limpia que la elección siga siendo barata de revisitar. Eso es arquitectura, y no aparece en una captura de pantalla de un canvas.
Hay una cosa más que vale la pena ser honesto al respecto. Lo que corre nuestros propios sistemas internos es deliberadamente pragmático, afinado para ser lo bastante bueno para una operación de una sola persona que conoce sus propios bordes. Un encargo de cliente recibe la otra marcha por completo, las mismas tres capas pero con el endurecimiento, las puertas de gobernanza antes de las acciones de riesgo, la observability y el testing que un sistema del que depende otra persona necesita de verdad. Saber la diferencia entre lo que nos basta a nosotros y lo que es correcto para un cliente es en sí parte de dominar el stack. Cualquiera puede correr las herramientas. Saber hasta dónde llevarlas es el trabajo.
Así que la próxima vez que veas un pitch de automatización que empieza y termina con n8n, la pregunta a hacer no es si el canvas es bonito. Es qué pasa en los dos bordes que el canvas no muestra, cuando el workflow tiene que pensar y cuando tiene que sobrevivir. Si quieres ese stack entero diseñado como debe ser y no solo la tercera parte fácil, esa es la conversación que tenemos.
