3. El patrón orquestador-trabajador

Descripción

Al terminar esta lección vas a poder repartir los papeles de un sistema multi-agente con un criterio explícito —qué posee el orquestador, qué posee cada trabajador, y qué no debe poseer ninguno de los dos—, vas a poder distinguir el patrón orquestador-trabajador de otras dos formas de repartir trabajo que se le parecen y se confunden con él (la cadena fija y el enrutador de un solo salto), y vas a poder decidir cuál de las tres corresponde a un caso concreto antes de tocar el canvas.

Esto importa porque la lección anterior te dejó cuatro responsabilidades recortadas sobre papel, y una lista de responsabilidades todavía no es un sistema. Falta lo que decide si el sistema funciona o se vuelve un enredo: quién es dueño de la conversación con el cliente, quién guarda la memoria, quién decide que un caso ya está cerrado, y qué pasa cuando un especialista se topa con algo que no le corresponde. Si esas cuatro preguntas no tienen una respuesta clara antes de empezar a conectar nodos, lo que vas a construir es un monolito repartido en varias piezas —el peor de los dos mundos: la complejidad del equipo sin la precisión del especialista—. Y esto es, además, lo que se te va a pedir explicar en una entrevista: nadie pregunta "¿sabes conectar un agente a otro?"; preguntan "¿cómo estructuraste el sistema y por qué?".

Conexión con el módulo: la lección 2 te dio el criterio para cortar por responsabilidad y te dejó con cuatro piezas sueltas —order_specialist, billing_specialist, sales_specialist y triage_agent—. Esta lección les da forma de arquitectura: el reparto de papeles, quién posee qué, y qué patrón corresponde. Sigue siendo diseño en papel: la conexión real entre un agente y otro es la lección 4. Lo que definas aquí es lo que vas a cablear ahí, y el contrato exacto de cada handoff es la lección 5.

La persona de triage en una clínica

En la entrada de urgencias de una clínica hay alguien cuyo trabajo no es curar a nadie. Escucha lo que trae cada persona que llega, hace dos o tres preguntas, y decide a dónde la manda: a traumatología, a cardiología, a observación. No pone un yeso, no lee un electrocardiograma, no receta nada. Si le preguntas qué sabe de medicina, la respuesta honesta es: lo suficiente para reconocer de qué se trata cada caso, y nada más.

Fíjate en tres cosas de esa persona, porque las tres van a ser reglas de diseño.

Primero: es la única que habla con quien llega. El paciente le explica el problema a ella, en su lenguaje, desordenado, con dos síntomas mezclados y una preocupación de fondo que no dijo. Ella traduce eso a un encargo concreto para el especialista: "varón, 40, dolor torácico de 2 horas, sin antecedentes". El cardiólogo no recibe el relato completo del paciente — recibe el encargo.

Segundo: el conocimiento profundo no está en ella. Está en cada especialista. Y eso es a propósito: si le pidieras a la persona de triage que también supiera cardiología, traumatología y pediatría, dejaría de ser buena en lo único que necesita ser buena, que es reconocer rápido de qué se trata cada caso.

Tercero: el caso vuelve. El cardiólogo no despide al paciente por su cuenta ni decide si el caso terminó. Emite un resultado —"descartado infarto, es muscular"— y ese resultado regresa al flujo de atención, donde alguien decide si con eso alcanza o si hace falta pasar por otro servicio. Ese regreso es lo que permite que un paciente con dos problemas reciba una sola respuesta coherente al final, en vez de dos altas médicas contradictorias.

Ese es el patrón orquestador-trabajador completo: alguien que recibe, traduce y reparte; especialistas que resuelven dentro de su ámbito y devuelven un resultado; y una composición final que junta todo en una sola respuesta.

Anatomía del patrón: quién posee qué

La palabra que hace todo el trabajo aquí es poseer. No "puede hacer" — poseer. En un sistema bien repartido, cada cosa tiene exactamente un dueño, y las fallas más comunes son casos donde dos piezas creen ser dueñas de lo mismo, o donde algo no tiene dueño.

El orquestador

El orquestador —en nuestro caso, el triage_agent— posee cuatro cosas:

