3. El nodo nativo de AI Agent en producción

Descripción

Al terminar esta lección vas a poder explicar qué es exactamente una iteración de un agente y por qué la décima cuesta mucho más que la primera, vas a saber qué hace Max Iterations —cuyo valor por defecto es 10— y por qué moverlo no suma gasto sino que lo multiplica, y vas a poder elegir un techo con criterio en vez de con corazonada. También vas a saber cuándo Return Intermediate Steps vale lo que cuesta y qué hacer cuando un agente choca contra su propio límite.

Esto importa porque el bucle del agente es la primera de las cinco fugas de la lección 2 y, con diferencia, la más cara. Es también la que explica el caso que abrió el módulo: alguien en Terra Market subió Max Iterations de 10 a 30 en ticket-classify para arreglar unos casos raros que fallaban, y funcionó — arregló esos casos y le levantó el techo de gasto a las 9.000 ejecuciones mensuales. Ese cambio no aparece en ninguna métrica de las que estabas mirando. Aparece en la factura, un mes después, cuando ya nadie recuerda quién lo hizo.

Conexión con el módulo: la lección 2 te dio el instrumento —cost_log, con los tokens crudos y una fila por llamada al modelo—. Esta lección lo usa para tomar la primera decisión real: cuánto techo le pones al bucle. Las lecciones 4 y 5 tratan las otras dos palancas grandes —qué modelo y dónde corre—, y las 6 y 7 tratan las superficies desde donde el bucle puede dispararse sin que tú lo pidas. Una frontera clara: aquí no vas a aprender a diseñar un agente. Qué herramientas darle, cómo escribir su contrato, cuándo pedir aprobación humana antes de una acción irreversible — todo eso es n8n-ai-chatbots-agents-guide, módulo 4. Esta lección se ocupa de operar un agente que ya existe, con la pregunta que esa guía no hace: cuánto puede llegar a costar una sola ejecución.

Qué es una iteración, con manzanas

Vamos a construir la imagen desde abajo, porque casi todo el mundo tiene un modelo mental equivocado del nodo AI Agent y ese modelo es la raíz del problema.

La intuición natural es esta: el nodo AI Agent hace una llamada al modelo. Le mandas el ticket, el modelo te devuelve la categoría, se acabó. Con esa imagen, Max Iterations parece un ajuste técnico sin consecuencias, y subirlo parece tan inofensivo como subir un timeout.

Lo que hace de verdad es otra cosa.

Un agente no es un traductor. Es más parecido a alguien a quien le encargas una gestión y que sale a hacerla. Le dices: "averigua si este pedido ya se envió y si el cliente califica para devolución". Esa persona no te contesta de inmediato: se levanta, va a una ventanilla a consultar el estado del pedido, vuelve con la respuesta, la lee, se da cuenta de que necesita también el historial del cliente, va a otra ventanilla, vuelve, y entonces te contesta.

Cada uno de esos viajes a una ventanilla y regreso es una iteración. En términos de n8n: una llamada al modelo, la decisión de usar o no una herramienta, la ejecución de esa herramienta, y el regreso del resultado al modelo. El nodo AI Agent repite ese ciclo hasta que el modelo dice "ya está, aquí va la respuesta final".

La documentación oficial lo dice con precisión: Max Iterations es "el número de veces que el modelo debe correr para intentar generar una buena respuesta al prompt del usuario". Su valor por defecto es 10. Verifica ese número en el panel de tu versión antes de tomar decisiones sobre él — lo que ves en pantalla manda sobre lo que diga cualquier guía.

Por qué el costo no crece en línea recta

Ahora la parte que hay que entender bien, porque es lo que hace peligroso el ajuste.

Cada vez que el agente vuelve a hablar con el modelo, no le manda solo lo nuevo: le manda todo el historial de la conversación hasta ahí. El modelo no tiene memoria entre llamadas; la única forma de que sepa lo que ya pasó es que se lo vuelvas a contar. Así que la entrada de cada iteración incluye el system prompt, las descripciones de las herramientas, la pregunta original, y todos los pasos intermedios anteriores: qué herramienta se llamó, con qué argumentos, y qué devolvió.

Vamos a ponerle números a eso, con el ticket-classify de Terra Market:

