6. Bucles agénticos entre agentes: condiciones de parada

Descripción

Al terminar esta lección vas a poder identificar los tres bucles distintos que existen en un sistema multi-agente y calcular el techo real de llamadas al modelo que tu sistema puede alcanzar en una sola conversación; vas a poder instalar cinco condiciones de parada complementarias —de las cuales solo una es un parámetro y las otras cuatro son decisiones de diseño—; y vas a poder reconocer en la traza de ejecución la firma de cada tipo de bucle descontrolado, incluido el más traicionero, que no produce ningún error y se ve como una respuesta incompleta.

Esto importa porque la delegación te dio poder y el poder llegó sin frenos. En la lección 5 le enseñaste al orquestador a redelegar cuando un especialista responde out_of_scope. Perfecto — hasta que dos especialistas con fronteras difusas se devuelven el mismo caso: pedidos dice "esto es de facturación", facturación dice "esto es de pedidos", y el orquestador, obediente, sigue redelegando. Cada vuelta cuesta dinero real y tiempo real, el cliente ve un mensaje que nunca llega, y en el panel de n8n no hay nada rojo. La otra falla es la inversa y todavía más silenciosa: un especialista que se queda sin iteraciones a mitad de su razonamiento y devuelve lo que tenía hasta ese momento, que parece una respuesta y es un pedazo de una. Un sistema multi-agente sin condiciones de parada explícitas no es un sistema, es una apuesta.

Conexión con el módulo: la lección 5 te dio el contrato, y con él la redelegación por out_of_scope — que es justamente lo que hace posible el bucle de esta lección. Aquí instalas los frenos. Esta lección también retoma dos cosas del Módulo 1: el bucle agéntico razonar-actuar-observar (lección 3) y el parámetro Max Iterations del nodo AI Agent (lección 4), que ahí era un detalle y aquí es una de cinco piezas. Lo que aquí se acota en número de vueltas, la lección 7 lo traduce a dinero y a segundos.

El expediente que va y viene entre dos oficinas

Piensa en un trámite que te tocó hacer alguna vez. Llegas a la ventanilla A, explicas lo que necesitas, y te dicen: "eso lo ve la oficina B, al fondo a la derecha". Vas a B, explicas otra vez, y te dicen: "no, esto es de A, ellos manejan ese formulario". Vuelves a A. Y en A te vuelven a mandar a B, porque la persona de A no recuerda que ya estuviste ahí y la de B tampoco.

Fíjate en tres cosas de esa escena, porque son exactamente las tres piezas del problema de esta lección.

Nadie está haciendo nada malo. La persona de A cree honestamente que el caso es de B. La de B cree honestamente lo contrario. Cada decisión individual es razonable. El problema no está en ninguna de las dos: está en que nadie lleva la cuenta.

El sistema no tiene forma de notar que está atascado. Si alguien preguntara "¿cuántas veces mandamos a esta persona de una oficina a la otra?", la respuesta terminaría el problema en un segundo. Pero nadie tiene ese número, porque cada oficina solo ve su propio turno.

Tú, el que hace el trámite, no recibes ningún error. No hay una alarma. Simplemente el trámite no avanza, y te das cuenta por el reloj, no por un aviso.

Un sistema multi-agente reproduce esa escena con una diferencia importante: es mucho más rápido. Lo que a ti te tomaría una mañana, dos agentes lo hacen en once segundos, gastando una llamada al modelo por vuelta. Y como cada llamada individual termina bien, el motor de n8n no tiene nada que reportar.

La solución en la vida real es la misma que vas a instalar aquí: alguien lleva la cuenta, y a la tercera vuelta hay una regla que dice "esto ya no se manda a ninguna oficina más, va a supervisión".

Los tres bucles de tu sistema

Antes de poner frenos hay que saber cuántas ruedas hay. En el sistema que armaste en las lecciones 4 y 5 existen tres bucles distintos, anidados unos dentro de otros. Se confunden con facilidad, y cada uno se frena de una forma distinta.

Bucle 1 — El bucle interno de cada especialista

Es el bucle agéntico clásico del Módulo 1: el especialista razona, llama una tool, observa el resultado, vuelve a razonar. Da tantas vueltas como necesite hasta producir su resultado.

