1. Introducción: agentes que delegan

Descripción

Al terminar esta lección vas a poder explicar por qué un sistema serio de 2026 se construye con varios agentes coordinados en vez de con uno solo que intenta saberlo todo, reconocer las tres señales concretas de que tu agente ya cruzó el límite de lo que puede sostener solo, y vas a tener el mapa completo de las ocho lecciones de este módulo — incluyendo la diferencia, que es el corazón de todo lo que sigue, entre delegar de verdad y simular una delegación con lógica manual.

Esto importa porque el agente que dejaste construido en el Módulo 4 funciona. Consulta el CRM, consulta la base de conocimiento, manda correos, crea tickets, sabe cuándo pedirle permiso a una persona. Y precisamente por eso es que va a empezar a fallar: cada vez que resuelve un caso nuevo, alguien del equipo le agrega una tool más y un párrafo más al system prompt. A las tres tools el agente es preciso. A las nueve, empieza a elegir la tool equivocada, a mezclar el tono de ventas con el de soporte, y a olvidar la regla que le escribiste hace dos semanas porque quedó sepultada entre otras veinte. Nadie rompió nada — simplemente le pediste a una sola pieza que sostuviera cuatro responsabilidades distintas. Este módulo es la respuesta a eso, y es también el punto donde las ofertas de trabajo dejan de hablar de "automatizar con IA" y empiezan a hablar de "flujos de agentes multi-paso".

Conexión con el módulo: esta es la primera lección del Módulo 5, y es puro mapa. No vas a conectar nada todavía. La lección 2 va a diagnosticar con precisión por qué el agente monolítico se degrada; la 3 te da el patrón de diseño; la 4 —la lección central de este módulo— te muestra el cableado real: un nodo AI Agent conectado al puerto ai_tool de otro nodo AI Agent. Todo lo que traes del Módulo 4 sigue vigente: el contrato de una tool (lección 5 de ese módulo) es literalmente la base del contrato entre agentes que vas a escribir en la lección 5 de este, y el sub-workflow expuesto como tool (lección 6) es el segundo mecanismo de delegación que vas a comparar.

La tienda que creció y no contrató a nadie más

Piensa en un negocio de barrio que arrancó con una sola persona en el mostrador. Al principio funciona perfecto: llega alguien, pregunta un precio, se lo dan; llega otro, quiere devolver algo, se lo resuelven. Una persona, todos los casos, cero fricción — porque la cantidad de cosas que hay que saber cabe cómodamente en la cabeza de alguien.

Ahora el negocio creció. La misma persona atiende el mostrador, factura, negocia con proveedores, resuelve reclamos y además intenta vender el producto nuevo. Todavía "funciona": nadie se va sin atención. Pero pasan cosas raras. Le explica la política de devoluciones a alguien que solo quería saber un horario. Le ofrece la promoción del mes a un cliente que está enojado por un cobro mal hecho. Se equivoca de formulario porque hay cinco formularios parecidos sobre el mostrador. Y cuando le pides que cambie una regla —"a partir de ahora las devoluciones de electrónicos son a 14 días"— tienes que confiar en que va a recordar eso, específicamente eso, en medio de todo lo demás que le pediste.

Nadie diría que la solución es contratar a una persona más inteligente. La solución es obvia: separar el mostrador de la caja, y la caja de los reclamos. Cada persona con un ámbito claro, con sus propios formularios sobre su propio escritorio, y alguien adelante que escucha lo que el cliente necesita y lo manda a donde corresponde. Eso no es "más gente por gusto" — es que el trabajo se volvió de un tipo que una sola cabeza no sostiene bien, por buena que sea.

Un agente de IA está exactamente en esa posición. El modelo no "se cansa", pero sí tiene un presupuesto finito de atención: todo lo que le pones en el system prompt y todas las descripciones de sus tools compiten entre sí en el mismo contexto, en cada turno. Cuando le das cuatro responsabilidades y nueve tools, no le estás dando más capacidad — le estás dando más cosas entre las cuales confundirse. Y a diferencia de la persona del mostrador, el agente no te va a decir "oye, esto ya no me cabe". Simplemente va a empezar a equivocarse de forma silenciosa, en casos concretos, y tú lo vas a descubrir por un cliente molesto.