Iteración 1
  entrada:  system prompt (320) + tools (180) + ticket (240)          =   740 tokens
  salida:   "voy a consultar el estado del pedido"                    =    40 tokens

Iteración 2
  entrada:  los mismos 740  +  lo que dijo el modelo (40)
            +  el resultado de la herramienta (180)                   =   960 tokens
  salida:   "ahora necesito el historial del cliente"                 =    45 tokens

Iteración 3
  entrada:  los 960 anteriores + 45 + otro resultado (200)            = 1.205 tokens
  salida:   la categoría final                                        =    35 tokens

Fíjate en la columna de entrada: 740, 960, 1.205. Crece en cada vuelta, y crece porque arrastra. Ahora suma las tres iteraciones y compáralo con lo que habrías pagado si el agente hubiera resuelto en una sola:

Tres iteraciones:  entrada 740 + 960 + 1.205 = 2.905 tokens
Una iteración:     entrada                   =   740 tokens

Tres vueltas no cuestan el triple: cuestan casi cuatro veces más.

Y esa curva se empina. Para cuando el agente va por la iteración diez, la entrada de esa sola llamada puede ser tres o cuatro veces la de la primera, porque arrastra nueve pasos de historia. La iteración veinte es peor. Por eso Max Iterations no es un límite lineal: es el techo de una curva que se acelera.

Si te sirve la imagen: es como pagarle a alguien por hora, pero además obligarlo a releer todo su cuaderno de notas antes de cada tarea nueva. La segunda tarea le toma un poco más que la primera. La décima le toma mucho más. Y tú pagas cada relectura.

Ejemplo trabajado: medir antes de decidir

Aquí está la parte que Terra Market no hizo, y que es todo el método de esta lección.

La persona que subió Max Iterations de 10 a 30 hizo lo razonable con la información que tenía: vio casos que fallaban, encontró un campo que parecía relacionado, lo subió, y comprobó que los casos dejaron de fallar. Lo que le faltó fue medir el efecto sobre el resto.

Vamos a hacerlo bien. Con cost_log ya escribiendo —una fila por llamada al modelo, con execution_id—, el número que necesitas sale de una consulta:

-- ¿Cuántas iteraciones usa REALMENTE ticket-classify?
-- Cada fila de cost_log es una llamada al modelo, así que contar filas
-- por execution_id te da las iteraciones de esa ejecución.
SELECT calls_per_execution,
       COUNT(*) AS how_many_executions
FROM (
  SELECT execution_id, COUNT(*) AS calls_per_execution
  FROM cost_log
  WHERE workflow_name = 'ticket-classify'
    AND logged_at >= now() - interval '7 days'
  GROUP BY execution_id
) t
GROUP BY calls_per_execution
ORDER BY calls_per_execution;

Qué esperar. Vas a obtener una distribución, no un número. Algo con esta forma:

iteraciones   ejecuciones   % acumulado
     1            1.240         19,7%
     2            3.980         83,0%
     3              780         95,4%
     4              210         98,7%
     5               58         99,6%
     6               14         99,8%
    ...
    28                3         99,99%
    30                4        100,0%

Léela con calma, porque esa tabla contiene toda la decisión.

El 95% de las ejecuciones se resuelve en tres iteraciones o menos. Ese es el caso típico y es donde vive el valor del workflow.

Hay una cola. Unas pocas ejecuciones llegan a 28 y 30 — es decir, chocan contra el techo. Y aquí está el detalle que cambia el diagnóstico: cuando el techo era 10, esas mismas ejecuciones chocaban contra 10. No es que ahora resuelvan casos que antes no podían: es que ahora dan veinte vueltas más antes de rendirse. Habría que revisar caso por caso si de verdad terminan bien o si simplemente terminan más caras.

Y la aritmética del cambio. Si esas 7 ejecuciones que llegan a 28-30 hubieran parado en 10, el ahorro por ejecución sería de unas veinte iteraciones de las caras — las del final de la curva, que arrastran todo el historial. Siete ejecuciones al día, treinta días, veinte iteraciones caras cada una: son 4.200 llamadas al modelo mensuales que nadie pidió, con la entrada más grande del rango.

La decisión, entonces, se escribe sola:

Techo razonable = percentil alto del caso legítimo  +  margen

  p99 observado (excluyendo la cola que choca con el techo) ≈ 5
  margen de seguridad para casos nuevos                     +2
  ─────────────────────────────────────────────────────────────
  Max Iterations = 7

Con 7, el 99,6% de las ejecuciones no nota ninguna diferencia. La cola se corta antes, más barata, y de forma visible — porque una ejecución que choca con el techo es una señal que puedes contar y alertar, mientras que una que da 30 vueltas y termina es invisible.

Y el hábito que hay que dejar instalado: ese cambio se prueba antes de publicarse. Bajas el techo en el entorno de desarrollo, corres una muestra de tickets reales —incluyendo varios de los "casos raros" que motivaron la subida original—, y comparas dos cosas: la calidad de la clasificación y el consumo. Si la calidad se mantiene, publicas. Si se cae, subes un escalón y vuelves a medir. No es una decisión de intuición: es un experimento de dos horas con un número al final.

Las otras opciones que mueven la aguja

Max Iterations es la más cara, pero no es la única. Veamos las que aparecen en el panel de opciones del nodo y qué implica cada una en producción.

Return Intermediate Steps

Qué es. Un interruptor que hace que el nodo incluya en su salida final los pasos intermedios que el agente dio: qué herramientas llamó, con qué argumentos, y qué devolvió cada una. Con él apagado, la salida es solo la respuesta final.

Para qué sirve. Para depurar y para auditar. Cuando un agente devuelve una categoría rara y quieres saber por qué, los pasos intermedios te lo dicen. Es el equivalente agéntico del logging estructurado que montaste en el módulo 4: sin él, tienes el resultado pero no el razonamiento.

Qué cuesta. Aquí hay que ser preciso, porque se confunde seguido. No aumenta el número de llamadas al modelo ni los tokens que se le mandan. Lo que hace es inflar los datos de ejecución que n8n guarda, y eso tiene un costo real que no es de tokens:

• Los datos de ejecución crecen, y con ellos la base de datos de la instancia. Si tienes 4.000 ejecuciones diarias, ese crecimiento se nota. El módulo 6 de esta guía trata a fondo la gestión del crecimiento de datos de ejecución, y esta opción es una de las que lo aceleran.
• El panel de ejecución se vuelve más pesado de cargar cuando lo abres a depurar.
• Si los pasos intermedios incluyen datos de clientes —y en soporte casi siempre los incluyen—, ahora están guardados en un lugar más, con las implicaciones de retención y privacidad que eso tiene. Ese ángulo lo trata el módulo 5.

La recomendación de operación: enciéndelo en desarrollo, y en producción enciéndelo temporalmente cuando estés investigando, no de forma permanente. Es una herramienta de diagnóstico, no una configuración por defecto. Y si lo dejas encendido en producción por una razón deliberada —auditoría, por ejemplo—, que sea una decisión escrita con su política de retención, no un olvido.

System Message

Qué es. El mensaje que se le manda al agente antes de la conversación: sus instrucciones, su rol, sus reglas.

Por qué está en una lección de costos. Porque viaja completo en cada iteración. Si tu agente da tres vueltas, tu system prompt se pagó tres veces en esa sola ejecución. Y multiplicado por el volumen mensual, es la fuga 2 de la lección anterior.

Eso le da una consecuencia práctica que casi nadie hace: el costo de una palabra del system prompt es su longitud × iteraciones × volumen. Una frase de 30 tokens que agregaste "por si acaso", en un workflow que da 2,5 iteraciones promedio y corre 9.000 veces al mes, cuesta 675.000 tokens al mes. Por una frase.

No es un argumento para escribir prompts crípticos —un prompt malo produce agentes que dan más vueltas, que es peor—. Es un argumento para revisarlo periódicamente y recortar lo que ya no aplica, igual que se revisa cualquier configuración que se acumula.

Enable Streaming

Qué es. Hace que el agente devuelva la respuesta en tiempo real, a medida que la genera, en vez de esperar a tenerla completa.