1. La conversación con el cliente. Es el único que recibe el mensaje crudo y el único que emite el texto que el cliente lee. Todo lo que un especialista produce pasa por él antes de salir. Esto no es formalismo: es lo que garantiza que el cliente reciba una sola voz, un solo tono y una sola respuesta aunque el caso haya tocado tres dominios.

2. La memoria de la sesión. El nodo de memoria —lo que construiste en el Módulo 3, con su session ID por cliente— se conecta al puerto ai_memory del orquestador, y solo ahí. Los especialistas no llevan memoria de la conversación. Cada llamada a un especialista es, desde su punto de vista, un encargo nuevo y autocontenido. Esto es contraintuitivo al principio y es una de las decisiones más importantes del patrón; volvemos sobre ella en un momento.

3. La decisión de a quién delegar y cuándo. Incluyendo la decisión de delegar más de una vez, o de no delegar en absoluto. Si el cliente escribe "hola", el orquestador responde "hola, ¿en qué te ayudo?" sin molestar a nadie.

4. La decisión de que el caso está cerrado. El especialista dice "esto es lo que encontré". El orquestador decide si con eso alcanza para responderle al cliente o si falta algo. Esa decisión no es del trabajador.

Y hay dos cosas que el orquestador no posee, que es donde más se falla:

• No posee conocimiento de dominio. Nada de plazos, montos, políticas ni nombres de campos de la base de datos. Si su system prompt menciona "14 días" o "$800", ese conocimiento está en el agente equivocado.
• No posee tools de acción sobre sistemas. El orquestador no manda correos, no abre disputas, no escribe en la base de datos. Sus tools son los especialistas. Una excepción razonable: puede tener alguna tool de lectura muy genérica —identificar al cliente por su número de teléfono, por ejemplo— si eso es lo que necesita para poder repartir. Pero en cuanto le conectas una tool que actúa, empezaste a reconstruir el monolito.

El trabajador

Cada especialista —order_specialist, billing_specialist, sales_specialist— posee tres cosas:

1. Su dominio completo. Todo el conocimiento necesario para cerrar los casos de su ámbito: las reglas, los plazos, las excepciones, el vocabulario. Está en su system prompt, que es corto precisamente porque solo cubre un dominio.

2. Sus tools. Las que necesita y solo esas. Un especialista que necesita una tool que pertenece claramente a otro es una señal de que el corte de la lección 2 quedó mal hecho.

3. Su propio bucle agéntico. Y esto es lo que lo hace un agente y no una función: puede llamar una tool, mirar el resultado, decidir que hace falta otra, llamarla, y recién entonces producir su resultado. Ese razonamiento interno es suyo y el orquestador no lo dirige.

Y tres cosas que el trabajador no posee:

• No habla con el cliente. Su salida es un resultado para el orquestador, no un mensaje para una persona. Escribir el prompt de un especialista en tono de atención al cliente —"responde con calidez y tuteo"— es un error sutil pero costoso: produce texto pensado para leerse, que el orquestador después tiene que reinterpretar o reenviar tal cual, y cuando hubo dos especialistas el cliente recibe dos saludos y dos despedidas pegados.
• No decide si el caso terminó. Reporta su estado —resuelto, no resuelto, hace falta esto otro— y el orquestador decide.
• No delega en otros especialistas. Al menos no por defecto. Un trabajador que puede llamar a otro trabajador abre la puerta a la delegación circular, que es el problema completo de la lección 6. La regla simple de arranque: los trabajadores son hojas del árbol.

La tabla de propiedad

Por qué la memoria vive solo en el orquestador

Vale la pena detenerse aquí porque es la decisión que más gente invierte al principio.

La tentación es darle memoria a cada especialista, con el argumento de que "así recuerda al cliente". Suena bien y produce tres problemas concretos.

Duplicación de historia. Si el orquestador tiene la conversación y el especialista también, la misma información viaja dos veces al modelo en cada turno: una en el contexto del orquestador y otra en el del especialista. Pagas por los mismos tokens dos veces y no ganas nada — la lección 7 pone el número.

