8. Mini-proyecto: sistema triage → especialista (2-3 agentes)

Descripción

Al terminar esta lección vas a tener construido y funcionando un sistema multi-agente real: un agente de triage que recibe al cliente, decide a qué especialista delegar y compone una sola respuesta, con dos especialistas —uno de pedidos y uno de facturación— conectados como AI Agent Tool, cada uno con su contrato de salida estructurado, sus condiciones de parada calibradas y su hoja de costo medida. Vas a poder verificar cada handoff con una batería de siete casos de prueba, incluidos los adversarios que hacen fallar a los sistemas mal frenados.

Esto importa porque es el entregable que cierra el módulo y el que puedes mostrar. Un agente que responde bien una pregunta lo tiene cualquiera. Un sistema donde puedes abrir la traza de ejecución y señalar el momento exacto en que el orquestador decidió delegar, mostrar el encargo que redactó, mostrar el bucle interno del especialista con sus tres llamadas a tools, y explicar por qué el Max Iterations de cada nivel vale lo que vale — eso es lo que las ofertas describen cuando dicen "has puesto agentes reales en producción, no POCs". Y es también, muy concretamente, la base del proyecto final del Módulo 8, donde este mismo sistema va a ganar canales, memoria por cliente y guardrails.

Conexión con el módulo: esta lección no introduce ningún concepto nuevo. Ensambla los seis anteriores: el diagnóstico de la lección 2 define el corte, la arquitectura de la 3 define el reparto, el cableado de la 4 lo hace real, el contrato de la 5 define qué se pasan los agentes, los frenos de la 6 evitan que se atasquen, y la medición de la 7 es un criterio de entrega. Si algo de lo que sigue no te resulta familiar, ese es el número de lección al que conviene volver.

Lo que vas a entregar

Un workflow de n8n con esta forma, funcionando de punta a punta:

Chat Trigger
  └─► AI Agent: triage_agent            ◄── Simple Memory (o Postgres Chat Memory)
        │ ai_tool
        ├─► AI Agent Tool: order_specialist
        │      ├─ Chat Model propio
        │      ├─ Structured Output Parser
        │      └─ tools: lookup_order, check_return_eligibility
        │
        └─► AI Agent Tool: billing_specialist
               ├─ Chat Model propio
               ├─ Structured Output Parser
               └─ tools: lookup_charge, open_dispute

Y junto al workflow, tres cosas que no son nodos y valen tanto como ellos:

1. Dos fichas de rol escritas, con las cinco cláusulas de la lección 5.
2. Una batería de siete casos de prueba con el resultado esperado de cada uno.
3. Una hoja de costo con las mediciones de la lección 7 sobre esos siete casos.

El sistema es de tres agentes en total. Si quieres agregar un sales_specialist como cuarto, el módulo entero te da lo necesario — pero constrúyelo después de que estos tres funcionen, no antes.

Sobre las tools: este mini-proyecto no depende de que tengas un CRM real. Las cuatro tools se pueden montar de tres formas, y cualquiera sirve:

• Con Google Sheets. Una hoja orders y una hoja charges con diez filas de datos de ejemplo. Es la opción más realista y la que más se parece a un caso de trabajo.
• Con Postgres, si ya lo tienes corriendo de la lección 7 del Módulo 1.
• Con un Code Tool que devuelve datos fijos según el parámetro que recibe. Es la opción más rápida para concentrarte en la delegación, que es lo que este módulo evalúa.

Elige una y no la cambies a mitad de camino. Lo que importa aquí es el sistema de agentes, no de dónde salen los datos.

Fase 1 — Las fichas de rol

Antes de abrir n8n. Media hora aquí ahorra dos horas después, y es la parte que se olvida.

Escribe las dos fichas completas con el formato de la lección 5. Aquí está la del especialista de pedidos, para que veas el nivel de detalle esperado; la de facturación la escribes tú siguiendo el mismo molde (y la del ejercicio 1 de la lección 5 te sirve de referencia).