La salida es la misma que en el negocio: en vez de un agente omnipotente, un equipo de agentes. Uno que recibe al cliente y decide de qué se trata el caso. Otros que resuelven un ámbito cada uno, con sus propias tools y su propia forma de responder. Y una delegación real entre ellos: el primero no "adivina" la respuesta del segundo, se la pide.

Ejemplo trabajado: el mismo mensaje, dos arquitecturas

Vamos a correr un mensaje real de un cliente de TuTienda contra dos configuraciones. El modelo es el mismo en las dos, las tools disponibles son las mismas en total, y la memoria es la misma. Lo único que cambia es cómo está repartido el trabajo.

Mensaje del cliente: "Hola, me llegó un cobro de $1,200 que no reconozco en la tarjeta, y de paso quería saber si el pedido #4521 ya salió. Gracias."

Fíjate que es un mensaje perfectamente normal y perfectamente incómodo: trae dos temas de dominios distintos —uno financiero y sensible, otro logístico y trivial— en una sola frase, como hablan las personas de verdad.

Configuración A — un solo agente con todo encima

# Nodo: AI Agent — Name: support_agent (el monolito del Módulo 4)
#
# System Message (resumido — el real tiene ~900 palabras):
#   Eres el agente de atención de TuTienda. Puedes resolver dudas de
#   pedidos, cobros, devoluciones y también recomendar productos.
#   Para pedidos usa lookup_order. Para cobros usa lookup_charge y,
#   si el cliente no reconoce el cargo, usa open_dispute — pero nunca
#   prometas un reembolso. Para devoluciones revisa la política:
#   30 días general, 14 días electrónicos... (siguen 6 párrafos más)
#
# Tools conectadas al puerto ai_tool (9):
#   lookup_order, lookup_charge, open_dispute, create_ticket,
#   send_email, check_refund_eligibility, search_knowledge_base,
#   get_customer_profile, recommend_products

Qué esperar — Configuración A. El agente lee el mensaje y tiene que resolver, en un solo turno de razonamiento, tres cosas a la vez: qué temas hay, en qué orden atenderlos, y cuál de nueve tools aplica a cada uno. En la mayoría de las corridas lo hace bien. Pero en una fracción no despreciable de casos pasa alguna de estas tres cosas:

• Atiende solo el segundo tema (el pedido) porque es el más fácil de resolver con una sola tool, y el cobro no reconocido —el que de verdad le importa al cliente— se queda sin respuesta.
• Llama a check_refund_eligibility en vez de open_dispute, porque las dos descripciones hablan de "cliente que no está conforme con un cargo" y el modelo elige entre ellas por parecido semántico.
• Cierra con una recomendación de producto, porque el system prompt también le dijo que recomiende, y nada en ese prompt le dice que un cliente con un cobro en disputa no es el momento.

Ninguno de esos tres resultados dispara un error en n8n. La ejecución aparece en verde. El problema solo se ve leyendo la conversación.

Configuración B — un equipo con delegación

# Nodo: AI Agent — Name: triage_agent (el orquestador)
#
# System Message (resumido):
#   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 directamente.
#   Si un mensaje trae más de un tema, delega cada tema por separado.
#
# Tools conectadas al puerto ai_tool (3, y todas son agentes):
#   order_specialist    — pedidos, envíos, estado y entregas
#   billing_specialist  — cobros, disputas y facturación
#   sales_specialist    — recomendaciones y preguntas de producto

# Nodo: AI Agent Tool — Name: billing_specialist
#
# Tool Description (esto es lo que lee el triage_agent para decidir):
#   Resuelve cualquier caso relacionado con cobros, cargos no
#   reconocidos, disputas y facturación. Úsalo cuando el cliente
#   mencione un monto cobrado, una tarjeta o una factura.
#   NO lo uses para estado de pedidos ni para devoluciones de producto.
#
# System Message (propio de este agente, ~150 palabras):
#   Eres el especialista en facturación de TuTienda...
#
# Tools propias (3): lookup_charge, open_dispute, get_customer_profile

