4. Un agente como tool de otro agente: delegación nativa

Descripción

Al terminar esta lección vas a poder conectar un agente completo —con su propio modelo, su propio system prompt y sus propias tools— al puerto ai_tool de otro agente, de forma que el primero pueda delegarle trabajo cuando el modelo lo decida; vas a poder leer la traza anidada que produce esa delegación para saber exactamente qué pasó en cada nivel; y vas a poder elegir con criterio entre los dos mecanismos nativos que n8n ofrece para esto, sabiendo qué gana y qué pierde cada uno.

Esto importa porque es el punto donde el diseño de las dos lecciones anteriores deja de ser un dibujo. Hasta ahora tienes un reparto de responsabilidades en papel y una tabla de quién posee qué. Esta lección es el cable. Y es también, sin exagerar, la razón por la que este módulo existe: durante años, en n8n, "agentes que se delegan tareas" fue una figura retórica para describir un Switch con nodos de IA en cada rama. Hoy es literal — el especialista se conecta al mismo puerto donde conectabas un nodo de Gmail en el Módulo 4, y el agente que llama no sabe ni le importa que del otro lado haya otro agente razonando. Para él es una tool más. Esa simetría es todo el truco, y entenderla bien es lo que separa a alguien que arma sistemas multi-agente de alguien que los describe.

Conexión con el módulo: la lección 3 te dio la arquitectura —orquestador con la conversación y la memoria, trabajadores con sus dominios y sus tools— y te dejó pendiente el cableado. Esta lección lo resuelve. Trae también dos cosas del Módulo 4 casi sin cambios: el contrato de una tool de la lección 5 (nombre y descripción son lo único que el agente que llama tiene para decidir) y $fromAI() de las lecciones 3 y 6 (el mecanismo por el cual el modelo arma los argumentos de la llamada). Lo que aquí queda todavía incompleto —qué forma exacta tiene la respuesta que devuelve el especialista, y qué pasa cuando no puede resolver— es la lección 5.

De una tool que hace una cosa a una tool que piensa

Piensa en la diferencia entre una calculadora y un contador.

Cuando le das un número a una calculadora, obtienes exactamente lo que pediste. No hay criterio de por medio: entra 1200 * 0.19, sale 228. Si le das un dato mal, produce un resultado mal con la misma seguridad. Es útil justamente porque es predecible.

Cuando le mandas algo a un contador, pasa otra cosa. Le dices "revisa este cargo de $1,200 que el cliente no reconoce" y él decide qué mirar primero. Consulta el registro, no encuentra nada, se le ocurre que quizás la compra se hizo con otro nombre, revisa eso también, y recién entonces te responde. No le diste una secuencia — le diste un encargo. Los pasos los eligió él, en función de lo que iba encontrando.

Las tools del Módulo 4 son calculadoras. Un nodo de Gmail conectado al puerto ai_tool hace exactamente una cosa: manda un correo con los parámetros que recibe. Un nodo de Postgres consulta y devuelve filas. Predecibles, y esa es su virtud.

Lo que vas a conectar en esta lección es un contador. Desde el punto de vista del agente que llama, se ve idéntico: una tool con un nombre, una descripción y un parámetro. Se conecta al mismo puerto. El agente decide llamarla de la misma forma, comparando su descripción contra lo que necesita. Pero del otro lado del cable, en vez de un nodo que ejecuta una acción, hay un agente completo que va a razonar, elegir entre sus propias tools, evaluar resultados, y quizás llamar tres tools antes de responder.

Esa simetría no es un detalle de implementación: es lo que hace que el patrón escale. Si delegar en un agente exigiera un mecanismo distinto al de usar una tool, tendrías que diseñar el orquestador de otra forma. Como es el mismo mecanismo, todo lo que aprendiste sobre contratos de tools se aplica sin traducción, y un orquestador puede tener mezclados agentes y tools normales sin ningún problema conceptual.

El nodo AI Agent Tool

n8n 2.0 tiene un sub-nodo específico para esto: AI Agent Tool. Su tipo interno es @n8n/n8n-nodes-langchain.agentTool, y la palabra clave de esa cadena es la última: agentTool, no agent. Es un agente empaquetado como tool.