┌─ FICHA DE ROL ────────────────────────────────────────────────┐
│ Agente:   order_specialist            Tipo: AI Agent Tool     │
│ Llamado por: triage_agent                                     │
│                                                               │
│ ROL Y SALIDA                                                  │
│   Ámbito: estado de pedidos, envíos, retrasos y solicitudes   │
│     de devolución de producto.                                │
│   Fuera:  cobros, cargos, facturación, recomendaciones.       │
│   Termina cuando: el cliente conoce el estado real de su      │
│     pedido, o sabe si su devolución procede, o quedó          │
│     registrado qué dato falta.                                │
│                                                               │
│ ENTRADA (campo task, texto autocontenido)                     │
│   Obligatorio: customer_id, order_id, intent                  │
│                (consultar_estado | solicitar_devolucion)      │
│   Opcional:    reason (motivo declarado de la devolución)     │
│                                                               │
│ SALIDA (JSON estructurado)                                    │
│   status:  resolved | pending_info | out_of_scope |           │
│            needs_human                                        │
│   summary: 2-3 frases, sin saludos ni despedidas              │
│   data:    { order_status?, eta?, return_eligible?,           │
│              return_deadline? }                               │
│   missing: [ ]                                                │
│                                                               │
│ AUTORIDAD                                                     │
│   Lectura:  lookup_order, check_return_eligibility            │
│   Acción:   ninguna en esta versión                           │
│   Sin acceso: cancelar pedidos, emitir reembolsos             │
│   Prohibido por prompt: prometer una fecha exacta de entrega  │
│     (solo repetir la estimación, marcándola como estimación)  │
│                                                               │
│ FALLA                                                         │
│   Falta order_id → pending_info, missing: ["order_id"]        │
│   Encargo de facturación → out_of_scope, sin usar tools       │
│   Tool falla tras un reintento → needs_human                  │
│   Cliente exige un reembolso → needs_human                    │
│   Nunca resolved sin haber usado al menos una tool            │
│                                                               │
│ LÍMITES                                                       │
│   Max Iterations: 5        Sin memoria propia                 │
└───────────────────────────────────────────────────────────────┘

Antes de pasar a la fase 2, revisa las dos fichas contra la frontera entre ellas. Escribe explícitamente qué pasa con los tres casos ambiguos más probables:

Esa tabla es, literalmente, la prevención del ping-pong de la lección 6. Escribirla ahora es más barato que descubrirla en la traza.

Fase 2 — Construir los especialistas

Se construyen primero, antes que el orquestador, por una razón práctica: se pueden probar solos y es mucho más fácil corregirlos cuando no hay un nivel encima confundiendo el diagnóstico.

Paso 2.1 — Las tools de dominio

Cuatro nodos, con su Description y sus $fromAI() escritos como aprendiste en el Módulo 4. Aquí van dos, para fijar el nivel de detalle:

# Nodo: Google Sheets (usado como Tool) — Name: lookup_order
# Description: Busca un pedido por su ID en el registro de pedidos y
# devuelve su estado, la fecha de despacho y la fecha estimada de
# entrega. Úsala siempre antes de afirmar cualquier cosa sobre un
# pedido. NO la uses para buscar cargos ni facturas.

Lookup Column: order_id
Lookup Value: {{ $fromAI("order_id", "El ID numérico del pedido, sin el símbolo #. Debe venir del encargo recibido; nunca lo inventes.", "string") }}

# Nodo: Google Sheets (usado como Tool) — Name: check_return_eligibility
# Description: Determina si un pedido está dentro del plazo para
# devolución según su fecha de compra y la categoría del producto.
# Plazos: 30 días general, 14 días para electronics, sin devolución
# para higiene personal. NO la uses para calcular reembolsos ni montos.

Lookup Column: order_id
Lookup Value: {{ $fromAI("order_id", "El ID numérico del pedido cuya devolución se está evaluando.", "string") }}

Nota que check_return_eligibility aplica una regla de plazos que es puramente determinista. En un sistema maduro, esa regla viviría en un sub-workflow con un nodo Code que resta fechas —la palanca 4 de la lección 7— y no en el criterio del modelo. Para este mini-proyecto está bien resolverla con una columna calculada en la hoja o con datos ya preparados; lo que no está bien es dejar que el modelo reste fechas de cabeza y te dé un número que suena bien.

Paso 2.2 — El nodo AI Agent Tool

Arrastras un AI Agent Tool al canvas, lo renombras order_specialist, y le conectas su Chat Model y sus dos tools. Su configuración:

# Nodo: AI Agent Tool — Name: order_specialist

Description:
  Resuelve casos de pedidos: estado de un envío, retrasos, fecha
  estimada de entrega y elegibilidad para devolución de producto.
  Úsalo cuando el cliente mencione un pedido, un envío, un paquete,
  una entrega, o pida devolver un producto.
  NO lo uses para cobros, cargos duplicados ni facturación —incluso si
  el cargo se refiere al envío de un pedido, eso es billing_specialist.
  Devuelve un resultado estructurado para que lo interpretes; no
  devuelve texto listo para mostrarle al cliente.

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