Historias que se desincronizan. El especialista de facturación solo se ejecuta cuando lo llaman. Si en una conversación de diez turnos lo llamaron dos veces, su memoria tiene dos entradas de una conversación de diez. Esa memoria parcial es peor que ninguna: el especialista cree tener contexto y en realidad tiene fragmentos sin los turnos intermedios que les daban sentido.

Ambigüedad sobre quién es la fuente de verdad. Si el orquestador cree que el cliente ya dio su número de pedido y el especialista no lo tiene en su historia, ninguno de los dos está equivocado y el sistema no tiene forma de resolverlo.

La alternativa correcta es simple: el orquestador es dueño de la historia y le pasa al especialista lo que necesita, ya digerido. Si el cliente dio su número de pedido tres turnos atrás, el orquestador lo incluye en el encargo. El especialista trabaja sin memoria, con todo lo que necesita en el encargo mismo. Eso lo hace además reproducible: puedes probar un especialista aislado mandándole un encargo y ver exactamente qué devuelve, sin depender del estado de una conversación.

Hay una excepción legítima, y es la única: un especialista que por su naturaleza mantiene un hilo largo y propio con el cliente —piensa en un agente de "onboarding" que guía un proceso de siete pasos a lo largo de días—. Ahí sí tiene sentido darle su propia memoria con su propio session ID. Pero es la excepción, y conviene poder justificarla.

Ejemplo trabajado: el sistema de TuTienda, dibujado y ejecutado

Así queda el reparto de la lección 2, ya con forma de arquitectura:

                        ┌──────────────────────┐
   Chat Trigger ──────► │  triage_agent        │ ◄── Postgres Chat Memory
                        │  (orquestador)       │     (session ID = customer_id)
                        │                      │
                        │  Chat Model: rápido  │
                        └──────────┬───────────┘
                                   │ ai_tool
              ┌────────────────────┼────────────────────┐
              ▼                    ▼                    ▼
    ┌───────────────────┐ ┌──────────────────┐ ┌──────────────────┐
    │ order_specialist  │ │ billing_specialist│ │ sales_specialist │
    │ (trabajador)      │ │ (trabajador)      │ │ (trabajador)     │
    │                   │ │                   │ │                  │
    │ Chat Model: fuerte│ │ Chat Model: fuerte│ │ Chat Model: medio│
    │ sin memoria       │ │ sin memoria       │ │ sin memoria      │
    └─────────┬─────────┘ └─────────┬────────┘ └────────┬─────────┘
              │ ai_tool             │ ai_tool           │ ai_tool
      ┌───────┼───────┐      ┌──────┼──────┐      ┌─────┴──────┐
      ▼       ▼       ▼      ▼      ▼      ▼      ▼            ▼
  lookup_  check_  create_  lookup_ open_ get_  recommend_  search_
  order    refund_ ticket   charge  disp. cust. products    knowledge_
           elig.                    ute   prof.             base

Tres cosas para leer en ese dibujo:

• La memoria cuelga del orquestador y de nadie más.
• Cada trabajador tiene su propio modelo conectado. No tienen que ser el mismo — el orquestador toma una decisión simple y puede correr con un modelo más rápido y barato; el especialista de facturación toma decisiones caras y merece el modelo más capaz. Este reparto de modelos es una de las palancas de costo de la lección 7.
• Las tools de acción están todas en el segundo nivel. El orquestador no tiene ninguna.

Ahora la traza de una ejecución real. El cliente escribe el mensaje de la lección 1 —el del cargo no reconocido más el pedido— y esto es lo que aparece en intermediateSteps del orquestador:

# Traza de ejecución de triage_agent (con returnIntermediateSteps = true)

paso 1  → llamada al modelo del orquestador
          decide: hay dos temas, delego el primero