Qué esperar — Configuración B. El triage_agent lee el mismo mensaje. Su decisión es mucho más pequeña: no tiene que elegir entre nueve tools ni recordar la política de devoluciones, porque nada de eso está en su contexto. Solo tiene que contestar una pregunta: ¿de qué se trata esto y a quién se lo paso? Reconoce dos temas y delega dos veces —primero a billing_specialist con el asunto del cargo, después a order_specialist con el número de pedido—. Cada especialista razona dentro de su propio ámbito, con sus propias tres tools y su propio system prompt corto, y devuelve un resultado. El triage_agent recibe las dos respuestas y compone un solo mensaje para el cliente:

"Revisé las dos cosas. Sobre el cobro de $1,200: no aparece asociado a ninguna compra tuya en los últimos 60 días, así que abrí la disputa #D-8842 y el equipo de facturación la revisa en 48 horas hábiles. Sobre el pedido #4521: salió ayer del centro de distribución y llega entre mañana y pasado."

Nota lo que cambió y lo que no. El modelo es el mismo. Las nueve tools siguen existiendo, solo que repartidas. Lo que cambió es que ninguna decisión individual es grande. El triage elige entre tres opciones bien separadas; cada especialista elige entre tres tools de un mismo dominio. Ese es todo el truco, y es la razón por la que un equipo de agentes acierta más que un agente que sabe lo mismo pero tiene que sostenerlo todo junto.

Y nota algo más, que va a ser el hilo de la lección 4: en la Configuración B nadie escribió un Switch que dijera "si el mensaje contiene la palabra 'cobro', ve a la rama de facturación". El triage_agent decidió delegar porque leyó las descripciones de sus tres agentes-tool y eligió. Eso es una decisión del modelo, no una condición que alguien dibujó de antemano.

El mapa de este módulo

Las siete lecciones que siguen desarman ese ejemplo pieza por pieza:

Lección	Qué resuelve
2	El diagnóstico: qué exactamente se degrada en un agente monolítico y con qué criterio se separan responsabilidades
3	El patrón orquestador-trabajador: quién coordina, quién ejecuta, y cuándo este patrón aplica y cuándo no
4	El cableado real: conectar un nodo AI Agent como tool de otro agente, con bucles agénticos nativos
5	El contrato entre agentes: rol, handoff, qué entra, qué sale y qué pasa cuando un especialista no puede resolver
6	Las condiciones de parada: cómo evitar que dos agentes se deleguen trabajo entre sí para siempre
7	El precio de todo esto: cada delegación es otra llamada al modelo — cuánto cuesta, cuánto tarda y cuándo no vale la pena
8	Mini-proyecto: un sistema triage → especialista funcionando de punta a punta, con sus handoffs verificados

El orden no es casual. Las lecciones 2 y 3 son de criterio: cuándo separar y cómo repartir. La 4 es de mecánica: el nodo y la conexión. La 5 y la 6 son de disciplina: sin contrato, los agentes se pasan basura entre sí; sin condiciones de parada, se pasan basura entre sí indefinidamente. La 7 es el contrapeso honesto —multi-agente no es gratis, y hay casos donde es la decisión equivocada—. Y la 8 ensambla todo.

Al final de este módulo vas a tener la capacidad concreta que declara el módulo: diseñar un sistema donde un agente orquestador delega en agentes especialistas, con handoffs y contratos claros, controlando condiciones de parada, costo y latencia. Esa frase, casi palabra por palabra, es lo que las ofertas describen como "diseñar flujos de agentes multi-paso".

Delegación nativa contra delegación simulada

Hay una distinción que conviene dejar clara desde ahora, porque es el motivo por el que este módulo existe y es donde más material en español se quedó viejo.