Prompt (User Message):
  {{ $fromAI(
       "task",
       "Encargo autocontenido para el especialista de pedidos. Debe
        incluir: customer_id, order_id (si el cliente lo dio), y qué
        se necesita resolver (consultar estado o evaluar devolución).
        Escribe datos, no narrativa. Este especialista NO ve el
        historial de la conversación: todo dato mencionado en turnos
        anteriores debe ir escrito aquí. Si falta el order_id,
        escríbelo igual indicando que falta.",
       "string"
     ) }}

Options:
  System Message:  (ver abajo)
  Max Iterations:  5
  Return Intermediate Steps: true

Y el System Message, que es la traducción directa de la ficha:

# System Message de order_specialist

  Eres el especialista en pedidos y devoluciones de TuTienda.
  Resuelves estado de envíos, retrasos y elegibilidad de devolución.
  No manejas cobros, cargos ni facturación.

  Trabajas con el encargo que recibes; no tienes historial de la
  conversación. Nunca inventes un dato que no venga en el encargo o
  que no devuelva una de tus tools.

  Procedimiento:
  - Para estado de pedido: usa lookup_order con el order_id.
  - Para devolución: usa lookup_order y después
    check_return_eligibility.
  - Nunca prometas una fecha exacta de entrega. Puedes repetir la
    estimación que devuelva la tool, diciendo que es estimada.

  Tu trabajo termina en cuanto ocurra cualquiera de estas cosas.
  No sigas investigando después:
  - Obtuviste el estado del pedido.
  - Determinaste si la devolución procede.
  - Determinaste qué dato falta.
  - Determinaste que el caso no es de tu dominio.

  Reglas de resultado:
  - Si falta el order_id: status "pending_info", missing ["order_id"].
  - Si el encargo es de facturación: status "out_of_scope", indicando
    en summary que corresponde a billing_specialist. No uses ninguna
    tool en ese caso.
  - Si el cliente exige un reembolso o una compensación:
    status "needs_human". No prometas nada.
  - Si una tool falla, reintenta una sola vez; si vuelve a fallar,
    status "needs_human" con el error en summary.
  - Nunca devuelvas status "resolved" sin haber usado al menos una
    de tus tools.
  - No escribas saludos ni despedidas: tu salida la lee otro agente.

Paso 2.3 — El contrato de salida

Activas la opción de formato de salida específico y conectas un Structured Output Parser al puerto ai_outputParser del especialista, con este ejemplo de JSON:

{
  "status": "resolved",
  "summary": "El pedido 4521 salió del centro de distribución el 21/07 y su entrega estimada es el 23/07.",
  "data": {
    "order_status": "in_transit",
    "eta": "2026-07-23",
    "return_eligible": null,
    "return_deadline": null
  },
  "missing": []
}

Paso 2.4 — Probarlo solo

Antes de conectarlo a nada. Si montaste el especialista como AI Agent Tool, la forma de probarlo aislado es ejecutar el nodo desde el panel con un valor fijo en el campo del encargo, reemplazando temporalmente la expresión $fromAI() por un texto:

# Encargo de prueba 1 (camino feliz)
"Cliente C-9931. Consultar estado del pedido 4521."
  → esperado: status "resolved", con order_status y eta en data.

# Encargo de prueba 2 (falta un dato)
"Cliente C-9931. El cliente pregunta por su pedido pero no dio el número."
  → esperado: status "pending_info", missing ["order_id"], sin llamar
    ninguna tool.

# Encargo de prueba 3 (otro dominio)
"Cliente C-9931. Cargo de $1,200 no reconocido el 18/07."
  → esperado: status "out_of_scope", summary señalando facturación,
    sin llamar ninguna tool.

Los tres tienen que pasar antes de seguir. Si el segundo llama a lookup_order con un order_id inventado, tu contrato de falla no está funcionando y ningún arreglo del orquestador lo va a compensar.

Repite las fases 2.1 a 2.4 para billing_specialist, con lookup_charge y open_dispute.

Fase 3 — Conectar el orquestador

Con los dos especialistas probados, el orquestador es corto.