La diferencia con el nodo AI Agent que ya conoces es de posición en el grafo, no de naturaleza:

Esa última fila es la importante, y es la que hace posible todo lo demás. Un AI Agent Tool no es un agente "reducido": tiene sus propios puertos abajo, y cuelgan de él su modelo y sus tools igual que del agente raíz. En el canvas se ve como un segundo nivel de ramificación: del agente raíz bajan tres agentes-tool, y de cada uno bajan sus propias tools.

Los puertos

Los parámetros

Estos son los campos que configuras en el panel del nodo. Vamos uno por uno, porque cada uno resuelve una pregunta distinta.

Description. El texto que lee el agente que llama para decidir si esta tool aplica. Es exactamente el mismo campo, con exactamente la misma función, que la Description de cualquier tool del Módulo 4 — con una diferencia de énfasis: aquí no describes una acción, describes un ámbito de competencia. "Manda un correo" es la descripción de una acción; "resuelve cualquier caso relacionado con cobros, cargos no reconocidos y facturación" es la descripción de un ámbito. Y como en el Módulo 4, la parte que más rinde es decir cuándo NO usarlo.

Source for Prompt (User Message). De dónde sale el encargo que recibe este agente. Cuando el nodo se usa como tool, la opción que te sirve es la de definirlo tú en el nodo (en el panel aparece como definirlo abajo, en el propio nodo), porque el encargo no viene de un chat trigger — viene del agente que llama.

El texto del prompt (User Message). Aquí va el encargo. Y aquí es donde entra $fromAI(): no escribes un encargo fijo, escribes una expresión que le dice al modelo del agente que llama qué debe redactar. Es el mismo mecanismo del Módulo 4, aplicado a algo más interesante que un order_id:

{{ $fromAI("task", "Descripción completa y autocontenida del caso que este especialista debe resolver. Incluye todos los datos que ya diste o que el cliente mencionó (IDs, montos, fechas). El especialista no tiene acceso a la conversación.", "string") }}

Lee con cuidado esa description. Está haciendo dos trabajos: le dice al modelo qué escribir, y le recuerda una restricción de arquitectura —el especialista no ve la conversación— que si no está escrita ahí, el modelo no tiene forma de saber. Un $fromAI("task", "La tarea") sin esa aclaración produce encargos como "revisa lo que me preguntó", que el especialista no puede resolver porque no tiene el "me preguntó".

Options → System Message. El system prompt del especialista. Corto, de un solo dominio, con sus reglas y su formato de salida — el que escribiste en el ejercicio 3 de la lección 3.

Options → Max Iterations. Cuántas vueltas de razonar-actuar-observar puede dar este agente antes de rendirse. Viene con un valor por defecto —10 en el nodo AI Agent— y aquí importa el doble que en un agente suelto, porque estás anidando bucles. La lección 6 se dedica entera a esto.

Options → Return Intermediate Steps. Si la salida del especialista incluye el detalle de sus propias llamadas a tools. Actívalo mientras construyes: sin esto, cuando un especialista devuelva algo raro vas a ver solo su conclusión, sin poder saber qué tools consultó para llegar ahí. En producción puedes apagarlo si el volumen de log te molesta.

Nota honesta sobre las etiquetas. n8n mueve de lugar y renombra campos entre versiones menores con cierta frecuencia — el propio nodo AI Agent dejó de tener un selector de "tipo de agente" en la 1.82, y el panel de configuración se rediseñó en la 2.0. Los conceptos de arriba son estables: descripción para el que llama, fuente del encargo, system prompt propio, límite de iteraciones, traza. Los nombres exactos y en qué pestaña vive cada uno, verifícalos en el panel del nodo de tu instancia antes de dar por sentado que están donde dice un tutorial. Si algo no aparece con ese nombre, busca el concepto, no la cadena de texto.

Ejemplo trabajado: conectar billing_specialist al triage_agent

Vamos a cablear el sistema que diseñaste en la lección 3. Empezamos por un solo especialista para ver bien el mecanismo, y después el resto es repetición.