Durante años, la única forma de armar "algo parecido a un equipo de agentes" en n8n era simularla. El patrón era este: un primer nodo de IA clasificaba el mensaje y devolvía una etiqueta —"billing", "orders", "sales"—; un nodo Switch leía esa etiqueta y mandaba el flujo por una de tres ramas; y en cada rama había otro nodo de IA con su propio prompt. Funcionaba, en el sentido de que producía respuestas. Pero mira con cuidado qué era realmente:

# El patrón VIEJO (simulado) — NO es lo que vas a construir
Chat Trigger
  → AI (clasificador que devuelve una etiqueta de texto)
  → Switch (3 ramas fijas, escritas a mano)
      ├── rama "billing"  → AI con prompt de facturación
      ├── rama "orders"   → AI con prompt de pedidos
      └── rama "sales"    → AI con prompt de ventas
  → (y aquí alguien tenía que resolver a mano cómo volver a juntar todo)

Tres cosas de ese diagrama no son delegación:

1. El camino está fijado de antemano. Las tres ramas existen antes de que llegue el primer mensaje. Si el cliente trae un caso que no encaja en ninguna, no hay nada que hacer; y si trae dos temas a la vez, como el ejemplo de arriba, el Switch toma una sola rama por definición.
2. No hay vuelta. Una vez que el flujo entró en la rama de facturación, no existe forma natural de que el resultado regrese a quien decidió, para que ese decida si hace falta algo más. Cada regreso hay que programarlo con nodos adicionales.
3. No hay bucle agéntico entre las piezas. El clasificador no puede pedir una aclaración, recibirla, y volver a decidir. Emite una etiqueta y se acabó su participación.

La delegación nativa que vas a construir en la lección 4 no tiene esas tres limitaciones, porque el especialista no es una rama: es una tool. Y una tool, como aprendiste en el Módulo 4, se llama cuando el modelo decide, con los argumentos que el modelo arma, tantas veces como el modelo considere necesario, y su resultado vuelve al agente que la llamó para que siga razonando con esa información en mano. Cuando esa tool es a su vez un agente completo —con su modelo, su prompt y sus propias tools—, lo que tienes es un bucle agéntico dentro de otro bucle agéntico. Eso es lo que n8n 2.0 permite de forma nativa y lo que el material escrito antes de esta capacidad no podía enseñar.

Si en algún momento de este módulo te descubres dibujando un Switch para repartir trabajo entre agentes, detente: eso es el patrón viejo, y la lección 4 te va a dar la versión que sí escala.

Una precisión honesta antes de seguir: esto no significa que IF y Switch estén prohibidos en n8n ni que sean malos nodos. Son excelentes para lógica determinista —"si el ticket es de un cliente premium, notifica al canal VIP"—, donde tú, no el modelo, debes decidir el camino. Lo que este módulo dice es más preciso: no uses lógica determinista para tomar una decisión que depende de entender lenguaje natural. Esa decisión es del modelo, y el mecanismo para dársela es una tool.

Errores comunes

Creer que "multi-agente" significa "más agentes es mejor" (conceptual). Qué pasa: alguien lee este módulo, vuelve a su workflow y parte un agente que funcionaba bien en cinco agentes especializados, uno por cada tool que tenía. El sistema se vuelve más lento, más caro, y encima menos preciso, porque ahora hay cinco traspasos de información donde antes había cero. Por qué pasa: la palabra "arquitectura multi-agente" suena a mejora por sí sola, y es fácil confundir un patrón de diseño con una meta. Cómo detectarlo: cuenta cuántas tools tenía tu agente original y cuántas responsabilidades distintas cubría; si eran tres tools de un mismo dominio y una sola responsabilidad, no tenías un problema que la delegación resuelva. Cómo corregirlo: espera a la lección 2, que te da las señales concretas de saturación, y a la lección 7, que te pone números sobre la mesa — delegar cuesta llamadas al modelo, y ese costo tiene que comprarte algo real.