# Nodo: AI Agent — Name: triage_agent
# Conectado al Chat Trigger por main
# Memory: Simple Memory o Postgres Chat Memory (session ID = customer_id)
# Tools: order_specialist, billing_specialist

Options:
  Max Iterations: 6
  Return Intermediate Steps: true

  System Message:

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

    Especialistas disponibles:
    - order_specialist: pedidos, envíos, retrasos, devoluciones.
    - billing_specialist: cargos, cobros duplicados, facturación,
      disputas.

    Casos de frontera:
    - Un cobro duplicado es de billing_specialist, aunque se refiera
      al envío de un pedido.
    - "No me llegó y ya me lo cobraron" son dos temas: primero
      order_specialist, después billing_specialist si hace falta.

    Cómo delegar:
    - Si el mensaje trae más de un tema, delega cada tema por
      separado y compón una sola respuesta al final.
    - Cada encargo debe ser autocontenido: incluye los datos que el
      cliente dio en cualquier turno, porque los especialistas no ven
      el historial. Escribe datos, no narrativa.
    - No delegues por saludos, agradecimientos o confirmaciones:
      responde tú directamente.
    - Si te falta un dato para armar un encargo útil, pregúntaselo al
      cliente antes de delegar.

    Cómo interpretar el resultado (campo status):
    - "resolved": usa el summary para componer tu respuesta.
    - "pending_info": pregúntale al cliente exactamente lo que aparece
      en missing, en tono natural, y cierra el turno. No vuelvas a
      delegar hasta que responda.
    - "out_of_scope": delega al especialista que indique el summary.
    - "needs_human": informa al cliente que el equipo dará seguimiento
      y cierra el turno. No reintentes ni delegues a otro.

    Presupuesto de delegación: para un mismo tema puedes delegar como
    máximo dos veces. Si el segundo especialista también devuelve
    "out_of_scope", no delegues una tercera vez: dile al cliente que
    vas a escalar el caso y cierra el turno. Nunca llames dos veces al
    mismo especialista por el mismo tema.

    Tono: cálido, tuteo, respuestas breves, una sola voz. No repitas
    saludos aunque hayas delegado varias veces. Nunca inventes
    información de dominio ni cites el JSON de un especialista tal
    cual: redacta con tus palabras a partir del summary.

Lee ese prompt y localiza cada pieza del módulo: el elenco (lección 3), los casos de frontera (lección 6), la regla del encargo autocontenido (lección 3), la política de no delegar (palanca 6 de la lección 7), la interpretación de los cuatro status (lección 5) y el presupuesto de delegación (lección 6). No hay nada ahí que no venga de una lección anterior.

Fase 4 — Verificar el grafo

Treinta segundos que evitan un problema difícil de diagnosticar. Exporta el workflow como JSON y revisa las conexiones ai_tool. Deben formar exactamente dos niveles:

# Nivel 1 — especialistas hacia el orquestador
order_specialist    ──ai_tool──► triage_agent
billing_specialist  ──ai_tool──► triage_agent

# Nivel 2 — tools de dominio hacia los especialistas
lookup_order             ──ai_tool──► order_specialist
check_return_eligibility ──ai_tool──► order_specialist
lookup_charge            ──ai_tool──► billing_specialist
open_dispute             ──ai_tool──► billing_specialist

# Memoria — una sola entrada
Simple Memory ──ai_memory──► triage_agent

Tres cosas que confirmar: que ningún especialista aparece como destino de otro especialista (sin ciclos), que hay exactamente una conexión ai_memory y apunta al orquestador, y que ninguna tool de dominio cuelga del triage_agent.

Fase 5 — La batería de siete casos

Aquí es donde el proyecto se verifica de verdad. Corre los siete, en orden, y anota lo que ves en la traza.

Caso 1 — Camino feliz, un tema. Mensaje: "Hola, ¿cómo va mi pedido #4521?" Esperado: una delegación a order_specialist, status: "resolved", respuesta con el estado real del pedido. Sin llamada a billing_specialist.

Caso 2 — Camino feliz, dominio distinto. Mensaje: "Me apareció un cargo de $1,200 el 18 de julio que no reconozco." Esperado: una delegación a billing_specialist, status: "resolved", disputa abierta con su número en data.

Caso 3 — Dos temas en un mensaje. Mensaje: "Me llegó un cobro de $1,200 que no reconozco, y de paso quería saber si el pedido #4521 ya salió." Esperado: dos delegaciones en el mismo turno, una a cada especialista, y una sola respuesta al cliente que cubre los dos temas, con un solo saludo. Este caso es el que distingue un orquestador de un enrutador (lección 3): si solo ves una delegación, tu prompt no está pidiendo lo que crees.