Qué implica en producción. Es una opción de experiencia de usuario, no de costo: los tokens son los mismos. Tiene sentido en un chat donde alguien está mirando la pantalla, y no tiene ninguno en un workflow automatizado donde el resultado va a una base de datos. En Terra Market, ticket-classify no lo necesita. Un asistente conversacional para el equipo de soporte, sí.

Tracing Metadata

Qué es. Permite adjuntar pares clave-valor propios a los eventos de trazado del agente.

Por qué te sirve. Si tienes una herramienta de observabilidad de IA conectada, esta es la puerta para etiquetar cada ejecución con datos tuyos —el cliente, el tipo de ticket, el entorno— y después poder segmentar el gasto por esas etiquetas. Es el mismo principio que las etiquetas en cualquier sistema de métricas: sin ellas tienes un total, con ellas tienes un desglose.

Automatically Passthrough Binary Images

Qué es. Controla si las imágenes binarias que entran al workflow se le pasan automáticamente al agente como mensajes de tipo imagen.

Por qué importa aquí. Porque las imágenes se cobran, y no son baratas. Una captura de pantalla que un cliente adjunta a un ticket puede costar tanto como varias páginas de texto. Si esta opción está encendida y tu workflow recibe adjuntos, estás pagando por procesar imágenes que quizás no aportan nada a la clasificación. Y como el default puede cambiar entre versiones, verifica en tu panel cómo está antes de asumirlo. Si tu agente no necesita ver imágenes, apágalo.

Qué pasa cuando el agente choca contra el techo

Esta parte merece su propia sección porque tiene una trampa operativa.

Cuando un agente llega a Max Iterations sin haber terminado, se detiene. Hasta ahí, lo esperable. La pregunta operativa es: ¿por dónde sale ese nodo? ¿Por la salida de éxito, con una respuesta a medias, o por la salida de error, donde tu manejo de errores del módulo 2 lo va a atrapar?

Y aquí va una advertencia honesta: este comportamiento ha sido reportado como inconsistente entre versiones, con casos donde el límite de iteraciones sale por la salida de éxito en vez de por la de error. No lo des por sentado en ninguna dirección. Verifícalo tú, en tu versión, con una prueba de treinta segundos:

1. Duplica tu workflow en desarrollo.
2. Pon Max Iterations en 1 o 2.
3. Dale una tarea que sepas que necesita más vueltas.
4. Mira el panel de ejecución: ¿salió en verde o en rojo? ¿Qué contiene la salida?

Ese resultado decide cómo construyes el resto. Porque las dos posibilidades tienen consecuencias muy distintas:

La segunda es la peligrosa, y merece un párrafo: si un agente que se quedó a medias sale en verde, su resultado a medias entra a tu ERP, o a tu cola de soporte, o al correo del cliente. En Terra Market eso sería un ticket clasificado con una categoría vacía o inventada. Nadie se entera, porque la ejecución salió bien.

La defensa vale la pena aunque tu versión salga por error, porque es barata y protege también de otras formas de respuesta mal formada:

// Nodo: Code — "Validate agent output"
// Modo: Run Once for Each Item
// Se pone después del agente, ANTES de que su salida toque cualquier
// sistema real. Verifica que la respuesta tenga la forma que el negocio
// espera, en vez de confiar en que salió en verde.

const VALID_CATEGORIES = [
  'returns',
  'late_shipping',
  'payment_issue',
  'general',
];

const data = $input.item.json;
const category = (data.category ?? '').trim();

// Un agente que se quedó a medias suele devolver vacío, o texto libre
// donde esperabas una etiqueta cerrada. Las dos cosas se detectan igual.
const isValid = VALID_CATEGORIES.includes(category);

return {
  json: {
    ...data,
    category: isValid ? category : 'needs_human_review',
    // Esta bandera es la que después cuentas y alertas: si sube,
    // el agente está chocando con su techo más de lo normal.
    agent_output_valid: isValid,
  },
};

Fíjate en lo que hace ese nodo cuando la salida no es válida: no lanza un error, redirige a revisión humana. En un flujo de soporte eso es lo correcto — un ticket sin clasificar que va a una cola de personas es un inconveniente; un ticket clasificado mal que se responde automáticamente es un problema con el cliente. La decisión de a dónde mandar lo dudoso depende de tu negocio, pero la decisión de detectarlo no es opcional.