Pensar que el orquestador "es el que sabe" y los especialistas solo ejecutan (conceptual). Qué pasa: alguien escribe un triage_agent con un system prompt de 800 palabras que explica la política de devoluciones, las reglas de facturación y el catálogo de productos, y después le conecta especialistas con prompts de dos líneas. El resultado es el monolito otra vez, solo que con pasos extra. Por qué pasa: es intuitivo pensar en el orquestador como "el jefe" y asumir que el jefe tiene que saber más que todos. Cómo detectarlo: si el system prompt de tu orquestador menciona una regla de negocio específica —un plazo, un monto, una política—, esa regla está en el agente equivocado. Cómo corregirlo: el orquestador sabe quién hace qué, no cómo se hace cada cosa; el conocimiento de dominio vive en el especialista que lo usa, y ese reparto es exactamente lo que vas a formalizar en la lección 5.

Empezar a construir el sistema del mini-proyecto antes de tener el módulo 4 terminado (práctico). Qué pasa: llegas a la lección 4 con ganas de conectar agentes entre sí, pero el agente base que traes no tiene ni tools reales conectadas ni contratos escritos, así que cuando el especialista falla no puedes distinguir si el problema es la delegación o la tool de abajo. Por qué pasa: la delegación es la parte llamativa del módulo y da la sensación de que se puede saltar directo a ella. Cómo detectarlo: si no puedes señalar en tu workflow al menos dos tools con su Description escrita y su $fromAI() con descripción por parámetro, todavía te falta el Módulo 4. Cómo corregirlo: un sistema multi-agente hereda todos los problemas de sus tools, multiplicados por la cantidad de agentes — resuelve la capa de tools primero y este módulo se vuelve mucho más simple.

Ejercicios

Ejercicio 1 — Cuenta las responsabilidades de tu agente. Toma el system prompt del agente que construiste en el Módulo 4 (o el de la Configuración A de esta lección) y subraya cada frase que empiece una responsabilidad distinta: "resuelve dudas de pedidos", "recomienda productos", "aplica la política de devoluciones". Cuenta cuántas hay. Después cuenta cuántas tools tiene conectadas. Escribe los dos números.

Ver solución

Para la Configuración A de esta lección: cuatro responsabilidades (pedidos, cobros, devoluciones, recomendación de producto) y nueve tools. No hay un umbral mágico —la lección 2 te da las señales reales—, pero dos números así ya te dicen algo: cada vez que el agente razona, tiene que sostener cuatro marcos mentales distintos y elegir entre nueve opciones, todo en el mismo contexto.

Si tu propio agente dio "una responsabilidad, tres tools", estás en la zona cómoda y este módulo te sirve como diseño para cuando crezca, no como reparación urgente. Si dio "cuatro y nueve" o más, ya estás en el territorio de la lección 2.

Por qué funciona: el ejercicio convierte una intuición vaga ("mi agente se está poniendo complicado") en dos números que puedes volver a medir después de separar, y comparar.

Ejercicio 2 — Reparte el mensaje. Este mensaje llega al chat de TuTienda: "buenas, quiero devolver los audífonos que compré el mes pasado porque no me gustaron, y ya que estoy, ¿tienen algo parecido pero con cancelación de ruido? mi presupuesto es hasta $800." Con el equipo de la Configuración B (order_specialist, billing_specialist, sales_specialist), ¿a quién o a quiénes delegaría el triage_agent, en qué orden, y qué le pasaría a cada uno?

Ver solución

Dos delegaciones. Primero a order_specialist, que es quien maneja devoluciones de producto —el mensaje habla de devolver algo comprado hace un mes, y ahí hay una regla de plazo que hay que verificar—. Después a sales_specialist, con la petición de recomendación y el presupuesto de $800.

El orden importa por una razón práctica: la respuesta de la primera delegación puede cambiar el sentido de la segunda. Si los audífonos resultan estar fuera del plazo de devolución (son electrónicos, 14 días), la recomendación de un producto de reemplazo se plantea distinto —"no podemos aceptar la devolución, pero si quieres cambiar de equipo, esto es lo que tenemos"— que si la devolución sí procede.