billing_specialist
  razonar → lookup_charge → observar
  razonar → get_customer_profile → observar
  razonar → open_dispute → observar
  razonar → producir resultado

Se frena con: el Max Iterations del propio especialista. Cuando falla: el especialista se corta a mitad y devuelve un resultado parcial, sin error.

Bucle 2 — El bucle del orquestador

El orquestador delega, lee el resultado, decide si delega otra vez o si compone la respuesta. También es un bucle agéntico — solo que sus "tools" son agentes.

triage_agent
  razonar → billing_specialist → observar resultado
  razonar → order_specialist → observar resultado
  razonar → componer respuesta

Se frena con: el Max Iterations del orquestador. Cuando falla: el orquestador se queda sin vueltas antes de haber atendido todos los temas del mensaje, y responde a medias.

Bucle 3 — El bucle de redelegación

Este es el peligroso, y es nuevo: no existía antes de que hubiera contratos. El especialista A devuelve out_of_scope señalando a B; el orquestador delega a B; B devuelve out_of_scope señalando a A; el orquestador delega a A.

triage_agent → order_specialist   → out_of_scope: "es de facturación"
triage_agent → billing_specialist → out_of_scope: "es de pedidos"
triage_agent → order_specialist   → out_of_scope: "es de facturación"
triage_agent → billing_specialist → out_of_scope: "es de pedidos"
...

Se frena con: una política explícita en el prompt del orquestador y, mejor aún, con un contador. Max Iterations lo corta eventualmente, pero de la peor forma posible: cuando ya gastaste todo el presupuesto.

Por qué ocurre. Casi siempre por una frontera mal trazada entre dos dominios. El caso clásico en TuTienda: "me cobraron el envío dos veces". ¿Eso es facturación (hay un cargo duplicado) o pedidos (el envío es del dominio logístico)? Si las dos Description no resuelven ese caso de forma explícita, los dos especialistas van a tener razón al rechazarlo.

Hay una cuarta forma, que no debería existir en tu sistema y conviene nombrar: la delegación circular directa, donde un especialista tiene a otro como tool y lo llama directamente. A llama a B, B llama a A, A llama a B, sin que el orquestador se entere de nada. Esta es la razón de la regla de arranque de la lección 3 —los trabajadores no delegan en otros trabajadores— y es la única de las cuatro que se previene por construcción: si el grafo no tiene ciclos, este bucle es imposible. Vale la pena verificarlo en el JSON exportado antes de dar por buena una arquitectura.

La aritmética de las iteraciones anidadas

Aquí está el número que la mayoría de la gente no calcula y debería.

Max Iterations viene con un valor por defecto de 10 en el nodo AI Agent. Si lo dejas así en todos lados y tienes un orquestador con tres especialistas, el techo teórico de tu sistema es:

Techo de llamadas al modelo en una conversación (peor caso):

  orquestador:          10 iteraciones
  cada delegación:      hasta 10 iteraciones del especialista

  10 × 10 = 100 llamadas al modelo, en el peor caso,
  para responder UN mensaje del cliente.

Cien llamadas al modelo. Ese es el techo que dejaste instalado sin darte cuenta, si no tocaste nada. En la práctica casi nunca se alcanza —la mayoría de las conversaciones se resuelven en siete u ocho llamadas, como viste en la traza de la lección 3—, pero el techo importa por dos razones: es lo que va a pasar el día que se dispare el bucle 3, y es lo que define tu peor caso de costo y de latencia.

La forma de pensarlo:

Con esos números, el techo del sistema de TuTienda baja de 100 a 8 × 6 = 48, y en la práctica se queda en menos de diez. Esos son números de referencia, no una fórmula: el valor correcto para tu caso sale de mirar tus propias trazas y contar cuántas iteraciones usa realmente un caso típico, y darle un margen.

Un método concreto para calibrar: corre veinte casos representativos con Return Intermediate Steps activado, cuenta las iteraciones de cada nivel en cada caso, toma el máximo observado y súmale dos. Si el máximo observado en el billing_specialist fue 4, ponle 6. Ese margen absorbe los casos raros sin dejar la puerta abierta de par en par.

Ejemplo trabajado: dos trazas que fallan sin error