Y la bandera agent_output_valid es una métrica: si el porcentaje de false sube, tu techo quedó corto o algo cambió en los datos de entrada. Es exactamente el tipo de señal que el módulo 4 te enseñó a alertar.

El timeout, que es el otro techo

Max Iterations acota cuántas veces habla el agente con el modelo. No acota cuánto tarda. Son dos límites distintos y conviene tener los dos.

El caso que los separa: un agente con Max Iterations en 7, cuya tercera iteración llama a una herramienta que consulta un servicio externo, y ese servicio se queda colgado. El agente no está iterando — está esperando. Max Iterations no lo protege de eso.

El límite de tiempo vive en la configuración del workflow, no en el nodo del agente, y conviene fijarlo con la misma lógica: mide cuánto tarda el caso típico, agrega margen, y ponlo. Un workflow con IA sin límite de tiempo es un workflow que puede quedarse ocupando un slot de ejecución indefinidamente, y en una instancia con 4.000 ejecuciones diarias eso tiene efectos que van más allá del costo — es capacidad que le quitas a todo lo demás. El módulo 6 de esta guía trata la concurrencia y el throughput a fondo; aquí basta con la regla: si el workflow tiene un agente, tiene límite de tiempo.

Errores comunes

Subir Max Iterations para arreglar un caso que falla (práctico). Qué pasa: unos pocos casos raros no se resuelven, alguien sube el techo, los casos se resuelven, y el techo se queda arriba para siempre afectando a todas las ejecuciones. Por qué pasa: es la primera hipótesis razonable —"le falta espacio para pensar"— y funciona, así que se confirma. Cómo detectarlo: corre la consulta de iteraciones por ejecución y mira la distribución. Si el 95% se resuelve en tres vueltas y el techo está en 30, el techo no está protegiendo el caso típico: está permitiendo la cola. Cómo corregirlo: casi siempre el caso raro no necesita más vueltas, necesita mejor información — un prompt más claro, una herramienta que devuelva datos más limpios, o una descripción de tool menos ambigua. Si después de arreglar eso el caso sigue necesitando quince vueltas, probablemente no debería resolverlo un agente. Y si de verdad hace falta subir el techo, súbelo solo para ese camino: separa los casos raros a un sub-workflow con su propia configuración, en vez de subirle el techo a las 9.000 ejecuciones mensuales.

Creer que Max Iterations es un límite lineal (conceptual). Qué pasa: alguien razona "de 10 a 30 es el triple, así que en el peor caso pago el triple", presupuesta con eso, y la factura sale bastante peor. Por qué pasa: el modelo mental de "cada iteración cuesta lo mismo" es el intuitivo y es falso, porque cada iteración arrastra el historial de las anteriores. Cómo detectarlo: mira en cost_log el costo de las llamadas de una misma execution_id, ordenadas. Vas a ver que suben. Cómo corregirlo: cuando estimes el peor caso, no multipliques el costo de una iteración por el techo. Toma una ejecución real que haya llegado al techo y mira lo que costó de verdad. Ese es tu peor caso, y suele sorprender.

Dejar Return Intermediate Steps encendido en producción sin decidirlo (práctico). Qué pasa: se enciende para depurar un problema, se resuelve el problema, y queda encendido. Meses después la base de datos de ejecuciones creció mucho más rápido de lo esperado y nadie sabe por qué. Por qué pasa: el efecto es invisible el primer día y acumulativo. Cómo detectarlo: revisa qué workflows con agente lo tienen activo y contrástalo con el crecimiento de tus datos de ejecución. Cómo corregirlo: trátalo como una bandera de diagnóstico — se enciende para investigar y se apaga al terminar. Si lo dejas encendido a propósito, escribe por qué y con qué política de retención, y revisa que los pasos intermedios no estén guardando datos de clientes que no deberían quedarse ahí.