Paso 1 — El orquestador ya existe. En el canvas tienes un Chat Trigger conectado por main a un nodo AI Agent llamado triage_agent, con su Chat Model y su memoria de Postgres conectada al puerto ai_memory. Su puerto ai_tool está vacío por ahora.

Paso 2 — Agregas el nodo AI Agent Tool. Buscas "AI Agent Tool" en el panel de nodos y lo sueltas en el canvas. Lo renombras a billing_specialist. El nombre del nodo importa: es lo que vas a ver en la traza y es parte de cómo el agente que llama se refiere a esta tool.

Paso 3 — Conectas su salida al orquestador. Arrastras desde el conector superior del billing_specialist hasta el puerto Tool del triage_agent. La conexión que se crea es de tipo ai_tool — la misma línea curva que ya usaste para conectar un nodo de Gmail. Visualmente no hay ninguna diferencia, y eso es precisamente lo que queremos.

Paso 4 — Le conectas su propio modelo. Al puerto Chat Model del billing_specialist le conectas un nodo de modelo de chat. Nota que no tiene por qué ser el mismo que usa el orquestador: aquí puedes poner el modelo más capaz que tengas disponible, porque este agente toma decisiones sobre dinero, mientras que el orquestador solo decide a quién llamar.

Paso 5 — Le conectas sus tools. Al puerto Tool del billing_specialist le conectas sus tres tools de dominio: lookup_charge, get_customer_profile y open_dispute. Cada una con su Description y sus $fromAI() bien escritos, como aprendiste en el Módulo 4.

Paso 6 — Configuras el nodo. Este es el contenido real:

# Nodo: AI Agent Tool — Name: billing_specialist
# (conectado al puerto Tool de triage_agent)

Description:
  Resuelve casos de cobros, cargos no reconocidos, montos en factura
  y solicitudes de disputa. Úsalo cuando el cliente mencione un monto
  cobrado, una tarjeta, un estado de cuenta o una factura.
  NO lo uses para estado de pedidos, envíos ni devoluciones de
  producto: para eso existe order_specialist.
  Devuelve un resumen del hallazgo y el estado del caso; no devuelve
  texto para mostrarle al cliente tal cual.

Source for Prompt (User Message):
  Definido en este nodo

Prompt (User Message):
  {{ $fromAI(
       "task",
       "Encargo completo y autocontenido para el especialista de
        facturación. Debe incluir el monto, la fecha aproximada del
        cargo, el ID del cliente y qué se espera resolver. Este
        especialista NO tiene acceso al historial de la conversación:
        todo dato relevante que el cliente haya mencionado en turnos
        anteriores debe ir escrito aquí.",
       "string"
     ) }}

Options:
  System Message:
    Eres el especialista en facturación de TuTienda. Resuelves cargos
    que el cliente no reconoce, dudas sobre montos y solicitudes de
    disputa. No manejas devoluciones de producto ni estado de envíos:
    si el encargo es de ese dominio, no uses ninguna tool y repórtalo
    como fuera de tu alcance.

    Procedimiento: usa lookup_charge con el monto y la fecha
    aproximada. Si no aparece, revisa get_customer_profile por si la
    compra se hizo con otro nombre o con otra tarjeta del mismo
    cliente. Solo si sigue sin aparecer, usa open_dispute.

    Nunca prometas un reembolso ni un plazo de resolución. Puedes
    confirmar que la disputa quedó abierta y su número de referencia.

    Trabajas con el encargo que recibes; no tienes historial de la
    conversación. Si te falta un dato, no lo inventes: repórtalo.

    Devuelve: qué encontraste, qué acción tomaste, si el caso quedó
    cerrado o pendiente, y qué dato falta si quedó pendiente.
    No escribas saludos ni despedidas: tu salida la lee otro agente.

  Max Iterations: 6
  Return Intermediate Steps: true

Paso 7 — Le dices al orquestador que existe. El triage_agent ya puede ver la tool, porque está conectada. Pero su system prompt tiene que declarar la política de uso:

# Nodo: AI Agent — Name: triage_agent
# Options → System Message:

  Eres la primera línea de atención de TuTienda. Tu único trabajo es
  entender qué necesita el cliente y delegarlo al especialista
  correcto. Tú no consultas sistemas ni resuelves casos por tu cuenta.

  Especialistas disponibles:
  - billing_specialist: cobros, cargos, facturación, disputas.
  - order_specialist: pedidos, envíos, retrasos, devoluciones.
  - sales_specialist: recomendaciones de producto y precios.

  Reglas:
  - Si el mensaje trae más de un tema, delega cada tema por separado
    y compón una sola respuesta al final.
  - Cada encargo que envíes debe ser autocontenido: incluye los datos
    que el cliente dio en cualquier turno de la conversación, porque
    los especialistas no ven el historial.
  - Si un especialista reporta que el caso quedó pendiente por falta
    de un dato, pídeselo al cliente antes de volver a delegar.
  - No inventes información de dominio. Si ningún especialista aplica,
    dilo con honestidad.
  - Compón la respuesta final al cliente con tono cálido y tuteo, en
    una sola voz, sin repetir saludos.

Paso 8 — Cómo se ve exportado. Si exportas el workflow como JSON, la parte que importa es connections, porque ahí se ve el grafo real:

{
  "connections": {
    "billing_specialist": {
      "ai_tool": [[ { "node": "triage_agent", "type": "ai_tool", "index": 0 } ]]
    },
    "Anthropic Chat Model (billing)": {
      "ai_languageModel": [[ { "node": "billing_specialist", "type": "ai_languageModel", "index": 0 } ]]
    },
    "lookup_charge": {
      "ai_tool": [[ { "node": "billing_specialist", "type": "ai_tool", "index": 0 } ]]
    },
    "get_customer_profile": {
      "ai_tool": [[ { "node": "billing_specialist", "type": "ai_tool", "index": 0 } ]]
    },
    "open_dispute": {
      "ai_tool": [[ { "node": "billing_specialist", "type": "ai_tool", "index": 0 } ]]
    },
    "Postgres Chat Memory": {
      "ai_memory": [[ { "node": "triage_agent", "type": "ai_memory", "index": 0 } ]]
    },
    "OpenAI Chat Model (triage)": {
      "ai_languageModel": [[ { "node": "triage_agent", "type": "ai_languageModel", "index": 0 } ]]
    }
  }
}

Léelo despacio, porque en esas siete entradas está todo el patrón:

• billing_specialist sale por ai_tool hacia triage_agent. Es una tool del orquestador.
• lookup_charge, get_customer_profile y open_dispute salen por ai_tool hacia billing_specialist. Son tools del especialista.
• La misma clase de conexión, ai_tool, aparece en dos niveles. Eso es la anidación, escrita en el grafo.
• Postgres Chat Memory va al triage_agent y a nadie más — la regla de propiedad de la lección 3, hecha cable.
• Hay dos nodos de modelo distintos, uno por agente.

Qué esperar. Mandas por el chat: "Hola, me llegó un cobro de $1,200 que no reconozco en la tarjeta."

En el panel de ejecución vas a ver el nodo triage_agent ejecutándose, y dentro de su detalle una llamada a la tool billing_specialist. Si abres esa llamada, ves el task que el orquestador redactó — algo como "El cliente reporta un cargo de $1,200 que no reconoce, en la tarjeta registrada. Cliente C-9931. Verificar si corresponde a alguna compra y, si no, abrir disputa." Nota que el orquestador escribió ese encargo: no reenvió el mensaje del cliente tal cual, lo tradujo, porque eso es lo que le pidió la description del $fromAI("task", ...).

Después ves el nodo billing_specialist ejecutándose por su cuenta, con sus propias llamadas a lookup_charge, get_customer_profile y open_dispute en secuencia. Y finalmente el triage_agent otra vez, componiendo la respuesta que llega al chat.

Lo que no vas a ver en ningún lado: un nodo Switch, un nodo IF, ni ninguna condición escrita por ti que dijera "si el mensaje habla de un cobro, ve por aquí". La decisión de llamar a billing_specialist la tomó el modelo del orquestador comparando lo que pidió el cliente contra la Description del especialista. Es exactamente el mismo mecanismo con el que un agente elige entre lookup_order y send_email — solo que la tool elegida resultó ser otro agente.