Vamos a leer las dos fallas más comunes, para que las reconozcas cuando aparezcan.

Falla 1 — El corte silencioso.

El cliente escribe: "me cobraron $1,200 que no reconozco, y además el pedido #4521 no ha llegado, y quiero saber si aplica alguna compensación." Tres temas. El Max Iterations del orquestador está en 4.

# Traza de triage_agent — Max Iterations: 4

iteración 1 → llamada al modelo: decide delegar el tema del cargo
iteración 2 → tool: billing_specialist
                 → status "resolved", disputa D-8842 abierta
iteración 3 → llamada al modelo: decide delegar el tema del pedido
iteración 4 → tool: order_specialist
                 → status "resolved", pedido en tránsito

[ el agente alcanzó su límite de iteraciones ]

respuesta final: "Abrí la disputa D-8842 por el cargo de $1,200 y tu
pedido #4521 está en tránsito, llega entre mañana y pasado."

Qué esperar. La ejecución aparece en verde. La respuesta se ve bien. Y el tercer tema —la compensación— nunca se atendió, porque el orquestador se quedó sin vueltas antes de poder delegarlo o siquiera mencionarlo. El cliente va a volver a escribir preguntando lo mismo, y el equipo va a concluir que "el bot no entiende".

Cómo se detecta. Cuenta los pasos en intermediateSteps y compáralos con el valor de Max Iterations. Si coinciden exactamente, casi con seguridad hubo corte. Es la señal más confiable que existe para esta falla, y es la razón por la que Return Intermediate Steps merece estar activado mientras construyes.

Cómo se corrige. Sube el límite del nivel que se cortó, y agrega en el system prompt del orquestador una instrucción de honestidad: "si no alcanzaste a atender todos los temas del mensaje, dilo explícitamente en tu respuesta en vez de responder solo lo que alcanzaste". Un sistema que dice "de tus tres preguntas resolví dos, la tercera la reviso enseguida" es mucho mejor que uno que finge que había dos.

Falla 2 — El ping-pong.

El cliente escribe: "me cobraron el envío dos veces en el pedido #4521". La frontera entre facturación y pedidos no está resuelta para este caso.

# Traza de triage_agent — Max Iterations: 8

