Perdí tres sesiones completas de trabajo antes de entender que el problema no era lo que creía. El agente escribía perfectamente — solo que en el lugar equivocado.
Ese es el tipo de error que no aparece en los logs como error. El pipeline termina con status 200. La página de Notion existe. Todo parece funcionar hasta que abres la página y el body está vacío.
El sistema que estoy construyendo
La Corporación Olave Ruiz es un experimento deliberado: un humano más catorce agentes de IA construyendo una empresa funcional. No es una demo. No es un caso de estudio académico. Es el negocio real, ejecutándose en producción, con n8n como motor de orquestación 24/7.
El pipeline tiene nombre y secuencia: Pepper recibe el input inicial, Wags evalúa la estrategia, Oracle investiga, Saul define la marca, Steve redacta el PRD, Ive diseña, Logan planifica, Neo implementa, y así hasta el final de la cadena. Cada agente es un nodo en n8n con acceso a herramientas específicas. Cada uno tiene un contexto acotado y una responsabilidad única.
En teoría, es elegante. En la práctica, es donde vive el diablo.
n8n superó los 230.000 usuarios activos a fines de 2025 y alcanzó 40 millones de dólares en ARR. El 75% de esa base usa herramientas de IA integradas (Sacra, Flowlyn, 2025). El ecosistema creció más rápido de lo que el tooling pudo acompañar, y esa brecha entre adopción y madurez técnica es exactamente donde ocurren los errores que documenté durante semanas.
El primer problema: max_tokens ya no existe
El primer síntoma fue una respuesta truncada. El agente Oracle — el investigador del pipeline — devolvía análisis cortados a la mitad. Aumenté el valor de max_tokens en el nodo de n8n. No cambió nada. Lo subí de 1500 a 4096. Mismo resultado.
El problema era anterior al valor. Era el parámetro mismo.
Algunos modelos de OpenAI migraron de max_tokens a max_completion_tokens. La API rechaza el parámetro antiguo con un error 400, pero n8n en algunas versiones no propagaba ese error de forma visible — el nodo simplemente devolvía una respuesta vacía o parcial sin indicar la causa. El fix llegó con el PR #18213 del repositorio n8n-io/n8n, pero si tu instancia no estaba actualizada, el comportamiento era silencioso y confuso.
La solución fue directa una vez identificada: actualizar n8n y reemplazar el parámetro en los nodos afectados. Pero el tiempo perdido antes de llegar ahí fue real.
El segundo problema: el contexto que crece solo
El error de parámetro fue molesto pero localizado. El siguiente problema era estructural.
Los agentes en n8n con loops acumulan historial. Cada iteración agrega el registro de tool calls anteriores al contexto. En la iteración 1, el agente tiene 4.000 tokens de contexto. En la iteración 5, tiene 40.000. En la iteración 9, el modelo responde con esto:
This model’s maximum context length is 128,000 tokens. However, your messages resulted in 192,821 tokens.
No es el límite de tokens de salida. Es el de entrada acumulada. La distinción importa porque cambiar max_tokens no resuelve nada aquí — el problema no es cuánto puede responder el modelo, sino cuánto está ingiriendo.
La comunidad de n8n ya documentó este patrón. Con cargas de 140.000 tokens por request, el error 429 es frecuente. Hay reportes explícitos de que 768 filas de datos en una sola llamada es “a ton for a model” (community.n8n.io). El crecimiento no es lineal si el agente tiene más de tres o cuatro herramientas activas — cada tool call agrega su propio JSON al historial, y el contexto escala rápido.
La solución que validé: sub-agentes especializados con contexto limpio. El agente coordinador delega a sub-agentes acotados que no heredan el historial del loop principal. Cada sub-agente empieza desde cero, hace su tarea, devuelve el resultado estructurado, y termina. El coordinador recibe el output, no el proceso.
Esto obliga a ser muy explícito sobre qué información necesita cada sub-agente para operar — lo que en la práctica mejora la arquitectura entera, no solo el problema de tokens.
El tercer problema: Notion tiene dos superficies y los LLMs solo ven una
Este fue el más costoso. Y el más difícil de detectar porque el sistema no fallaba — producía resultados plausibles pero vacíos.
La Notion API expone dos superficies distintas para cada página. Las properties son los metadatos: título, fecha, estado, etiquetas, cualquier campo de la base de datos. Los children son los bloques de contenido: párrafos, encabezados, listas, el body de la página.
Cuando un agente LLM recibe la instrucción “crea una página en Notion con este contenido”, tiende a mapear todo a properties. El resultado es una página con título correcto, fecha correcta, estado correcto — y sin una sola línea de texto en el cuerpo.
El JSON que el agente generaba se veía así:
{
"parent": { "database_id": "abc123" },
"properties": {
"title": { "title": [{ "text": { "content": "Análisis de mercado" } }] },
"summary": { "rich_text": [{ "text": { "content": "El contenido completo del análisis..." } }] },
"status": { "select": { "name": "Draft" } }
}
}El campo summary en properties no es el body. Es un campo de metadato. El cuerpo real requiere una clave children al nivel raíz del payload, con bloques tipados:
{
"parent": { "database_id": "abc123" },
"properties": {
"title": { "title": [{ "text": { "content": "Análisis de mercado" } }] },
"status": { "select": { "name": "Draft" } }
},
"children": [
{
"object": "block",
"type": "paragraph",
"paragraph": {
"rich_text": [{ "text": { "content": "El contenido completo del análisis..." } }]
}
}
]
}Sin instrucciones explícitas sobre esta distinción, el LLM no la infiere. No porque no pueda — sino porque la instrucción general de “escribe en Notion” es ambigua respecto a dónde. La API de Notion no es intuitiva en este punto: es perfectamente posible crear una página sin children y obtener un 200 de respuesta. El error no existe. La página existe. El contenido, no.
La solución fue agregar una sección explícita al system prompt de los agentes que interactúan con Notion, describiendo la diferencia entre properties y children, con un ejemplo de estructura esperada. No como documentación de referencia — como instrucción operativa directa.
Cómo quedó el sistema
El pipeline actual separa responsabilidades en tres capas. Los agentes coordinadores (Pepper, Wags, Alfred) manejan el flujo pero no ejecutan operaciones en APIs externas directamente. Los agentes especializados (Oracle, Don, Lucas) reciben contexto limpio, operan en su dominio, y devuelven output estructurado. Los nodos de integración (n8n tools para Notion, para GitHub, para correo) tienen instrucciones explícitas sobre la superficie específica de cada API que deben usar.
El resultado no es un sistema sin errores. Es un sistema donde los errores son localizables. Cuando algo falla, falla en un lugar acotado con un log que tiene sentido.
La variable que todavía no está resuelta es la gestión del contexto a escala. Con catorce agentes potencialmente activos en simultáneo, cada uno con su propio historial de conversación, el consumo de tokens por hora en producción es una variable que aún no tengo bajo control completo. Estoy midiendo. Los números aún no indican una solución definitiva.
Ese es el estado real del sistema a fecha de hoy.