El segundo mecanismo: un agente dentro de un sub-workflow

Hay una segunda forma nativa de delegar, y conviene conocerla porque en algunos casos es la mejor. Es la que quedó anunciada al final de la lección 6 del Módulo 4: un sub-workflow que tiene un AI Agent adentro, expuesto al orquestador con Call n8n Workflow Tool.

El montaje es este:

# Workflow separado: "Billing Specialist"
Execute Sub-workflow Trigger        ← Input Source: Define Using Fields Below
  (campo: task, tipo String)              declara el contrato de entrada
  → AI Agent (con su modelo, su prompt y sus tools de facturación)
  → Edit Fields (Set)               ← último nodo: define qué se devuelve

# En el workflow del orquestador
Call n8n Workflow Tool
  Description: "Resuelve casos de cobros, cargos no reconocidos..."
  Source: Database
  Workflow: "Billing Specialist"
  Workflow Inputs:
    task = {{ $fromAI("task", "Encargo completo y autocontenido...", "string") }}

Desde el punto de vista del orquestador, esto es indistinguible del AI Agent Tool: una tool con una descripción y un parámetro. La diferencia está del otro lado del cable.

Cuál usar

La regla práctica. Empieza con AI Agent Tool: es más directo, todo se ve en un canvas, y para un sistema de tres especialistas alcanza de sobra. Múdate a sub-workflow cuando aparezca alguna de estas tres cosas:

1. El mismo especialista lo necesita más de un sistema. El especialista de facturación que atiende el chat web también le sirve al agente interno de Slack del equipo de finanzas. Un solo lugar para corregirlo.
2. Quieres poder probarlo aislado. Poder mandarle veinte encargos de prueba a Billing Specialist y revisar sus veinte respuestas, sin pasar por el orquestador, es enormemente valioso cuando estás afinando su prompt.
3. Necesitas pasos alrededor del agente. Validar que el task traiga los campos mínimos antes de gastar una llamada al modelo; normalizar la salida a una forma fija; escribir una línea en un log de auditoría. Todo eso necesita nodos antes y después del agente, y para eso hace falta un workflow.

Las dos formas se pueden mezclar en el mismo orquestador sin problema: dos especialistas como AI Agent Tool y uno como sub-workflow, si eso es lo que corresponde.

Por qué no un Switch: los dos diseños lado a lado

Ya lo dijimos en la lección 1 como advertencia. Ahora que tienes el cableado real, vale la pena ponerlos uno junto al otro, porque las diferencias dejan de ser abstractas.

# DISEÑO VIEJO — simulado con Switch
Chat Trigger
  → Basic LLM Chain  ("clasifica este mensaje: billing | orders | sales")
  → Switch (3 ramas fijas sobre el texto devuelto)
      ├── rama billing → AI Agent con tools de facturación → ¿y ahora qué?
      ├── rama orders  → AI Agent con tools de pedidos     → ¿y ahora qué?
      └── rama sales   → AI Agent con tools de ventas      → ¿y ahora qué?

# DISEÑO NATIVO — delegación por ai_tool
Chat Trigger
  → AI Agent (triage_agent)  ← Postgres Chat Memory
       │ ai_tool
       ├── AI Agent Tool: billing_specialist → sus 3 tools
       ├── AI Agent Tool: order_specialist   → sus 3 tools
       └── AI Agent Tool: sales_specialist   → sus 2 tools

Cuatro diferencias concretas, no de estilo:

1. Un mensaje con dos temas. En el diseño viejo, el Switch toma una rama. Por construcción. El cliente que pregunta por un cargo y por un pedido recibe media respuesta. En el diseño nativo, el orquestador llama dos tools en el mismo turno y compone.

2. El resultado vuelve. En el diseño viejo, una vez que el flujo entró en la rama de facturación, no hay forma natural de que el resultado regrese al que clasificó. Ese "¿y ahora qué?" del diagrama es real: hay que armar a mano el camino de vuelta, y decidir qué hacer si una rama no corrió. En el diseño nativo, el retorno es lo que hace una tool: el resultado vuelve al agente que llamó y ese sigue razonando con él.