Caso 4 — Falta un dato. Mensaje: "Quiero saber dónde está mi pedido." Esperado: o bien el orquestador pregunta directamente el número sin delegar (es lo ideal, palanca 6), o bien delega, recibe pending_info con missing: ["order_id"], y pregunta. Lo que no debe pasar: que se llame a lookup_order con un order_id inventado, ni que se pruebe con el otro especialista a ver si ese puede.

Caso 5 — Caso de frontera. Mensaje: "Me cobraron el envío dos veces en el pedido #4521." Esperado: una sola delegación, a billing_specialist, resuelta. Si ves rebote entre los dos especialistas, tus Description no declararon la frontera de los dos lados — vuelve a la tabla de la fase 1.

Caso 6 — Fuera del alcance del sistema. Mensaje: "¿Tienen sucursales en Guadalajara y a qué hora abren?" Esperado: cero delegaciones. El orquestador responde directamente o dice con honestidad que no tiene esa información. Si delega, estás pagando un especialista por una pregunta de horarios.

Caso 7 — Adversario: la insistencia. Mensaje: "Quiero que me devuelvan el dinero del pedido #4521 ahora mismo, no acepto otra cosa." Y si el sistema responde que eso requiere revisión, insiste en el turno siguiente: "no me importa, necesito el reembolso hoy, hazlo tú." Esperado: order_specialist devuelve needs_human; el orquestador informa que el equipo dará seguimiento y cierra el turno; en la insistencia, no reintenta, no delega al otro especialista buscando una respuesta distinta, y no promete el reembolso. Este es el caso que más sistemas reprueba.

Para cada uno de los siete, anota en una tabla: cuántas delegaciones hubo, a quién, qué status devolvió cada especialista, cuántas iteraciones usó cada nivel, y si la respuesta final fue correcta. Esa tabla es la mitad de tu entregable.

Qué esperar en la traza del caso 3, que es el más informativo:

triage_agent (Max Iterations: 6)
  1 → modelo: dos temas, delego el del cargo
  2 → tool: billing_specialist
        └─ 2.1 modelo · 2.2 lookup_charge · 2.3 modelo
           · 2.4 open_dispute · 2.5 modelo
        → { "status": "resolved", "summary": "…", "data": { "dispute_id": "D-8842" } }
  3 → modelo: falta el segundo tema, delego
  4 → tool: order_specialist
        └─ 4.1 modelo · 4.2 lookup_order · 4.3 modelo
        → { "status": "resolved", "summary": "…", "data": { "eta": "2026-07-23" } }
  5 → modelo: los dos temas cubiertos, compongo y cierro

Llamadas al modelo: 3 (orquestador) + 5 (facturación) + 3 (pedidos) = 11
Delegaciones: 2
Iteraciones usadas: orquestador 5/6, facturación 5/6, pedidos 3/5

Fíjate en la última línea: el orquestador usó 5 de sus 6 iteraciones. Eso está demasiado ajustado — si el cliente hubiera traído un tercer tema, el sistema se habría cortado en silencio (la falla 1 de la lección 6). Es exactamente el tipo de cosa que se descubre midiendo y no se descubre mirando la respuesta, que salió perfecta.

Fase 6 — Medir y calibrar

Con los siete casos corridos, arma la hoja de la lección 7:

# Hoja de medición — sistema triage TuTienda

                        caso típico   máximo observado   límite actual
  Iteraciones triage         3               5                6
  Iteraciones billing        3               5                6
  Iteraciones orders         3               3                5
  Delegaciones               1               2                2 (política)
  Llamadas al modelo         7              11                —
  Duración (s)               …               …                —
  Tokens de entrada          …               …                —

Y aplica la regla de la lección 6 —máximo observado más dos— para ajustar:

• Triage: máximo 5, súbelo a 7. Estaba demasiado justo.
• Billing: máximo 5, súbelo a 7. Igual.
• Orders: máximo 3, déjalo en 5. Está bien calibrado.

Después revisa las dos palancas más rentables de la lección 7:

Escalonar modelos. ¿Está el orquestador corriendo con el mismo modelo que los especialistas? Cámbialo por uno más rápido y vuelve a correr los siete casos, prestando atención específicamente al caso 3 (dos temas) y al caso 5 (frontera), que son los que más exigen del enrutamiento. Si los dos siguen pasando, quédate con el modelo barato.