paso 2  → tool: billing_specialist
          input:  { "task": "El cliente reporta un cargo de $1,200 que no
                     reconoce. Cliente ID: C-9931. Verificar el cargo y,
                     si no corresponde a ninguna compra, abrir disputa." }

          ─── dentro de billing_specialist (su propio bucle) ───
          paso 2.1 → llamada al modelo del especialista
          paso 2.2 → tool: lookup_charge  ($1,200, últimos 60 días)
                     resultado: sin coincidencias
          paso 2.3 → tool: get_customer_profile (C-9931)
                     resultado: una sola tarjeta registrada, sin alias
          paso 2.4 → tool: open_dispute
                     resultado: { "dispute_id": "D-8842", "sla_hours": 48 }
          paso 2.5 → llamada al modelo del especialista
          ──────────────────────────────────────────────────────

          output: { "status": "resolved",
                    "summary": "Cargo de $1,200 no corresponde a ninguna
                                compra registrada. Disputa D-8842 abierta,
                                revisión en 48 h hábiles.",
                    "needs_human": false }

paso 3  → llamada al modelo del orquestador
          decide: falta el segundo tema, delego

paso 4  → tool: order_specialist
          input:  { "task": "Consultar estado del pedido #4521 del cliente
                     C-9931 e informar fecha estimada de entrega." }

          ─── dentro de order_specialist ───
          paso 4.1 → llamada al modelo del especialista
          paso 4.2 → tool: lookup_order (4521)
                     resultado: { "status": "in_transit",
                                  "shipped_at": "2026-07-21",
                                  "eta": "2026-07-23" }
          paso 4.3 → llamada al modelo del especialista
          ───────────────────────────────────

          output: { "status": "resolved",
                    "summary": "Pedido 4521 salió el 21/07, entrega
                                estimada 22-23/07.",
                    "needs_human": false }

paso 5  → llamada al modelo del orquestador
          decide: los dos temas están cubiertos, compongo y cierro

Qué esperar. Mira los números de esa traza, porque son la lección 7 anticipada: el orquestador hizo tres llamadas al modelo (pasos 1, 3 y 5), el especialista de facturación hizo dos (2.1 y 2.5), y el de pedidos hizo dos (4.1 y 4.3). Siete llamadas al modelo y cuatro llamadas a tools reales, para responder un mensaje. Un agente monolítico habría hecho quizá tres llamadas al modelo y las mismas cuatro a tools. Estás pagando algo más del doble en llamadas al modelo a cambio de precisión y de un radio de daño acotado. Ese es el trato del patrón, y hay que hacerlo con los ojos abiertos.

Mira también la estructura de los pasos 2 y 4: dentro de cada uno hay un bucle completo. El especialista de facturación llamó tres tools en secuencia, y la tercera —abrir la disputa— dependía del resultado de las dos primeras. Nadie programó esa secuencia. Es el bucle agéntico del especialista funcionando dentro del bucle agéntico del orquestador. Eso es lo que ningún Switch puede producir, y es exactamente lo que vas a cablear en la lección 4.

Y mira el campo status en las dos salidas. Esa palabra —"resolved"— es lo que le permite al orquestador decidir en el paso 5 que el caso está cerrado. Si hubiera dicho "needs_more_info", el paso 5 habría sido otra delegación o una pregunta al cliente. Ese campo es el contrato de salida, y la lección 5 lo formaliza.

Tres formas de repartir trabajo, y cuál es cuál

"Multi-agente" no significa una sola cosa. Hay al menos tres formas de repartir trabajo entre varias piezas de IA, se confunden con facilidad, y elegir la equivocada produce sistemas que funcionan a medias. Vale la pena poder nombrarlas.

Forma 1 — La cadena fija (pipeline)

Varias piezas en secuencia, donde la salida de una es la entrada de la siguiente, y el orden lo decidiste tú de antemano.

Mensaje ─► extraer datos ─► clasificar ─► redactar respuesta ─► enviar

Cuándo aplica. Cuando el orden de los pasos es siempre el mismo y no depende del caso. Procesar facturas entrantes: siempre hay que extraer los campos, siempre hay que validarlos, siempre hay que registrarlos. No hay nada que decidir sobre el camino.

Cuándo no. En cuanto el caso determina el camino. Y ojo con esto, porque es la trampa más común: una cadena fija normalmente ni siquiera necesita agentes. Si el orden está decidido y cada paso es una transformación, lo que necesitas son nodos de IA en cadena —la IA procedural de la Guía 6— o un sub-workflow determinista, que cuestan menos y son mucho más predecibles.

Forma 2 — El enrutador de un salto (router)

Una pieza clasifica y manda el caso a exactamente un destino. El caso no vuelve.

Mensaje ─► clasificar ─┬─► destino A (y termina ahí)
                       ├─► destino B (y termina ahí)
                       └─► destino C (y termina ahí)

Cuándo aplica. Cuando cada caso pertenece a exactamente un dominio, no hay nada que componer al final, y el destino puede cerrar el caso por su cuenta. El ejemplo típico no es un chat: es un sistema de tickets entrantes que se reparten a colas distintas. Cada ticket va a una cola y ahí se acaba el trabajo del enrutador.

Cuándo no. Cuando un mismo mensaje puede tocar dos dominios, o cuando hace falta una respuesta única al final, o cuando el destino puede descubrir a mitad de camino que el caso no era suyo. Los tres casos son la norma en atención al cliente.

Una nota importante para no confundirse: un enrutador también se puede implementar de forma nativa, con los especialistas como tools. La diferencia con el patrón siguiente no es cómo está cableado, es la política: en un enrutador el orquestador delega una vez y reenvía lo que recibió; en orquestador-trabajador puede delegar varias veces, evaluar los resultados y componer. El Switch de la lección 1 es una implementación mala de un enrutador —fija y sin retorno—, pero el enrutador en sí es un patrón legítimo.

Forma 3 — Orquestador-trabajador

Una pieza coordina, decide dinámicamente a quién llamar —cero, una o varias veces—, recibe cada resultado, y compone la respuesta final.

Mensaje ─► orquestador ⇄ trabajador A
                       ⇄ trabajador B      ─► respuesta única
                       ⇄ trabajador C

Las flechas de doble punta son lo que lo distingue: cada llamada vuelve.

Cuándo aplica. Cuando el número y el orden de las delegaciones dependen del caso, cuando hace falta componer una respuesta única, o cuando un resultado puede cambiar la decisión siguiente. Atención al cliente por chat es el caso de libro.

Cuándo no. Cuando el trabajo es determinista (usa una cadena o un sub-workflow), cuando el volumen es tan alto que el costo por conversación manda sobre la precisión, o cuando hay un solo dominio.

La tabla de decisión

Léela de arriba abajo con tu caso en la mano y la respuesta aparece sola. Si contestaste "no" a las primeras cuatro, no necesitas este módulo para ese caso — necesitas la Guía 6.

Cuándo el patrón no aplica

Tres situaciones donde orquestador-trabajador es la respuesta equivocada, aunque tengas varias responsabilidades:

Cuando las responsabilidades no se cruzan nunca. Si TuTienda tuviera un agente de atención al cliente y un agente interno que le arma reportes al equipo de finanzas, esos dos no forman un equipo: son dos sistemas distintos que casualmente viven en la misma instancia de n8n. Poner un orquestador encima de ellos agrega una llamada al modelo para elegir entre dos cosas que nunca aparecen en el mismo mensaje. Dos workflows separados, cada uno con su propio trigger, es más simple y más barato.

Cuando el "orquestador" no tiene nada que decidir. Si el canal de entrada ya te dice de qué se trata —un formulario web con un campo "motivo: facturación / pedidos / ventas" que el cliente eligió— entonces el enrutamiento ya ocurrió, y lo hizo el cliente. Meter un agente a re-decidir algo que ya está decidido es pagar una llamada al modelo por nada. Ahí un Switch sobre el campo del formulario es lo correcto — y sí, este es el caso donde Switch es la respuesta buena, porque el dato es estructurado y la decisión es determinista.

Cuando hay una restricción dura de latencia. Un agente de voz que atiende una llamada telefónica tiene un presupuesto de tiempo muy corto antes de que el silencio se vuelva incómodo. Cada delegación agrega una ronda completa al modelo, en serie. Si tu presupuesto es de dos segundos, probablemente solo te alcance para un agente con buenas tools. El Módulo 6, cuando llegues a agentes de voz, retoma esta tensión.

Errores comunes

Darle memoria a los trabajadores "para que tengan contexto" (conceptual). Qué pasa: alguien conecta un nodo de memoria al puerto ai_memory de cada especialista, con el mismo session ID que el orquestador. El sistema empieza a comportarse de forma extraña: el especialista de facturación responde cosas sobre un pedido, o repite información que ya se le dio al cliente, o contradice al orquestador. Por qué pasa: parece un beneficio gratis, y la palabra "memoria" invita a pensar que más siempre es mejor. Cómo detectarlo: revisa cuántos turnos tiene la memoria del especialista comparada con la del orquestador; si el especialista se llamó dos veces en una conversación de diez turnos, su historia tiene agujeros que no tiene forma de saber que existen. Cómo corregirlo: quita la memoria de los trabajadores y pásales el contexto que necesitan dentro del encargo — si el número de pedido se dijo tres turnos atrás, es responsabilidad del orquestador incluirlo, y ese es justamente el trabajo por el que existe.

Escribir el prompt del trabajador como si hablara con el cliente (conceptual). Qué pasa: el especialista devuelve "¡Hola! Con gusto reviso eso por ti. Ya abrí tu disputa, ¿hay algo más en lo que pueda ayudarte?", y el orquestador tiene que decidir qué hacer con ese texto: si lo reenvía tal cual, el cliente recibe dos saludos cuando hubo dos delegaciones; si lo reescribe, el sistema pagó tokens por generar texto de cortesía que se tira. Por qué pasa: todos los ejemplos de agentes que uno ve son agentes que hablan con personas, y el reflejo es escribir todos los prompts así. Cómo detectarlo: lee la salida cruda de un especialista en el log; si tiene saludo, despedida o una pregunta dirigida al cliente, está escrito para el destinatario equivocado. Cómo corregirlo: el prompt del trabajador debe pedir explícitamente un resultado, no un mensaje — "devuelve qué encontraste, qué acción tomaste y si el caso quedó cerrado" — y la lección 5 lo lleva un paso más allá con una salida estructurada.

Conectarle tools de acción al orquestador "porque son casos simples" (práctico). Qué pasa: el triage_agent termina con create_ticket conectada directamente, con el argumento de que crear un ticket es trivial y no amerita delegar. Seis semanas después tiene también send_email y lookup_order, porque cada una parecía trivial en su momento, y el orquestador volvió a ser el monolito. Por qué pasa: cada excepción individual es razonable; el problema es acumulativo y no se ve en el momento de tomarlo. Cómo detectarlo: cuenta cuántas tools del orquestador NO son agentes; el número correcto es cero, o a lo sumo una tool de lectura que necesita para poder repartir. Cómo corregirlo: si crear un ticket es una acción legítima del sistema, pertenece al especialista cuyo dominio la usa — y si no pertenece a ninguno, es señal de que falta una responsabilidad en tu corte.

Confundir un enrutador con orquestador-trabajador y quejarse de lo que el enrutador no hace (práctico). Qué pasa: alguien construye un sistema donde el orquestador delega una vez y devuelve tal cual lo que recibió, y después se frustra porque los mensajes con dos temas se responden a medias. Por qué pasa: el cableado de los dos patrones es idéntico —especialistas como tools—; lo que cambia es la política escrita en el system prompt del orquestador. Cómo detectarlo: busca en el prompt del orquestador si dice explícitamente que puede delegar más de una vez y que debe componer una respuesta única; si no lo dice, tienes un enrutador. Cómo corregirlo: agrega esa instrucción explícita —"si el mensaje trae más de un tema, delega cada uno por separado y compón una sola respuesta al final"— y verifica en la traza que aparezcan dos llamadas a tool en el mismo turno.

Ejercicios

Ejercicio 1 — Asigna la propiedad. Para cada uno de estos ocho elementos, di si pertenece al orquestador, a un trabajador, o a ninguno de los dos:

(a) El session ID de la conversación. (b) La regla "los productos de higiene personal no admiten devolución". (c) La credencial de la API de pagos. (d) La decisión de responderle al cliente sin delegar nada. (e) El texto "¿hay algo más en lo que pueda ayudarte?". (f) La tool open_dispute. (g) La decisión de que hace falta una segunda delegación. (h) El cálculo determinista de si una fecha de compra está dentro del plazo.

Ejercicio 2 — Elige el patrón. Para cada uno de estos cuatro sistemas, di cuál de las tres formas corresponde (cadena fija, enrutador, orquestador-trabajador) y por qué:

(a) Un sistema que recibe facturas escaneadas por correo, extrae proveedor, monto y fecha, valida contra el catálogo de proveedores, y registra la factura en una hoja de cálculo. (b) Un chat de atención al cliente donde los mensajes suelen traer más de un tema y hace falta una respuesta única. (c) Un buzón interno donde llegan solicitudes de empleados que hay que mandar a la cola correcta: recursos humanos, sistemas o contabilidad. Cada cola tiene un equipo humano que resuelve. (d) Un asistente de investigación que, dada una pregunta, decide qué fuentes consultar, lee los resultados, decide si hace falta buscar más, y al final escribe un informe.

Ejercicio 3 — Reescribe un prompt de trabajador. Este es el system prompt actual de un especialista. Tiene tres problemas del patrón. Encuéntralos y reescríbelo.

# System Message de order_specialist (versión con problemas)
#
#   Eres el agente de atención de TuTienda. Saluda al cliente con
#   calidez y tutéalo. Resuelves consultas de pedidos y devoluciones.
#   Si el cliente además pregunta por un cobro, usa lookup_charge para
#   ayudarlo. Recuerda lo que el cliente te dijo en mensajes anteriores.
#   Termina siempre preguntando si necesita algo más.

# System Message de order_specialist (corregido)
#
#   Eres el especialista en pedidos y devoluciones de TuTienda.
#   Resuelves estado de envíos, retrasos y solicitudes de devolución.
#   No manejas cobros ni facturación: si el encargo que recibes es de
#   ese dominio, no uses ninguna tool y repórtalo como fuera de tu
#   alcance.
#
#   Trabajas con el encargo que recibes; no tienes historial de la
#   conversación. Si te falta un dato para resolver, no lo inventes:
#   repórtalo como faltante.
#
#   Plazos de devolución: 30 días general, 14 días para la categoría
#   electronics, sin devolución para higiene personal.
#
#   Devuelve siempre: 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,
#   no el cliente.

Resumen y siguiente paso

Ya tienes la arquitectura. El orquestador posee la conversación, la memoria de sesión, la decisión de a quién delegar y la decisión de que el caso está cerrado — y no posee conocimiento de dominio ni tools de acción. Cada trabajador posee su dominio completo, sus tools y su propio bucle agéntico — y no habla con el cliente, no decide si el caso terminó, y no delega en otros trabajadores. La memoria vive en un solo lugar, el orquestador, y lo que el trabajador necesita viaja dentro del encargo. Y viste que orquestador-trabajador es una de tres formas de repartir trabajo, con una tabla de cuatro preguntas para saber cuál corresponde.

Antes de avanzar deberías poder: decir quién es dueño del session ID y por qué; explicar por qué un trabajador no debería tener memoria propia, con al menos dos de los tres problemas que eso causa; distinguir un enrutador de un orquestador-trabajador aunque estén cableados igual; y detectar en el prompt de un trabajador las frases que revelan que fue escrito para el destinatario equivocado.

Lo que no tienes todavía es el cable. Todo lo de esta lección es diseño: un dibujo con flechas y una tabla de propiedad. La pregunta concreta —cómo se conecta, físicamente, un nodo AI Agent al puerto ai_tool de otro nodo AI Agent en n8n 2.0, qué parámetros tiene esa conexión y cómo se ve en la traza de ejecución— es el tema completo de la lección 4. Es la lección central de este módulo.

Recursos

• AI Agent node — n8n Docs — referencia del nodo raíz y de sus puertos ai_languageModel, ai_memory y ai_tool; la base física del reparto que diseñaste aquí.
• Memory sub-nodes — n8n Docs — el catálogo de nodos de memoria y su session ID; útil para confirmar dónde conectar la memoria del orquestador.
• Building Effective AI Agents — Anthropic — el artículo que define orquestador-trabajador, enrutamiento y encadenamiento como patrones distintos, con el criterio de cuándo usar cada uno.
• What agents do — n8n Docs — la distinción entre un agente (decide) y una chain (secuencia fija), que es la misma frontera entre la Forma 1 y la Forma 3 de esta lección.
• Switch node — n8n Docs — para el caso legítimo que se mencionó aquí: enrutar sobre un campo estructurado que el cliente ya eligió, donde la decisión es determinista y no hace falta un modelo.