3. Se puede volver a decidir. Si el especialista de pedidos reporta "este caso en realidad es de facturación, el cliente habla de un cargo, no de un envío", el orquestador puede leer eso y delegar a quien corresponde en el mismo turno. En el diseño viejo, el Switch ya se ejecutó y no vuelve a ejecutarse.

4. Agregar un especialista. En el diseño nativo: arrastras un nodo, lo conectas al puerto Tool, y agregas una línea al system prompt del orquestador. En el diseño viejo: agregas una rama al Switch, agregas la etiqueta nueva al prompt del clasificador, y revisas la lógica de reunificación que armaste a mano. El primero es una operación de dos minutos; el segundo es un cambio con riesgo de romper lo que ya funcionaba.

Y otra vez la precisión honesta: nada de esto dice que Switch sea un mal nodo. Es excelente para lo que es. Si el canal de entrada te da un campo estructurado —{"department": "billing"} de un formulario— usar un modelo para "decidir" algo que ya viene decidido es tirar dinero. La frontera es esta: Switch para datos, delegación para lenguaje.

Leer la traza anidada

Cuando delegas, tu capacidad de depurar depende enteramente de poder leer qué pasó en cada nivel. Con Return Intermediate Steps activado en los dos —el orquestador y cada especialista— la salida tiene esta forma:

triage_agent
├── llamada al modelo (decide delegar)
├── tool: billing_specialist
│   └── (dentro) billing_specialist
│       ├── llamada al modelo
│       ├── tool: lookup_charge      → sin coincidencias
│       ├── llamada al modelo
│       ├── tool: get_customer_profile → una tarjeta, sin alias
│       ├── llamada al modelo
│       ├── tool: open_dispute       → D-8842
│       └── llamada al modelo (produce su resultado)
├── llamada al modelo (evalúa el resultado)
└── respuesta final al cliente

Cuando algo sale mal, esa estructura te dice en qué nivel buscar, que es la mitad del trabajo:

Ese "qué task recibió" merece un énfasis: es el punto de inspección más útil de todo el sistema. La mitad de los problemas de un sistema multi-agente no están en los agentes sino en lo que se pasan entre ellos, y el task es donde eso se ve escrito, en texto plano, tal como lo redactó el modelo del orquestador. Antes de tocar el prompt de un especialista que "no sabe resolver", lee el encargo que le llegó. Muchas veces la respuesta está ahí.

Errores comunes

Escribir la Description del especialista como si describiera una acción (conceptual). Qué pasa: alguien pone Description: "Consulta cargos y abre disputas" en el billing_specialist. El orquestador empieza a llamarlo solo cuando el cliente usa palabras muy parecidas a "cargo" o "disputa", y deja pasar casos evidentes como "me descontaron de más" o "esto no cuadra con lo que compré". Por qué pasa: es el reflejo del Módulo 4, donde las tools sí eran acciones y describirlas por su acción era correcto. Cómo detectarlo: junta diez mensajes reales de clientes de ese dominio y revisa cuántos comparten vocabulario con tu descripción; si son tres de diez, la descripción es demasiado estrecha. Cómo corregirlo: describe el ámbito y los síntomas, no la mecánica — "úsalo cuando el cliente mencione un monto cobrado, una tarjeta, un estado de cuenta, o diga que algo no le cuadra en lo que le cobraron" — y agrega siempre el "no lo uses para…" que lo separa de sus vecinos.

Pasarle al especialista el mensaje crudo del cliente en vez de un encargo (conceptual). Qué pasa: el $fromAI("task", ...) se define como "el mensaje del cliente", y el especialista recibe "hola, oye, me llegó algo raro en la tarjeta y de paso quería saber lo de mi pedido". El especialista no tiene el ID del cliente (estaba en el sistema, no en el mensaje), no tiene el monto (el cliente lo dijo dos turnos atrás), e intenta resolver también lo del pedido, que no es su dominio. Por qué pasa: reenviar el mensaje tal cual es lo más simple y parece lo más fiel. Cómo detectarlo: lee el task que llegó en la traza; si se parece a cómo escribe un cliente y no a cómo se redacta un encargo interno, ese es el problema. Cómo corregirlo: la description del $fromAI() tiene que exigir un encargo autocontenido, con los datos ya extraídos y con un solo tema — y el system prompt del orquestador tiene que repetir esa regla, porque una sola mención rara vez basta.