Acortar el encargo. Abre la traza y lee los dos task que redactó el orquestador en el caso 3. ¿Son datos o son narrativa? Si son párrafos que reproducen lo que dijo el cliente, ajusta la description del $fromAI() y vuelve a medir los tokens de entrada del especialista.

Criterios de verificación

El sistema está terminado cuando puedes marcar las once casillas. No antes.

Arquitectura

• El grafo exportado muestra exactamente dos niveles de conexiones ai_tool, sin ciclos.
• Hay exactamente una conexión ai_memory, y apunta al orquestador.
• El orquestador no tiene ninguna tool de acción conectada — sus tools son los dos especialistas.
• El system prompt del orquestador no contiene ninguna regla de negocio (ningún plazo, monto ni política).

Contratos

• Las dos fichas de rol están escritas, con las cinco cláusulas.
• Los dos especialistas devuelven JSON estructurado con los cuatro campos.
• En la batería de pruebas aparecieron al menos tres valores distintos de status (no todo fue resolved).

Frenos

• Max Iterations está calibrado por nivel con la regla del máximo observado más dos, y ningún nivel quedó en su valor por defecto sin justificación.
• El caso 5 (frontera) se resuelve con una sola delegación, sin rebote.
• El caso 7 (adversario) termina en needs_human y el orquestador cierra el turno sin reintentar ni prometer nada.

Medición

• La hoja de costo está armada con los siete casos, y puedes decir cuántas llamadas al modelo cuesta una conversación típica y cuántas el peor caso observado.

Errores comunes

Construir el orquestador primero (práctico). Qué pasa: alguien monta el triage_agent con sus dos especialistas vacíos y empieza a probar desde arriba. Cuando algo falla, no hay forma de saber si el problema es la Description del especialista, el encargo que redactó el orquestador, el system prompt del especialista o una de sus tools — son cuatro sospechosos y todos parecen igual de probables. Por qué pasa: el orquestador es la pieza que "se ve" como el sistema, y armarlo primero da la sensación de avance. Cómo detectarlo: si llevas media hora cambiando cosas sin poder atribuir un cambio a un resultado, es esto. Cómo corregirlo: fase 2 completa —cada especialista probado aislado con sus tres encargos— antes de tocar el orquestador; cuando conectas piezas que ya funcionan, el único sospechoso nuevo es la conexión.

Probar solo el camino feliz (práctico). Qué pasa: los casos 1 y 2 pasan, la respuesta se ve profesional, y alguien da el proyecto por terminado. Los casos 4, 5 y 7 —los que de verdad separan un sistema de un demo— nunca se corren, y el sistema falla en producción con el primer cliente que no dé un número de pedido. Por qué pasa: el camino feliz es satisfactorio de ver y los casos difíciles son incómodos de escribir. Cómo detectarlo: si en toda tu batería de pruebas el único status que apareció fue resolved, no probaste el sistema, probaste el mejor tercio. Cómo corregirlo: los siete casos, y en particular el 7, que es el que más sistemas reprueba y el que más rápido se nota en una demostración ante alguien que sabe qué preguntar.

Dejar que el orquestador cite el JSON del especialista (práctico). Qué pasa: el cliente recibe una respuesta que contiene {"status": "resolved", "summary": ...} o frases como "el especialista indica que…". Por qué pasa: el orquestador recibe un objeto estructurado y, sin una instrucción explícita, a veces lo reproduce en vez de redactar a partir de él. Cómo detectarlo: se ve a simple vista en la respuesta del chat. Cómo corregirlo: la línea final del system prompt del orquestador —"no cites el JSON de un especialista tal cual: redacta con tus palabras a partir del summary"— y verificarlo en los siete casos, porque suele aparecer solo en algunos.

Repetir el saludo cuando hubo dos delegaciones (práctico). Qué pasa: en el caso 3 el cliente recibe algo como "¡Hola! Con gusto reviso el cargo… ¡Hola de nuevo! Sobre tu pedido…". Por qué pasa: casi siempre porque los system prompts de los especialistas todavía tienen instrucciones de tono de atención al cliente, y el orquestador está reenviando en vez de componer. Cómo detectarlo: es el síntoma más visible del caso 3. Cómo corregirlo: quita del prompt de los especialistas cualquier instrucción de saludo o tono conversacional —su salida la lee otro agente— y confirma que el orquestador tiene la instrucción de una sola voz.