iteración 1 → modelo: parece un cargo duplicado, delego a facturación
iteración 2 → tool: billing_specialist
                 → { "status": "out_of_scope",
                     "summary": "El cargo corresponde al envío de un
                                 pedido; el dominio logístico lo maneja
                                 order_specialist." }
iteración 3 → modelo: dice que es de pedidos, redelego
iteración 4 → tool: order_specialist
                 → { "status": "out_of_scope",
                     "summary": "Es un cobro duplicado, no un problema
                                 de envío. Corresponde a facturación." }
iteración 5 → modelo: dice que es de facturación, redelego
iteración 6 → tool: billing_specialist
                 → { "status": "out_of_scope", ... }
iteración 7 → modelo: redelego
iteración 8 → tool: order_specialist
                 → { "status": "out_of_scope", ... }

[ límite de iteraciones alcanzado ]

respuesta final: (texto genérico o vacío, según el modelo)

Qué esperar. Ocho llamadas al modelo del orquestador, cuatro llamadas a agentes completos —con sus propias llamadas internas— y cero valor producido. Si tuvieras Max Iterations en 10 en todos lados, esto podría haber sido considerablemente peor. El cliente esperó veinte segundos para recibir nada.

Cómo se detecta. Busca en la traza el mismo nombre de tool apareciendo más de dos veces, o dos nombres alternándose. Es un patrón visual inconfundible una vez que sabes buscarlo.

Cómo se corrige. Aquí Max Iterations no es la corrección — es lo que evitó que fuera infinito, que es distinto. La corrección real son las condiciones de parada de la sección siguiente, empezando por la más simple: una regla en el prompt del orquestador que prohíba redelegar el mismo tema más de una vez.

Las cinco condiciones de parada

Un sistema multi-agente bien frenado tiene cinco, y son complementarias: cada una atrapa un caso que las otras no.

1. El límite duro: Max Iterations en cada nivel

Es el freno de emergencia. No es una condición de parada elegante — es el que impide que un problema se convierta en una factura.

# Nodo: AI Agent — triage_agent
Options → Max Iterations: 8

# Nodo: AI Agent Tool — billing_specialist
Options → Max Iterations: 6

# Nodo: AI Agent Tool — order_specialist
Options → Max Iterations: 5

# Nodo: AI Agent Tool — sales_specialist
Options → Max Iterations: 4

Qué atrapa: cualquier bucle, eventualmente. Qué no atrapa: nada de forma elegante. Cuando este freno actúa, ya gastaste todo el presupuesto y el resultado es una respuesta cortada. Piénsalo como el fusible de la instalación eléctrica: indispensable, y si se quema seguido es que hay otro problema que resolver.

2. El criterio de salida en el prompt

La parada semántica: el agente sabe cuándo terminó porque se lo escribiste.

# Fragmento del System Message de billing_specialist

  Tu trabajo termina cuando ocurre cualquiera de estas cosas:
  - Encontraste el cargo y puedes explicarlo.
  - No lo encontraste y abriste la disputa.
  - Determinaste qué dato falta para poder buscarlo.
  - Determinaste que el caso no es de tu dominio.
  En cuanto ocurra una de las cuatro, devuelve tu resultado.
  No sigas investigando "por si acaso".

Qué atrapa: el bucle 1, el interno del especialista, que es el que más se alarga cuando el prompt no dice cuándo parar. Un agente sin criterio de salida explícito tiende a seguir consultando tools mientras le queden iteraciones. Qué no atrapa: los bucles entre agentes, porque cada especialista individual está terminando correctamente su turno.

3. Los estados terminales

Del contrato de la lección 5: hay valores de status después de los cuales no se reintenta nada.

# Fragmento del System Message de triage_agent

  Estados terminales — cuando un especialista devuelve uno de estos,
  NO delegues de nuevo por ese tema bajo ninguna circunstancia:
  - "needs_human": informa al cliente que el equipo dará seguimiento
    y cierra el turno.
  - "pending_info": pregúntale al cliente lo que falta y cierra el
    turno. La conversación sigue, pero este turno termina aquí.

Qué atrapa: el reintento inútil, que es el bucle más frecuente en la práctica. Un orquestador sin esta regla, ante un pending_info, tiende a probar con otro especialista "a ver si ese sí puede" — y el otro tampoco puede, porque el dato sigue faltando. Qué no atrapa: el ping-pong de out_of_scope, que por definición no es un estado terminal —redelegar es la respuesta correcta la primera vez—.

4. El presupuesto de delegación

Aquí está la corrección específica del ping-pong. La idea: llevar la cuenta de cuántas veces se ha delegado un mismo tema, y cortar a las dos.

n8n no tiene un contador nativo de "profundidad de delegación" — vale la pena decirlo con claridad en vez de inventar un parámetro. Hay tres formas prácticas de conseguirlo, de la más simple a la más robusta:

Forma A — La regla en el prompt. La más simple, y sorprendentemente efectiva, porque el orquestador tiene la traza de sus propias llamadas en su contexto:

# Fragmento del System Message de triage_agent

  Presupuesto de delegación: para un mismo tema del cliente, puedes
  delegar como máximo DOS veces.
  - Primera delegación: al especialista que parezca corresponder.
  - Si devuelve "out_of_scope", segunda delegación al que indique.
  - Si el segundo también devuelve "out_of_scope", NO delegues una
    tercera vez. El caso queda sin dueño claro: informa al cliente
    que vas a escalarlo y cierra el turno.
  Nunca llames dos veces al mismo especialista por el mismo tema.

Forma B — El contador en el encargo. Más explícito: el task incluye qué intento es, y el especialista lo ve.

# En el $fromAI del AI Agent Tool

{{ $fromAI("task", "Encargo autocontenido. Empieza SIEMPRE con la línea 'Intento N de 2:' donde N es 1 si es la primera vez que se delega este tema, o 2 si otro especialista ya lo rechazó. Si es intento 2, incluye qué dijo el especialista anterior.", "string") }}

Con eso, el especialista recibe "Intento 2 de 2: order_specialist rechazó este caso diciendo que era un cobro duplicado…" y su system prompt puede tener una regla: "si recibes un intento 2, resuélvelo con lo que tengas o devuelve needs_human; no devuelvas out_of_scope". El ping-pong se corta por diseño, en el nivel donde ocurre.

Forma C — La pared dura en un sub-workflow. La única que no depende de que el modelo obedezca. Si el especialista está montado como sub-workflow (lección 4), puedes poner un nodo Code al inicio que lea el contador del encargo y termine la ejecución si excede el límite, sin llegar a llamar al modelo:

// Code node — al inicio del sub-workflow del especialista
// Corta la delegación antes de gastar una llamada al modelo.
// El contador viene en el encargo; si no viene, asumimos el primero.
const attempt = $input.first().json.attempt ?? 1;

if (attempt > 2) {
  return [{
    json: {
      status: 'needs_human',
      summary: 'Se agotó el presupuesto de delegación para este caso.',
      data: {},
      missing: [],
    },
  }];
}

// Si está dentro del presupuesto, deja pasar el encargo al agente.
return $input.all();

Qué atrapa: el bucle 3, el ping-pong, que es el único que las otras cuatro condiciones no resuelven bien. Qué no atrapa: nada más — es específico.

Cuál usar. Empieza con la Forma A. Si en la traza ves que el ping-pong ocurre igual, pasa a la B. Reserva la C para sistemas donde el costo de una vuelta extra sea significativo o donde el especialista ya esté como sub-workflow por otras razones.

5. La regla de grafo: los trabajadores son hojas

La condición de parada que no cuesta nada porque es estructural: si ningún especialista tiene otro agente conectado a su puerto ai_tool, la delegación circular directa es imposible. No hay que confiar en ningún prompt ni en ningún contador — el grafo no tiene ciclos.

Cómo verificarlo, en treinta segundos: exporta el workflow como JSON y busca las conexiones de tipo ai_tool. Cada una debería apuntar a un agente que no es tool de nadie más hacia abajo. En un sistema de tres especialistas, las conexiones ai_tool deberían formar exactamente dos niveles: especialistas → orquestador, y tools de dominio → especialistas. Si aparece una tercera capa, o si un nombre aparece a la vez como origen y como destino en dos entradas distintas, tienes un ciclo posible.

Qué atrapa: la delegación circular directa, por construcción. Qué no atrapa: el ping-pong vía orquestador, que no es un ciclo del grafo sino un ciclo del razonamiento — el grafo sigue siendo un árbol y el bucle ocurre igual.

La tabla de las cinco

Instálalas todas. Cada una atrapa un caso que las demás no, y ninguna sustituye a otra.

Cuando la parada la impone un error

Falta un caso que no es un bucle y se confunde con uno: la ejecución que se detiene porque algo falló técnicamente.

Si una tool de dominio falla —la API de la transportadora no responde, la base de datos rechaza la conexión— el comportamiento por defecto depende de cómo esté configurado el manejo de errores de ese nodo. Dos cosas conviene decidir de forma explícita en un sistema multi-agente:

Qué le llega al especialista cuando su tool falla. Si el error se propaga y detiene la ejecución completa, el orquestador nunca recibe nada y el cliente ve un silencio. Suele ser preferible que el error llegue al especialista como un resultado —"la consulta falló"— para que pueda aplicar su contrato de falla y devolver needs_human con una explicación. Eso se configura en el nodo de la tool, con las opciones de continuar ante error que ofrece n8n.

Cuánto puede tardar todo esto. Un sistema con delegaciones anidadas puede tardar bastante más que un agente suelto, y una ejecución que se queda esperando indefinidamente a una API caída consume recursos y deja al cliente colgado. n8n permite configurar un tiempo máximo de ejecución en los ajustes del workflow; en un sistema multi-agente conviene fijarlo de forma consciente en vez de dejarlo abierto. La lección 7 te da el cálculo para saber qué valor es razonable en tu caso.

Una nota sobre el reintento: si el contrato de falla de tu especialista dice "reintenta una sola vez", asegúrate de que ese "una sola vez" esté escrito y sea verificable en la traza. Un modelo al que le dices "reintenta si falla" sin límite va a reintentar mientras le queden iteraciones, y ese es otro bucle, con la particularidad de que cada vuelta también golpea al sistema externo que ya estaba fallando.

Errores comunes

Confiar en que Max Iterations es la condición de parada (conceptual). Qué pasa: alguien pone límites conservadores en todos los agentes y da el tema por cerrado. El sistema no se cuelga nunca, cierto — pero produce respuestas cortadas de forma regular, y nadie las relaciona con el límite porque no hay ningún error. Por qué pasa: es el único freno que se ve como un parámetro configurable, y configurar algo se siente como resolverlo. Cómo detectarlo: cuenta cuántas ejecuciones terminan con un número de pasos exactamente igual al límite; si son más del 5%, tu sistema está viviendo contra el techo. Cómo corregirlo: Max Iterations es el fusible, no el interruptor. Las paradas que quieres que actúen en el día a día son las semánticas: criterio de salida, estados terminales y presupuesto de delegación.

Poner el mismo Max Iterations en todos los niveles (conceptual). Qué pasa: alguien deja 10 en el orquestador y 10 en cada especialista, sin notar que eso multiplica. El peor caso del sistema es 100 llamadas al modelo, cuando el caso típico son 7. Por qué pasa: el parámetro está en el mismo lugar en cada nodo y el valor por defecto es el mismo, así que no hay nada que invite a diferenciarlo. Cómo detectarlo: multiplica el límite del orquestador por el límite del especialista más generoso; ese número es tu peor caso, y probablemente te sorprenda. Cómo corregirlo: calibra con la regla del máximo observado más dos, por nivel, y recuerda que un especialista con dos tools rara vez necesita más de cuatro iteraciones.

Tratar out_of_scope como un fracaso del especialista (conceptual). Qué pasa: alguien ve varios out_of_scope en la traza, concluye que los especialistas están mal configurados, y les amplía el ámbito a los dos para que "ninguno rechace casos". El ping-pong desaparece y en su lugar aparece algo peor: dos especialistas que aceptan el mismo caso y lo resuelven de formas distintas según a cuál le tocó. Por qué pasa: el ping-pong se ve como un problema de los especialistas cuando es un problema de la frontera entre ellos. Cómo detectarlo: junta los casos que produjeron ping-pong y busca qué tienen en común; casi siempre son un mismo tipo de caso ambiguo, no casos variados. Cómo corregirlo: resuelve la frontera de forma explícita en las dos Description —"un cobro duplicado de envío lo maneja billing_specialist, aunque se refiera a un pedido"— y deja que out_of_scope siga existiendo para lo que es: una señal honesta de que el orquestador se equivocó de destinatario.

Construir la pared dura antes de necesitarla (práctico). Qué pasa: alguien lee la Forma C, monta todos sus especialistas como sub-workflows con nodos Code contando intentos, y termina con un sistema de ocho workflows para tres especialistas que nunca hicieron ping-pong. Por qué pasa: la solución más robusta se siente como la más profesional. Cómo detectarlo: pregúntate cuántas veces observaste el problema que estás previniendo; si la respuesta es cero, estás pagando complejidad por adelantado. Cómo corregirlo: Forma A primero, siempre. Sube a B o C cuando la traza te muestre que hace falta — y la traza te lo va a mostrar con claridad, porque el ping-pong tiene una firma visual inconfundible.

No verificar el grafo después de agregar un especialista (práctico). Qué pasa: seis meses después, alguien agrega un escalation_specialist y, para que pueda consultar datos de facturación, le conecta el billing_specialist como tool. Acaba de crear un camino de dos agentes que se pueden llamar entre sí, y nadie lo notó porque en el canvas se ve como una conexión más. Por qué pasa: la regla "los trabajadores son hojas" es una convención, no algo que n8n imponga. Cómo detectarlo: exporta el JSON y revisa las conexiones ai_tool; deberían formar exactamente dos niveles. Cómo corregirlo: si un especialista de verdad necesita datos de otro dominio, dale la tool de lectura que necesita —lookup_charge— en vez del agente completo; compartir una tool de lectura no crea ningún ciclo.

Ejercicios

Ejercicio 1 — Calcula el techo. Un sistema tiene un orquestador con Max Iterations en 10 y cuatro especialistas: dos con límite 10, uno con 6 y uno con 3. (a) ¿Cuál es el peor caso de llamadas al modelo para responder un mensaje? (b) Si el caso típico observado en la traza usa 3 iteraciones del orquestador y hasta 4 de un especialista, ¿qué valores pondrías en cada nivel?

Ejercicio 2 — Diagnostica la traza. Lee esta traza y di qué falla es, cómo la reconociste, y cuál de las cinco condiciones de parada la habría evitado:

triage_agent — Max Iterations: 8
  1 → modelo
  2 → tool: order_specialist   → status "pending_info", missing: ["order_id"]
  3 → modelo
  4 → tool: sales_specialist   → status "out_of_scope"
  5 → modelo
  6 → tool: order_specialist   → status "pending_info", missing: ["order_id"]
  7 → modelo
  8 → tool: billing_specialist → status "out_of_scope"
  [ límite alcanzado ]

Ejercicio 3 — Resuelve la frontera. El ping-pong del caso "me cobraron el envío dos veces en el pedido #4521" sigue ocurriendo. Escribe las dos líneas que agregarías a las Description de billing_specialist y order_specialist para que este caso deje de rebotar, y explica por qué esa corrección es mejor que subir el Max Iterations.

# Agregado a la Description de billing_specialist
  Los cobros duplicados son SIEMPRE de tu dominio, incluso cuando el
  cargo duplicado corresponde a un envío, a un servicio o a cualquier
  concepto asociado a un pedido. Si el cliente reporta que le cobraron
  algo dos veces, es tuyo.

# Agregado a la Description de order_specialist
  Los cobros duplicados NO son de tu dominio, aunque el cargo se
  refiera al envío de un pedido: eso lo maneja billing_specialist.
  Tú manejas el envío en sí (dónde está, cuándo llega, a qué dirección),
  no lo que se cobró por él.

Resumen y siguiente paso

Ya tienes los frenos. Tu sistema tiene tres bucles anidados —el interno de cada especialista, el del orquestador, y el de redelegación entre agentes— más un cuarto que la regla de grafo hace imposible. Los límites de iteración se multiplican entre niveles, así que un sistema con los valores por defecto tiene un techo de cien llamadas al modelo que casi nadie calcula. Y las cinco condiciones de parada son complementarias: Max Iterations como fusible, el criterio de salida en el prompt para el bucle interno, los estados terminales para los reintentos inútiles, el presupuesto de delegación para el ping-pong, y el grafo sin ciclos para la delegación circular. Las dos fallas típicas —el corte silencioso y el ping-pong— no producen ningún error en n8n y se reconocen por su firma en la traza: pasos que igualan exactamente el límite, y la misma tool apareciendo dos o más veces.

Antes de avanzar deberías poder: calcular el peor caso de tu sistema multiplicando límites; calibrar Max Iterations por nivel con la regla del máximo observado más dos; nombrar las cinco condiciones de parada y qué bucle atrapa cada una; y diagnosticar una traza distinguiendo un corte silencioso de un ping-pong.

Lo que queda es traducir todo esto a las dos unidades que importan fuera del equipo técnico: dinero y segundos. Un techo de cien llamadas al modelo suena mal, pero ¿cuánto es en pesos? ¿Cuánto tarda cada delegación de verdad? ¿A partir de qué punto un especialista deja de valer lo que cuesta? La lección 7 pone la calculadora sobre la mesa y te da las palancas para ajustar — incluida la más incómoda, que es decidir que un agente no debería existir.

Recursos

• AI Agent node — n8n Docs — referencia de Max Iterations y Return Intermediate Steps, las dos opciones sobre las que se apoya toda esta lección.
• AI Agent Tool node — n8n Docs — el mismo par de opciones en el nivel del especialista, que es donde se multiplican.
• Error handling — n8n Docs — cómo decidir si un error de una tool detiene la ejecución o llega al agente como un resultado que puede manejar.
• Workflow settings — n8n Docs — dónde se fija el tiempo máximo de ejecución de un workflow, un freno adicional que conviene poner de forma consciente en sistemas con delegaciones anidadas.
• Code node — n8n Docs — la referencia del nodo con el que se implementa la pared dura de la Forma C, incluyendo el formato de retorno [{ json: {...} }].
• View past executions — n8n Docs — el panel donde se leen las trazas y se cuentan los pasos, que es como se detectan las dos fallas de esta lección.