Dejar el mismo modelo caro en los cinco agentes (práctico). Qué pasa: alguien conecta el modelo más capaz disponible a los cinco nodos, y el costo por conversación se multiplica sin que la calidad mejore de forma proporcional — el orquestador está tomando una decisión de tres opciones con un modelo pensado para razonamiento complejo. Por qué pasa: el modelo por defecto es el que uno ya tenía configurado, y cambiarlo agente por agente se siente como una micro-optimización prematura. Cómo detectarlo: mira la traza y clasifica cada llamada al modelo por dificultad de la decisión; las del orquestador suelen ser "elegir entre tres opciones bien descritas". Cómo corregirlo: modelo rápido y barato en el orquestador, modelo capaz en los especialistas que toman decisiones costosas, modelo intermedio en el resto — la lección 7 pone los números de esta palanca.

Conectar un especialista y no mencionarlo en el system prompt del orquestador (práctico). Qué pasa: la tool está conectada, el cable se ve en el canvas, y el orquestador casi nunca la llama. Por qué pasa: técnicamente el modelo ve la tool y su descripción aunque el prompt no la nombre, así que "debería funcionar" — y a veces funciona a medias, lo cual es peor que no funcionar, porque parece un problema aleatorio. Cómo detectarlo: cuenta en veinte ejecuciones cuántas veces se llamó cada especialista; si uno tiene cero o casi cero llamadas en casos donde claramente correspondía, es esto. Cómo corregirlo: declara explícitamente el elenco en el system prompt del orquestador, con una línea por especialista y su ámbito — el modelo elige mejor cuando el prompt confirma la política, no solo cuando la tool está disponible.

Conectar la memoria a los especialistas por costumbre (práctico). Qué pasa: al armar cada AI Agent Tool, la mano va sola a conectarle un nodo de memoria porque "así se arma un agente". Aparecen los tres problemas de la lección 3, y además el costo por conversación sube sin explicación visible. Cómo detectarlo: revisa el JSON exportado y busca cuántas entradas ai_memory hay; deberían ser exactamente una, apuntando al orquestador. Cómo corregirlo: deja el puerto Memory del especialista vacío y asegúrate de que el task traiga lo que necesita — si un especialista de verdad necesita hilo propio, esa es la excepción que hay que poder justificar por escrito.

Ejercicios

Ejercicio 1 — Lee el grafo. Te pasan este fragmento de connections de un workflow y te dicen que es un sistema multi-agente con delegación nativa. Di si lo es, y si no, qué está mal:

{
  "connections": {
    "billing_specialist": {
      "main": [[ { "node": "triage_agent", "type": "main", "index": 0 } ]]
    },
    "lookup_charge": {
      "ai_tool": [[ { "node": "billing_specialist", "type": "ai_tool", "index": 0 } ]]
    }
  }
}

Ejercicio 2 — Escribe la Description y el $fromAI(). TuTienda quiere agregar un cuarto especialista: warranty_specialist, que maneja garantías de producto —reclamos por fallas dentro del período de garantía, tramitación de reparaciones y reemplazos por defecto de fábrica—. Ya existen order_specialist (pedidos, envíos, devoluciones por arrepentimiento) y billing_specialist. Escribe la Description del nodo AI Agent Tool y la expresión $fromAI() del campo de prompt.

Description:
  Resuelve reclamos de garantía: productos que fallaron o dejaron de
  funcionar dentro de su período de garantía, tramitación de
  reparaciones y reemplazos por defecto de fábrica. Úsalo cuando el
  cliente diga que algo se dañó, dejó de funcionar, vino defectuoso o
  pregunte por la cobertura de garantía.
  NO lo uses para devoluciones por arrepentimiento —cuando el cliente
  simplemente no quiso el producto— ni para pedidos que llegaron
  dañados en el transporte: esos dos casos son de order_specialist.
  NO lo uses para reclamos de cobro: eso es billing_specialist.