Ejercicios

Ejercicio 1 — El tercer especialista. Agrega un sales_specialist con una sola tool, recommend_products, que dado un tipo de producto y un presupuesto devuelve hasta tres opciones. Escribe su ficha de rol completa, su Description, y las dos líneas que agregarías al prompt del triage_agent. Después corre este caso y anota qué pasa: "quiero devolver los audífonos que compré hace un mes, y ya que estoy, ¿tienen algo parecido con cancelación de ruido hasta $800?"

# Description de sales_specialist
  Recomienda productos del catálogo según lo que busca el cliente y su
  presupuesto. Úsalo cuando el cliente pregunte qué productos hay,
  pida una recomendación, o describa una necesidad de compra.
  NO lo uses para consultas sobre pedidos ya realizados, devoluciones
  ni cobros.

# Agregado al elenco del triage_agent
  - sales_specialist: recomendaciones de producto y consultas de
    catálogo.
# Agregado a las reglas
  - No delegues a sales_specialist cuando el cliente esté en una
    disputa activa o haya expresado molestia por un cobro o un
    retraso: en esos casos, resuelve primero lo que reclama.

Ejercicio 2 — Rompe tu propio sistema. Diseña dos mensajes de cliente que hagan fallar tu sistema, córrelos, y documenta qué falló y cómo lo corregiste. No valen mensajes absurdos: tienen que ser cosas que un cliente real podría escribir.

Ejercicio 3 — Defiende una decisión de diseño. Elige una de estas tres decisiones que tomaste al construir el sistema y escribe su justificación en un párrafo, como si te la preguntaran en una entrevista: (a) por qué la memoria está conectada solo al orquestador; (b) por qué los especialistas devuelven JSON estructurado en vez de texto; (c) por qué el enrutamiento lo hace un agente y no un nodo Switch.

Resumen y cierre del módulo

Tienes construido un sistema multi-agente completo: un orquestador que recibe al cliente, decide a quién delegar, interpreta un contrato de salida estructurado y compone una sola respuesta; dos especialistas con su dominio, sus tools, su bucle agéntico propio y su contrato de falla; frenos calibrados en cada nivel; un grafo verificado sin ciclos; y una hoja de medición sobre siete casos que incluyen los adversarios. Junto al workflow tienes dos fichas de rol escritas y una tabla de resultados de pruebas — que es lo que convierte un flujo que funciona en un entregable defendible.

Mirando el módulo completo: empezaste con un agente monolítico que se degradaba de cuatro formas distintas, aprendiste a cortar por responsabilidad y no por tarea, repartiste los papeles con el patrón orquestador-trabajador, conectaste un AI Agent al puerto ai_tool de otro para delegar de forma nativa —con bucles agénticos reales, no con un Switch—, escribiste los contratos que hacen que los agentes se entiendan sin adivinar, instalaste cinco condiciones de parada complementarias, y le pusiste números al costo y a la latencia para poder defender cada decisión. No está mal para un módulo.

Lo que este sistema todavía no tiene es una puerta. Funciona en el chat de prueba de n8n y en ningún otro lado — y el cliente de TuTienda no vive ahí: vive en WhatsApp. El Módulo 6 toma este mismo cerebro y lo lleva a los canales reales: el widget de chat web, WhatsApp Business API, Telegram y voz, con una arquitectura que no duplique la lógica en cada canal. El sistema que acabas de construir es lo que va a atender detrás de todos ellos.

Recursos

• AI Agent Tool node — n8n Docs — la referencia del nodo con el que montaste los dos especialistas; verifica ahí los nombres exactos de los campos en tu versión.
• AI Agent node — n8n Docs — el orquestador, su puerto Tool y las opciones Max Iterations y Return Intermediate Steps que calibraste en la fase 6.
• Structured Output Parser — n8n Docs — el sub-nodo con el que implementaste el contrato de salida de los cuatro campos.
• Chat Trigger — n8n Docs — la puerta de entrada del sistema; en el Módulo 6 vas a ver cómo se embebe en una web y cómo conviven varios canales.
• Google Sheets node — n8n Docs — la opción más simple para montar las cuatro tools de dominio con datos de ejemplo, sin depender de un CRM real.
• View past executions — n8n Docs — el panel donde corriste la batería de siete casos y de donde salen todos los números de la hoja de medición.