Lo que NO hace el triage_agent es resolver ninguna de las dos cosas por su cuenta. No consulta el plazo, no mira el catálogo. Su respuesta final es la composición de lo que le devolvieron los dos especialistas.

Por qué funciona: el ejercicio muestra que "delegar" no es "elegir una rama". Un mismo mensaje puede disparar dos delegaciones, en un orden que el modelo decide, y con la segunda informada por el resultado de la primera — algo que un Switch no puede hacer por construcción.

Ejercicio 3 — Detecta el patrón viejo. Alguien te comparte este workflow y te dice que es "un sistema multi-agente":

Chat Trigger
  → Basic LLM Chain (clasifica y devuelve "soporte" | "ventas")
  → Switch (2 ramas según el texto devuelto)
      ├── rama "soporte" → AI Agent con tools de soporte
      └── rama "ventas"  → AI Agent con tools de ventas

Nombra al menos dos cosas concretas que este diseño no puede hacer, y que la delegación nativa sí.

Ver solución

Tres respuestas válidas, con dos alcanza:

1. No puede atender un mensaje con dos temas. El Switch toma una rama y solo una. Un cliente que pregunta por un cargo y por un pedido en el mismo mensaje va a quedar con la mitad de su caso sin responder.
2. No puede volver a decidir con información nueva. Si el agente de soporte descubre a mitad de camino que en realidad el caso es de ventas, no hay forma de que el flujo regrese al clasificador: ya pasó por el Switch y ese nodo no se ejecuta dos veces en el mismo camino.
3. No puede componer una respuesta única. Cada rama termina en su propio agente, y juntar dos resultados en un solo mensaje al cliente exige nodos adicionales escritos a mano, con su propia lógica de "qué hago si una rama no corrió".

Por qué funciona: las tres limitaciones vienen del mismo origen — el camino está decidido antes de conocer el caso. En la delegación nativa el especialista es una tool, y una tool se puede llamar cero, una o varias veces, en el orden que el razonamiento requiera, con el resultado volviendo siempre a quien la llamó.

Resumen y siguiente paso

Lo que viste en esta lección es el marco completo antes del primer cable: un agente monolítico se degrada no porque el modelo sea malo, sino porque le pediste sostener varias responsabilidades y muchas tools en un mismo contexto; la salida es un equipo donde cada agente toma decisiones pequeñas dentro de un ámbito claro; y la diferencia entre delegar de verdad y simularlo con un Switch es que en la delegación nativa el especialista es una tool que el modelo elige llamar, cuyo resultado vuelve a quien la llamó.

Antes de avanzar a la lección 2 deberías poder: explicar en una frase por qué la Configuración B acierta más que la A aunque tengan el mismo modelo y las mismas nueve tools; nombrar las tres cosas que un Switch no puede hacer y una delegación sí; y decir cuántas responsabilidades y cuántas tools tiene hoy tu propio agente.

Lo que todavía no tienes es el criterio preciso. "Cuatro responsabilidades y nueve tools" suena a mucho, pero ¿mucho comparado con qué? ¿Qué se degrada exactamente, y a partir de qué señal concreta conviene separar? Esa es la lección 2: el diagnóstico del agente monolítico, y la regla para cortar por el lugar correcto.

Recursos

• What agents do — n8n Docs — la definición oficial de agente en n8n, la base sobre la que este módulo construye la idea de un agente que llama a otro.
• AI Agent node — n8n Docs — referencia del nodo raíz y de su puerto ai_tool, que en la lección 4 vas a usar para conectar un agente completo en vez de una tool simple.
• How tools work — n8n Docs — cómo el modelo elige una tool a partir de su descripción; el mismo mecanismo que decide a qué especialista delegar.
• Building Effective AI Agents — Anthropic — el artículo que popularizó el vocabulario de orquestador-trabajador y la advertencia de no agregar complejidad multi-agente sin una razón medible.
• Switch node — n8n Docs — el nodo del patrón viejo; vale la pena conocerlo bien para saber exactamente dónde sí sirve (lógica determinista) y dónde no (decidir con lenguaje natural).