{{ $fromAI(
     "task",
     "Encargo autocontenido para el especialista de garantías. Debe
      incluir: qué producto es (nombre o SKU), cuándo se compró, qué
      falla presenta según el cliente, y el ID del cliente. Este
      especialista NO tiene acceso al historial de la conversación:
      todo dato mencionado en turnos anteriores debe escribirse aquí.
      Si falta alguno de esos datos, escríbelo igual indicando cuál
      falta, para que el especialista pueda reportarlo.",
     "string"
   ) }}

Ejercicio 3 — Elige el mecanismo. Para cada uno de estos tres casos, decide si conviene AI Agent Tool o sub-workflow con agente adentro, y justifica:

(a) Un sales_specialist que solo usa el chat web de TuTienda, con dos tools, todavía en construcción y con el prompt cambiando cada día. (b) Un escalation_specialist que decide si un caso va a un humano, y que van a llamar tanto el agente de chat web como el de WhatsApp como el agente interno de Slack. (c) Un refund_specialist cuya salida hay que registrar siempre en una tabla de auditoría, con marca de tiempo, antes de devolvérsela al orquestador.

Resumen y siguiente paso

Ya sabes delegar de forma nativa. El nodo AI Agent Tool es un agente completo —con su propio Chat Model, sus propias tools y su propio system prompt— que se conecta al puerto ai_tool de otro agente, igual que se conectaba un nodo de Gmail en el Módulo 4. Su Description le dice al que llama cuándo usarlo, describiendo un ámbito y no una acción; el encargo viaja en un $fromAI("task", …) cuya descripción debe exigir que sea autocontenido; y sus Options llevan su system prompt, su Max Iterations y la traza. El segundo mecanismo —un agente dentro de un sub-workflow, expuesto con Call n8n Workflow Tool— es el que conviene cuando el especialista se reutiliza, cuando quieres probarlo aislado, o cuando necesitas pasos alrededor de él. Y en el JSON exportado, la firma del patrón es la misma clase de conexión, ai_tool, apareciendo en dos niveles.

Antes de avanzar deberías poder: conectar un AI Agent Tool al puerto Tool de un agente y explicar por qué esa conexión es ai_tool y no main; escribir una Description de ámbito con su frontera explícita contra los especialistas vecinos; escribir un $fromAI("task", …) que produzca encargos autocontenidos; y leer una traza anidada para saber en qué nivel está un problema.

Lo que todavía está flojo es lo que se pasan entre sí. Hasta ahora, el encargo es un texto libre y la respuesta del especialista también. Eso funciona en la demo y se rompe en cuanto el sistema crece: el orquestador tiene que adivinar, leyendo prosa, si el caso quedó resuelto, si falta un dato o si hace falta un humano. La lección 5 convierte ese intercambio en un contrato explícito —qué entra, qué sale, con qué campos, y qué pasa cuando el especialista no puede resolver—, que es la misma disciplina del contrato de tools del Módulo 4 aplicada entre agentes.

Recursos

• AI Agent Tool node — n8n Docs — la referencia del sub-nodo central de esta lección: sus parámetros, sus puertos y sus opciones. Verifica ahí los nombres exactos de los campos en tu versión.
• AI Agent node — n8n Docs — el nodo raíz que hace de orquestador, con su puerto Tool sin límite de conexiones.
• Call n8n Workflow Tool — n8n Docs — el segundo mecanismo de delegación: Description, Source y el mapeo de Workflow Inputs.
• Execute Sub-workflow Trigger — n8n Docs — cómo declarar el contrato de entrada con Define Using Fields Below y por qué el último nodo define la respuesta.
• Use AI for parameters ($fromAI) — n8n Docs — sintaxis de los cuatro argumentos; la description es la que decide la calidad de los encargos que redacta el orquestador.
• How tools work — n8n Docs — el mecanismo de selección de tools, que es el mismo tanto si la tool es un nodo de Gmail como si es un agente completo.