n8n: cómo construir agentes de IA que no fallen en producción

Por qué los agentes de IA fallan cuando «corren mucho»

El equipo de n8n publicó esta semana una serie que se aleja del prompt engineering y entra en un terreno que la mayoría de founders ignora hasta que su agente empieza a fallar en producción: el diseño del harness, es decir, la capa de software que rodea al modelo y decide cuándo, cómo y con qué estado se ejecuta cada llamada.

La tesis central es incómoda pero útil: cada vez que le pides a un LLM que se evalúe a sí mismo, que resuma su propio contexto o que decida mid-task cuándo comprimir la conversación, estás añadiendo un punto de alucinación y drift. La solución no es mejor prompting; es tratar al agente como cualquier pieza de software y diseñar su lógica operativa de forma determinista.

Esto importa a founders hispanohablantes porque la conversación en español sobre agentes suele centrarse en qué modelo usar. El artículo de n8n recuerda que el problema casi nunca es el modelo: es lo que rodea al modelo.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Qué es un «harness» de agente y por qué cambia la conversación

Un harness es la capa que gestiona:

El ciclo de vida del contexto (qué entra y qué sale de la ventana)
La persistencia del estado entre llamadas
La programación de reintentos y recovery
La validación de cada paso antes de darlo por bueno

El propio n8n es un buen ejemplo de cómo ha crecido esta categoría. La empresa berlinesa levantó una Serie C de US$180M en octubre de 2025 con valoración de US$2.500M, según Wikipedia, y en mayo de 2026 SAP tomó una participación estratégica que elevó esa valoración a aproximadamente US$5.200M, lo que la convirtió en la AI company alemana más valiosa por esa métrica. En el mismo período, n8n añadió más de 112.000 estrellas de GitHub en 2025 y superó a Zapier y Make en flexibilidad para construir flujos con nodos, según la cobertura de JavaScript Rising Stars recogida por Wikipedia.

La cifra que importa para un founder: la categoría de durable execution (la capacidad de un agente de recuperarse de fallos sin perder estado) dejó de ser nicho. DBOS, una de las plataformas que el artículo de n8n menciona como referencia, anunció en agosto de 2026 la concesión de la patente estadounidense US 12,625,863 B1 sobre «Database-Centric Operating System for Durable Workflow», reportó Yahoo Finance. DBOS afirma ejecutar «miles de millones de workflows por mes» entre cientos de clientes, desde startups AI-native hasta empresas Fortune 100, y nombrar CEO a su cofundador Qian Li y CTO a Peter Kraft.

Las tres palancas del diseño de agentes duraderos

El artículo organiza la discusión en tres partes que cualquier founder puede mapear contra su producto.

1. Contexto y memoria: la ventana no es gratis

Cada prompt que envías al LLM reenvía toda la conversación. La experiencia tipo chat es una UI, una «ilusión de usuario». Esto tiene tres consecuencias prácticas:

Llegas al límite de tokens y el modelo empieza a truncar
Aparece el llamado context rot: el modelo se descentra conforme la ventana crece
Puedes masajear el contexto dentro de la ventana para mantenerlo denso

La solución pasa por gestionar el ciclo de vida del contexto con cuatro operaciones:

Crear y entender: qué tokens entran y por qué. Herramientas como el Context Usage Meter de Gumloop muestran en tiempo real qué categoría (system, tools, conversation, subagents…) está consumiendo la ventana.
Comprimir: eliminar tokens irrelevantes y resumir bloques en versiones semánticamente equivalentes. Google ADK Context Compaction resume eventos antiguos cuando se supera un umbral de invocaciones.
Persistir: escribir el contexto en almacenamiento durable. Los ledgers inmutables (append-only) son el patrón recomendado, porque permiten escribir y leer pero no modificar ni borrar.
Recuperar: usar el ledger como mecanismo de reconstrucción al iniciar una sesión nueva, en lugar de replay de toda la conversación.

2. Ejecución durable: que el agente sobreviva al crash

Un agente de larga duración no corre durante mucho tiempo seguido. Corre cuando hace falta, registra lo que hizo y se vuelve a dormir. La pregunta clave pasa a ser qué persiste entre llamadas.

Según el patrón descrito por Cloudflare y citado en el artículo, persiste:

El estado del agente y las tablas SQLite creadas
Las tareas programadas (que disparan alarmas para despertarlo)
Los estados de conexión WebSocket

No necesita persistir: variables en memoria, timers activos, llamadas HTTP abiertas, cadenas de promesas.

Las herramientas que materializan este patrón son DBOS, Restate e Inngest, cada una con un enfoque distinto (anotaciones en código vs. capa de orquestación separada). Restate persiste cada paso antes de avanzar y hace replay determinista; DBOS hace checkpoints en Postgres. El artículo también menciona la posibilidad de construir lógica de durable execution sobre n8n usando sus triggers deterministas (schedules y webhooks) y almacenamiento persistente.

3. Progreso de tareas y evaluación: el truco del checklist

Aquí aparece la pregunta que más cuesta responder en producción: ¿está el agente todavía en camino o se ha ido por la deriva?

El atajo fácil es pedirle a otro LLM que lo evalúe (LLM-as-judge). El artículo lo descarta porque es el mismo tipo de modelo cometiendo el mismo tipo de error, un nivel más arriba.

La alternativa es definir criterios de completitud antes de que el agente empiece y validar con puertas deterministas que devuelven un booleano, no con opinión generativa. Taxonomía útil, de más barata a más completa:

Códigos de estado (¿la API devolvió 200?)
Validación de esquema (¿el JSON parsea con los campos esperados?)
Consistencia cross-field (¿el username devuelto coincide con el solicitante?)
State-diff (¿el recurso realmente cambió al re-consultar?)
Tests unitarios o de integración contra el cambio

Otras técnicas complementarias: máquinas de estados finitos para validar secuencias legales de tool calls, sandboxing para observar el comportamiento antes de producción y convertir acciones observadas en allowlists deterministas, clasificadores no generativos (DeBERTa, RoBERTa, ModernBERT) para veredictos binarios sin modelo generativo en el loop, y detección de anomalías en patrones de tool calls (loops recursivos, picos de tokens, ejecuciones fuera de orden).

Si necesitas un LLM como juez, el artículo recomienda reducirlo a un rol estrecho y comprobable, como «este trace encaja en la categoría X de la taxonomía» — un compilador difuso de comportamiento contra categoría determinista, no un generador de «bueno»/»malo».

El nuevo riesgo: el agente como vector de ataque

El cambio de paradigma tiene un lado oscuro que se materializó este mismo año. CSO Online reportó en julio de 2026 que el investigador Pillar Security descubrió vulnerabilidades en los flujos automatizados del repositorio GitHub de Google ADK para Python: instrucciones maliciosas en un pull request público podían inducir al agente a publicar comandos que disparaban workflows reservados para usuarios confiables, extraer tokens y manipular aprobaciones. Pillar lo describió como «el primer caso práctico real de explotación agent-to-agent en un sistema multi-agente en producción».

La implicación para founders es directa: cuando diseñas un harness, la autoridad se mueve por la salida del agente, no solo por las herramientas que le asignas. Como sintetizó Sanchit Vir Gogia, analista jefe de Greyhound Research, «el lenguaje natural se ha unido al camino de autorización». Si tu agente puede alterar algo que otro sistema ya confía, tienes un agujero, aunque Agent A nunca llame directamente a Agent B.

¿Qué significa esto para tu startup?

Tres cambios de mentalidad que puedes aplicar esta semana sin reescribir tu stack.

Separa «modelo» de «agente». Un modelo convierte texto en texto. Un agente ejecuta acciones. El fallo más caro es tratar al LLM como si fuera todo el sistema. Dibuja el diagrama de tu agente: qué es determinista (schedules, validaciones, retries) y qué pasa por el modelo.
Diseña el criterio de «hecho» antes de que el agente empiece. Por cada paso de tu flujo, escribe una frase que diga cuándo está terminado y conviértela en una validación booleana sobre el log de ejecución o el estado del sistema. Si la única forma de saberlo es pedirle al modelo que opine, rediseña el paso.
Convierte tu almacenamiento en ledger append-only. No le pidas al LLM que «no actualice el registro». Eso no es ingeniería. Provisiona tú el storage, define los permisos deterministamente y trata cada entrada como inmutable. Es la diferencia entre un agente que se recupera y un agente que pierde la cabeza cada vez que se reinicia.