Confiar en el verde de la ejecución cuando hay un agente adentro (conceptual). Qué pasa: la métrica de tasa de éxito dice 99,8% y el equipo está tranquilo, mientras algunos tickets llegan a los clientes con clasificaciones incompletas porque el agente se quedó a medias y salió en verde igual. Por qué pasa: en un sistema determinista "sin error" y "correcto" son casi lo mismo. Con un agente, no lo son. Cómo detectarlo: haz la prueba de Max Iterations = 1 en desarrollo y mira por dónde sale el nodo en tu versión. Y en producción, cuenta cuántas salidas del agente no tienen la forma esperada. Cómo corregirlo: validar la salida explícitamente con un nodo después del agente, y llevar esa validación como métrica propia. Con IA, "no falló" y "salió bien" son dos preguntas distintas y hay que responder las dos.

Poner un techo sin poner un límite de tiempo (práctico). Qué pasa: el agente tiene Max Iterations en 7 y aun así una ejecución se queda colgada dos horas, porque una herramienta llamó a un servicio externo que no respondió y nadie puso un tiempo máximo. Por qué pasa: Max Iterations se siente como "el límite del agente", y cubre solo una de las dos formas de descontrolarse. Cómo detectarlo: ordena tus ejecuciones por duración y mira la cola superior. Si hay ejecuciones de horas en un workflow que debería tardar segundos, ya lo encontraste. Cómo corregirlo: los dos límites, siempre. Iteraciones en el nodo, tiempo máximo en la configuración del workflow. Y si el agente consume herramientas que llaman a terceros, también un timeout en esas llamadas — que es justo el tema de la lección 7.

Ejercicios

Ejercicio 1 — Elige el techo con la distribución. Mediste reply-draft durante una semana y obtuviste esta distribución de iteraciones por ejecución:

iteraciones   ejecuciones
     1              90
     2           1.610
     3             580
     4             140
     5              38
     6              11
     7               4
    12               2
    20               5   ← el techo actual está en 20

(a) ¿Qué porcentaje de ejecuciones se resuelve en 4 iteraciones o menos? (b) ¿Qué techo propondrías y por qué? (c) ¿Qué te llama la atención de las 5 ejecuciones que llegan exactamente a 20, y qué harías con ellas antes de bajar el techo? (d) Si bajas el techo de 20 a 6, ¿cuántas ejecuciones semanales se ven afectadas, y qué les pasa?

2.420 / 2.480 = 97,6%

Ejercicio 2 — Estima el peor caso de verdad. Un compañero te dice: "una ejecución normal de ticket-classify cuesta unos 800 tokens de entrada. Con Max Iterations en 30, el peor caso son 30 × 800 = 24.000 tokens. Presupuestemos con eso."

(a) Explica por qué esa estimación está mal y en qué dirección. (b) Reconstruye la estimación correcta, sabiendo que en cada iteración se agregan al historial unos 220 tokens (la decisión del modelo más el resultado de la herramienta). (c) ¿Qué consulta a cost_log te daría el peor caso real, sin estimar nada?

iteración 1:   800
iteración 2:   800 +  220  = 1.020
iteración 3:   800 +  440  = 1.240
...
iteración n:   800 + 220 × (n − 1)
iteración 30:  800 + 220 × 29 = 7.180

total = 30 × 800  +  220 × (0 + 1 + 2 + ... + 29)
      = 24.000    +  220 × (29 × 30 / 2)
      = 24.000    +  220 × 435
      = 24.000    +  95.700
      = 119.700 tokens de entrada

-- El peor caso real de la última semana, por ejecución
SELECT execution_id,
       COUNT(*)            AS iterations,
       SUM(input_tokens)   AS total_input,
       SUM(output_tokens)  AS total_output,
       SUM(cost_total)     AS execution_cost
FROM cost_log
WHERE workflow_name = 'ticket-classify'
  AND logged_at >= now() - interval '7 days'
GROUP BY execution_id
ORDER BY execution_cost DESC
LIMIT 10;

Ejercicio 3 — Diseña el plan de cambio. Te toca arreglar el Max Iterations de ticket-classify en Terra Market: está en 30 y la evidencia dice que debería estar en 7. El workflow corre 300 veces al día en producción y clasifica tickets de clientes reales. Escribe el plan de cambio completo: qué haces antes, qué haces durante, qué mides, y bajo qué condición lo revertirías. Mínimo seis pasos.

Resumen y siguiente paso

Ya sabes qué hay dentro del nodo AI Agent. Una iteración es un ciclo completo: llamada al modelo, decisión de usar una herramienta, ejecución, y regreso del resultado. El agente repite ese ciclo hasta terminar o hasta chocar con Max Iterations, cuyo valor por defecto es 10 — verifícalo en tu versión.

Y sabes por qué ese número es el multiplicador más peligroso del módulo: cada iteración vuelve a mandar todo el historial acumulado, así que la entrada crece en cada vuelta y el costo de un bucle crece aproximadamente con el cuadrado del número de iteraciones. Duplicar el techo no duplica el peor caso: lo cuadruplica. Tres vueltas no cuestan el triple de una: cuestan casi cuatro veces más.

Tienes el método para elegir el techo, y no es una corazonada: medir la distribución real de iteraciones por ejecución con cost_log, encontrar dónde se aplana, poner el techo ahí más un margen, y abrir las ejecuciones que chocan con el techo actual — porque una ejecución que termina exactamente en el límite casi nunca necesitaba ese número: se le acabaron las vueltas.

Viste las otras opciones y qué mueven: Return Intermediate Steps no cuesta tokens pero infla los datos de ejecución, y es una bandera de diagnóstico, no una configuración permanente. El System Message viaja completo en cada iteración, así que su costo real es longitud × iteraciones × volumen. Enable Streaming es experiencia de usuario, no costo. Tracing Metadata te deja segmentar el gasto. Y Automatically Passthrough Binary Images puede estar haciéndote pagar por imágenes que no necesitas.

Y te llevas la advertencia operativa que más incidentes evita: verifica en tu versión por dónde sale el nodo cuando choca con el techo. El comportamiento se ha reportado como inconsistente, y si sale por éxito, tu métrica de tasa de éxito miente y un resultado a medias llega a tus sistemas. La defensa es validar la salida explícitamente con un nodo después del agente, redirigir lo dudoso a revisión humana, y contar esa bandera como métrica. Más el otro techo que hace falta: un límite de tiempo en la configuración del workflow, porque Max Iterations acota cuántas veces habla el agente, no cuánto puede esperar.

Antes de avanzar deberías poder: explicar por qué la iteración diez cuesta más que la primera; sacar de cost_log la distribución de iteraciones de un workflow y proponer un techo con ella; decir qué cuesta Return Intermediate Steps y qué no; y describir qué le pasa a un resultado incompleto que sale en verde.

La lección 4 sube un nivel y toca la otra palanca grande: qué modelo atiende la llamada. Vas a ver que no es una decisión estética sino dos cosas a la vez — un renglón de la factura que puede variar mucho entre modelos del mismo proveedor, y un riesgo de que tu workflow deje de funcionar sin aviso, porque los proveedores retiran modelos con fecha anunciada y el identificador que tienes escrito deja de existir. Vas a aprender el procedimiento para verificar que el tuyo sigue vivo, y el criterio para dejar de usar el mismo modelo para clasificar tickets y para redactar respuestas.

Recursos

• AI Agent node — n8n Docs — la ficha del nodo, con sus conexiones y su lugar en el lienzo.
• Tools Agent — n8n Docs — la lista completa de opciones con sus valores por defecto, incluidos Max Iterations (10), Return Intermediate Steps, System Message, Tracing Metadata, Enable Streaming y Automatically Passthrough Binary Images. Verifica aquí lo que ves en tu versión.
• How tools work — n8n Docs — el mecanismo por el que el agente decide qué herramienta llamar, que es lo que produce las iteraciones que estás contando.
• Workflow settings — n8n Docs — dónde vive el límite de tiempo del workflow, el otro techo que le hace falta a un agente.
• Módulo 2 de esta guía — manejo de errores, ramas de error y Continue On Error, que es lo que atrapa a un agente que choca con su techo si tu versión lo saca por la salida de error.
• Módulo 6 de esta guía — gestión del crecimiento de datos de ejecución, que es lo que acelera Return Intermediate Steps cuando queda encendido.
• Guía hermana n8n-ai-chatbots-agents-guide, módulo 4 (este mismo ecosistema) — el diseño del agente: qué herramientas darle, cómo escribir sus contratos y dónde poner aprobación humana. Es a donde llevas los hallazgos cuando descubres que el agente itera de más por un problema de diseño.