Módulo 5: Sistemas multi-agente: agentes que se delegan tareas
2. Por qué un solo agente no alcanza: separar responsabilidades
Descripción
Al terminar esta lección vas a poder diagnosticar, con señales concretas y verificables en el panel de ejecuciones de n8n, cuál de los cuatro modos de degradación está sufriendo un agente monolítico; vas a poder decidir dónde cortar usando una regla explícita —una responsabilidad, un criterio de salida— en vez de cortar por intuición; y vas a poder defender, con el mismo criterio, cuándo NO conviene separar y un solo agente sigue siendo la respuesta correcta.
Esto importa porque la lección anterior te dejó una intuición ("mi agente tiene demasiado encima") y una intuición no se puede discutir en una reunión ni verificar en un log. Si le dices a tu equipo "hay que partir el agente en tres" y te preguntan por qué, "porque tiene muchas tools" no es una respuesta: es una impresión. En cambio, "en las últimas 40 ejecuciones, el agente eligió check_refund_eligibility en 6 casos donde el cliente hablaba de un cargo, no de una devolución, y las dos descripciones se solapan en la frase 'cliente no conforme'" es un diagnóstico. Esta lección te da la forma de llegar a esa segunda frase. Y te da también la disciplina contraria, que es igual de importante: separar tiene un costo real en dinero y en tiempo de respuesta —la lección 7 le pone números—, así que necesitas poder justificar cada corte, no solo desearlo.
Conexión con el módulo: la lección 1 te mostró el contraste entre un agente monolítico y un equipo, y te dio el mapa. Esta lección es el diagnóstico: por qué exactamente se degrada el monolito, y con qué regla se decide el corte. La lección 3 toma el resultado de ese corte —un conjunto de responsabilidades separadas— y le da forma de arquitectura con el patrón orquestador-trabajador. Todavía no vas a conectar ningún agente a otro; eso es la lección 4. Aquí trabajas con papel y con logs.
Un escritorio con demasiados formularios
Vuelve a la persona del mostrador de la lección anterior, pero ahora mira su escritorio en vez de mirarla a ella. Sobre el escritorio hay nueve formularios. Tres son para pedidos, dos para cobros, dos para devoluciones, uno para reclamos y uno para inscribir a alguien al programa de puntos. Todos se ven parecidos: mismo tamaño, mismo membrete, encabezados de dos palabras que dicen cosas como "Solicitud de revisión" y "Solicitud de ajuste".
Ahora imagina que llega un cliente y dice, hablando rápido: "me cobraron algo que no compré". La persona tiene que hacer dos cosas al mismo tiempo: entender el caso, y elegir el formulario. Si los nueve formularios estuvieran claramente separados —tres en una gaveta rotulada PEDIDOS, dos en otra rotulada COBROS— la segunda tarea sería trivial. Pero están los nueve juntos sobre la mesa, y dos de ellos dicen casi lo mismo. La persona va a acertar la mayoría de las veces. Y va a fallar algunas, no por falta de criterio, sino porque le pusiste dos objetos casi idénticos al lado y le pediste distinguirlos a la carrera.
Un agente de IA vive exactamente esa escena en cada turno. La diferencia con la persona es que a él no le llegan los formularios de a poco: todas las descripciones de todas sus tools se le presentan juntas, en el mismo contexto, en cada llamada al modelo. Y junto a ellas va también el system prompt completo, con todas sus reglas. El modelo no lee "la parte relevante" — lee todo y elige. Cuanto más grande y más parecido entre sí es ese conjunto, más fácil es que la elección salga mal.
Eso no es un defecto del modelo que se arregle con un modelo mejor. Es una propiedad de cómo funciona la elección: el agente compara semánticamente lo que pidió el usuario contra el texto de cada descripción disponible. Si dos textos se parecen, la señal se reparte entre ambos. Si el system prompt tiene veinte reglas, la regla número diecisiete compite con las otras diecinueve por la atención del modelo en ese turno. Un modelo más capaz mejora el promedio, no elimina el fenómeno.
Los cuatro modos de degradación
Cuando alguien dice "mi agente empezó a fallar", casi siempre está viendo uno de estos cuatro. Vale la pena tener el nombre de cada uno, porque el corte que resuelve uno no resuelve necesariamente los otros.
1. Colisión de tools
Dos o más tools cuyas descripciones se superponen semánticamente, y el modelo elige entre ellas de forma inconsistente.
Cómo se ve. En el panel de ejecuciones, el mismo tipo de mensaje dispara tools distintas en corridas distintas. O peor: dispara consistentemente la tool equivocada, porque la descripción de esa tool casualmente se parece más a cómo hablan los clientes reales.
Ejemplo en TuTienda. El agente tiene estas dos:
# Tool 1 — Name: check_refund_eligibility
# Description: "Verifica si un cliente puede recibir dinero de vuelta
# por una compra con la que no quedó conforme."
# Tool 2 — Name: open_dispute
# Description: "Abre una disputa cuando el cliente no reconoce o no
# está conforme con un cargo en su tarjeta."
Las dos contienen la frase "no está conforme". Una es sobre devolver un producto; la otra es sobre un cobro que el cliente no reconoce. Para una persona son casos obvios y distintos. Para un modelo que compara textos, son dos descripciones con un 40% de vocabulario compartido.
Por qué el corte lo resuelve. Si check_refund_eligibility vive en el order_specialist y open_dispute vive en el billing_specialist, el modelo nunca las ve juntas. En el momento en que el especialista de facturación razona, check_refund_eligibility no existe en su contexto — no hay con qué colisionar.
Ojo con esto: parte de este problema se resuelve sin separar agentes, simplemente escribiendo mejores descripciones, que es lo que aprendiste en la lección 5 del Módulo 4. Antes de partir un agente por colisión de tools, prueba primero a arreglar las descripciones. Si con dos o tres tools eso alcanza, no necesitas un equipo. Si tienes nueve tools de cuatro dominios distintos, escribir descripciones mutuamente excluyentes entre las nueve se vuelve un ejercicio imposible: cada vez que aclaras una, se solapa con otra.
2. Dilución del prompt
El system prompt creció hasta el punto en que una instrucción específica pierde fuerza frente al resto del texto.
Cómo se ve. Una regla que escribiste y probaste hace semanas deja de cumplirse, sin que nadie la haya borrado. Típicamente es una regla de excepción —"para electrónicos el plazo es de 14 días, no 30"— o una prohibición —"nunca ofrezcas descuentos"—. El agente la respeta en la mayoría de los casos y la ignora en algunos, casi siempre cuando la conversación se alargó o cuando el cliente insistió.
Ejemplo en TuTienda. Este es el system prompt del agente monolítico, resumido a sus encabezados:
# System Message de support_agent (~900 palabras en total)
#
# Eres el agente de atención de TuTienda. Tono cálido, tuteo,
# respuestas breves.
#
# PEDIDOS: usa lookup_order con el número que dé el cliente. Si el
# pedido lleva más de 5 días hábiles en tránsito, ofrece disculpas
# y propón seguimiento. Nunca prometas una fecha exacta de entrega.
#
# COBROS: usa lookup_charge. Si el cliente no reconoce el cargo,
# verifica primero el perfil con get_customer_profile por si compró
# con otro nombre. Solo entonces usa open_dispute. Nunca prometas
# un reembolso ni un plazo de resolución.
#
# DEVOLUCIONES: el plazo general es de 30 días. Para la categoría
# electronics el plazo es de 14 días. Los productos de higiene
# personal no admiten devolución. Verifica siempre con
# check_refund_eligibility antes de confirmarle algo al cliente.
#
# VENTAS: si el cliente pregunta por productos, usa
# recommend_products. Respeta su presupuesto si lo menciona.
# No recomiendes más de tres productos por respuesta.
#
# ESCALAMIENTO: si el cliente pide hablar con una persona dos veces,
# crea un ticket con create_ticket y avísale.
#
# (…y seis párrafos más de casos especiales acumulados)
Cuenta las prohibiciones: "nunca prometas una fecha exacta", "nunca prometas un reembolso", "no recomiendes más de tres productos", "los de higiene no admiten devolución". Son cuatro reglas negativas dispersas en 900 palabras, cada una perteneciente a un dominio distinto. En un turno donde el cliente está hablando de un cobro, las tres reglas de los otros dominios están ocupando contexto sin aportar nada — y la regla de facturación que sí importa está compitiendo con ellas.
Por qué el corte lo resuelve. El system prompt del billing_specialist tiene 150 palabras y contiene exactamente las reglas de facturación. Ninguna regla de devoluciones, ninguna de ventas. Esa regla ya no compite con nada.
3. Contaminación de rol
El agente mezcla el registro, el tono o la intención de un dominio con otro, porque un solo system prompt le pidió ser varias personas a la vez.
Cómo se ve. Es el modo más difícil de detectar en un log, porque no hay ninguna tool mal llamada — la respuesta es técnicamente correcta y aun así está mal. El caso clásico: un cliente enojado por un cobro recibe, al final de la respuesta, una recomendación de producto. El agente no se equivocó de tool: el prompt le dijo que recomiende cuando pueda, y nada le dijo que un cliente en disputa no es el momento.
Ejemplo en TuTienda. Con el prompt de arriba, esta respuesta es perfectamente consistente con las instrucciones:
"Ya abrí la disputa por el cargo de $1,200 que no reconoces, el equipo la revisa pronto. Por cierto, vi que te interesan los audífonos — tenemos tres modelos nuevos que podrían gustarte."
Nadie escribió una instrucción que impida eso. Y escribirla es más difícil de lo que parece, porque tendrías que enumerar todas las combinaciones prohibidas de dominios: no vendas durante una disputa, no vendas durante un reclamo de envío, no vendas cuando el cliente pidió hablar con una persona. Cada regla nueva es otra línea diluyendo el prompt — el modo 2 empeorando mientras intentas arreglar el 3.
Por qué el corte lo resuelve. Si sales_specialist es un agente aparte, no se ejecuta a menos que alguien lo llame. El triage_agent no lo va a llamar en un caso de disputa, porque su trabajo es leer la intención del cliente y esa intención no era comprar. La prohibición deja de ser una regla en un prompt y pasa a ser una consecuencia de la arquitectura.
4. Radio de daño
Un solo agente con todas las tools significa que cualquier mensaje que logre influir en él alcanza, potencialmente, todas las acciones del sistema.
Cómo se ve. No se ve, hasta que se ve. Es el modo silencioso. Si un mensaje del cliente —o el contenido de un correo que el agente leyó con una tool, que es peor— logra empujar al agente hacia una acción que no debía tomar, el conjunto de acciones disponibles para ese empujón es el conjunto completo de las nueve tools. Un agente de ventas que además puede abrir disputas y crear tickets tiene un radio de daño mucho más grande que uno que solo puede recomendar productos.
Ejemplo en TuTienda. El agente monolítico puede, en el mismo turno, leer el perfil de un cliente (get_customer_profile), abrir una disputa (open_dispute) y mandar un correo (send_email). Nada en la arquitectura impide que esas tres se combinen en una secuencia que nadie diseñó.
Por qué el corte lo resuelve. Cada especialista tiene solo las tools de su dominio. El sales_specialist no puede mandar correos porque no tiene esa tool conectada — no porque el prompt se lo prohíba, sino porque físicamente no está en su puerto ai_tool. Esa es la diferencia entre una restricción de texto y una restricción estructural, exactamente la misma distinción que trazaste en la lección 5 del Módulo 4 con los límites de confianza.
Este cuarto modo tiene un módulo entero dedicado más adelante en esta guía —el de seguridad—, así que aquí solo lo nombramos como una razón de diseño más para separar. Lo que importa retener ahora: la separación por responsabilidad también es una separación de permisos, y eso es un beneficio que se obtiene gratis al cortar bien.
Ejemplo trabajado: leer los cuatro modos en un log
Vamos a diagnosticar el agente de TuTienda con datos, no con impresiones. Supón que revisas las últimas 40 ejecuciones en el panel de n8n. Para hacerlo bien, necesitas una cosa activada en el nodo AI Agent:
# Nodo: AI Agent — Name: support_agent
# Options:
# returnIntermediateSteps = true
Return Intermediate Steps hace que la salida del agente incluya, además del texto final, un arreglo con cada acción que tomó antes de responder: qué tool llamó, con qué argumentos, y qué recibió de vuelta. Sin esto solo ves el resultado; con esto ves el razonamiento hecho pasos. Es tu instrumento de diagnóstico principal en todo este módulo.
Con eso activado, esto es lo que encuentras en las 40 ejecuciones, y qué modo indica cada hallazgo:
| Hallazgo en el log | Modo | Qué lo confirma |
|---|---|---|
6 de 11 mensajes sobre cargos llamaron a check_refund_eligibility en lugar de open_dispute | 1 — colisión de tools | Las dos descripciones comparten "no está conforme"; la elección se reparte |
| 3 respuestas confirmaron una devolución de electrónicos a los 22 días de la compra | 2 — dilución del prompt | La regla de los 14 días existe en el prompt y no se aplicó; el plazo general de 30 sí |
| 4 respuestas a clientes con disputa abierta terminaron con una recomendación de producto | 3 — contaminación de rol | Ninguna tool mal llamada; el problema es el registro, no la acción |
En 1 ejecución el agente llamó send_email con un cuerpo que citaba texto de un correo entrante | 4 — radio de daño | La tool de lectura alimentó una tool de escritura sin que nadie lo diseñara |
Qué esperar. Esa tabla es un diagnóstico defendible. Con ella puedes decir: "de 40 ejecuciones, 13 tuvieron un defecto atribuible a que el agente sostiene cuatro dominios a la vez, y los defectos son de tres tipos distintos que no se arreglan con la misma corrección". Eso es muy diferente a "creo que tiene demasiadas tools".
Fíjate también en algo incómodo: las cuatro filas se ven en el log, pero ninguna de las 40 ejecuciones aparece marcada como fallida en n8n. Todas corrieron sin error. Los cuatro modos de degradación son invisibles para el motor de ejecución, porque no son fallas técnicas — son decisiones del modelo que resultaron ser las equivocadas. Por eso el diagnóstico exige leer conversaciones, no leer indicadores de estado.
Dónde cortar: por responsabilidad, no por tarea
Ya sabes que hay que separar. Falta lo difícil: por dónde. Y es difícil porque hay una tentación fuerte y equivocada: cortar por tarea.
Cortar por tarea significa crear un agente por cada cosa que el sistema hace: un agente que busca pedidos, un agente que manda correos, un agente que crea tickets. Suena ordenado y es un error, por dos razones. Primero, porque un agente que solo llama una tool no está tomando ninguna decisión interesante — es una tool con una capa de modelo encima, que cuesta una llamada al modelo y no aporta criterio. Segundo, porque los casos reales no llegan partidos por tarea: llegan partidos por dominio. Un cliente no dice "necesito una búsqueda de pedido seguida de un envío de correo"; dice "¿dónde está mi pedido?".
Cortar por responsabilidad significa otra cosa: agrupar todo lo que hace falta para cerrar un tipo de caso de principio a fin. El order_specialist no es "el que busca pedidos" — es "el que resuelve cualquier cosa relacionada con un pedido hasta dejarla cerrada", lo que incluye buscarlo, evaluar si el retraso amerita disculpa, verificar una devolución y crear un ticket si no puede resolverlo.
La regla operativa que te sirve para decidir es esta:
Una responsabilidad es un ámbito con un criterio de salida único. Si puedes escribir en una sola frase "este agente termina su trabajo cuando ___", y esa frase no tiene un "o" adentro, tienes una responsabilidad.
Aplícala:
- "El
order_specialisttermina cuando el cliente sabe el estado real de su pedido, o cuando quedó registrado un ticket porque no se pudo determinar." — Ese "o" es aceptable: son dos finales del mismo caso, uno exitoso y uno de escape. Es una responsabilidad. - "El
support_agenttermina cuando el cliente sabe el estado de su pedido, o cuando se abrió una disputa, o cuando recibió una recomendación de producto." — Ese "o" separa tres casos que no tienen nada que ver entre sí. Son tres responsabilidades disfrazadas de una.
La prueba de las tres preguntas
Antes de crear un agente nuevo, respóndele estas tres. Si alguna te cuesta, todavía no tienes una responsabilidad bien recortada:
- ¿Cuál es su criterio de salida único? Una frase, sin "o" que separe dominios.
- ¿Qué tools necesita, y solo él? Si dos agentes candidatos necesitan la misma tool de acción —no de lectura, de acción—, revisa si en realidad son uno solo. Compartir una tool de lectura como
get_customer_profilees normal; compartiropen_disputees señal de que el corte está mal hecho. - ¿Qué le tiene que decir alguien para que empiece a trabajar? Si la respuesta es "el mensaje completo del cliente, tal cual", todavía no es un especialista — es otro generalista. Un especialista recibe un encargo acotado. Esto es el contrato de entrada, y lo formalizas en la lección 5.
La tabla de síntoma a corte
| Síntoma que observas | Modo | Primera corrección a intentar | ¿Justifica separar agentes? |
|---|---|---|---|
| Dos tools de un mismo dominio se confunden entre sí | 1 | Reescribir las descripciones para que sean mutuamente excluyentes | No |
| Tools de dominios distintos se confunden entre sí | 1 | Reescribir descripciones — y si sigue, separar | Sí, si persiste |
| Una regla de excepción se ignora a veces | 2 | Acortar el prompt quitando lo que no aplica a ese dominio | Sí, si el prompt no se puede acortar sin perder dominios |
| El tono o la intención de un dominio se filtra a otro | 3 | Ninguna corrección de texto funciona bien | Sí |
| Una tool de acción sensible está disponible en contextos donde no debería | 4 | Revisión humana (Módulo 4, lección 5) como primera barrera | Sí, además de la revisión humana |
| El agente responde bien pero tarda mucho y llama muchas tools | ninguno | Revisar el prompt y el Max Iterations | No — separar lo haría más lento |
Esa última fila es importante y volveremos sobre ella en la lección 7: separar no acelera nada. Al contrario. Si tu problema es de latencia o de costo, la delegación es exactamente la dirección equivocada.
Cuándo NO separar
Tres casos donde un solo agente sigue siendo la respuesta correcta, y conviene poder defenderlos:
Un solo dominio, aunque tenga muchas tools. Un agente que consulta pedidos, verifica el estado del envío con la transportadora, calcula el retraso y crea un ticket de seguimiento tiene cuatro tools y una sola responsabilidad. No lo partas. Las cuatro tools pertenecen al mismo criterio de salida y sus descripciones se pueden hacer mutuamente excluyentes sin acrobacias.
Volumen bajo y equipo de una persona. Un sistema multi-agente es más difícil de depurar: cuando algo sale mal, tienes que averiguar primero en qué nivel salió mal. Si tu agente atiende veinte conversaciones al día y lo mantienes tú solo, el costo de esa complejidad puede superar al beneficio de la precisión, incluso con síntomas de dilución presentes.
Cuando el trabajo es determinista. Si lo que quieres encapsular no requiere ningún juicio —consultar una base de datos, aplicar una regla de plazo con una fórmula fija, calcular un monto— eso no es un agente, es un sub-workflow. Ya lo construiste en la lección 6 del Módulo 4, y sigue siendo la respuesta correcta: cuesta cero llamadas al modelo, es predecible y se puede probar con datos fijos. Reserva los agentes para donde de verdad hace falta que algo interprete lenguaje o elija entre caminos.
Ejemplo trabajado: el corte de TuTienda
Tomamos el system prompt monolítico de arriba y le aplicamos la regla. Primero, las responsabilidades candidatas con su criterio de salida:
# Responsabilidad A — pedidos y devoluciones de producto
# Criterio de salida: el cliente conoce el estado real de su pedido
# o el resultado de su solicitud de devolución (procede / no procede
# / quedó en ticket).
# Tools: lookup_order, check_refund_eligibility, create_ticket
# Responsabilidad B — cobros y facturación
# Criterio de salida: el cargo quedó explicado o quedó una disputa
# abierta con su número de referencia.
# Tools: lookup_charge, open_dispute, get_customer_profile
# Responsabilidad C — recomendación de producto
# Criterio de salida: el cliente recibió hasta tres opciones que
# respetan su presupuesto y su necesidad declarada.
# Tools: recommend_products, search_knowledge_base
# Responsabilidad D — entender qué necesita el cliente y repartir
# Criterio de salida: cada tema del mensaje fue atendido por el
# especialista que corresponde y el cliente recibió una respuesta única.
# Tools: A, B y C (los otros tres agentes)
Ahora revisa la lista contra las tres preguntas:
- Criterio de salida único: las cuatro pasan. La A tiene un "o" pero separa finales del mismo caso, no dominios.
- Tools propias:
create_ticketaparece solo en A.get_customer_profileestá solo en B, aunque sería razonable que A también lo consultara — si más adelante A lo necesita, es una tool de lectura y compartirla no rompe nada.send_emaildesapareció del reparto: mirando el prompt original, solo se usaba para confirmar acciones que ahora cada especialista puede reportar en su respuesta. Una tool que no encuentra dueño en ningún corte es casi siempre una tool que no hacía falta. - Qué necesita para empezar: A necesita un número de pedido o una descripción del producto. B necesita un monto y una fecha aproximada. C necesita una necesidad y, si existe, un presupuesto. D necesita el mensaje crudo del cliente — y es el único que lo necesita, porque es el que traduce lenguaje de cliente a encargos concretos.
Compara ahora el prompt de B contra el monolito:
# System Message de billing_specialist (~140 palabras)
#
# 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.
#
# 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.
#
# Devuelve siempre: qué encontraste, qué acción tomaste y si el caso
# quedó cerrado o pendiente.
Qué esperar. Ciento cuarenta palabras contra novecientas. Tres tools contra nueve. Una sola prohibición ("nunca prometas un reembolso ni un plazo") en vez de cuatro dispersas. Cuando este agente razona sobre un cargo, no hay ninguna regla de devoluciones ni ninguna instrucción de ventas ocupando su contexto. Los modos 1, 2 y 3 no desaparecen por magia —todavía puedes escribir mal la descripción de una de las tres tools—, pero el espacio donde pueden ocurrir se redujo a una fracción.
Y fíjate en la última línea del prompt: "Devuelve siempre: qué encontraste, qué acción tomaste y si el caso quedó cerrado o pendiente." Esa línea no estaba en el monolito y no es decorativa. Es el primer esbozo del contrato de salida que el especialista le debe a quien lo llamó — el tema completo de la lección 5.
Errores comunes
Cortar por tarea en vez de por responsabilidad (conceptual). Qué pasa: alguien crea un email_agent, un database_agent y un ticket_agent, uno por cada sistema conectado. El resultado es un sistema donde el orquestador tiene que saber la secuencia completa de cada caso —primero busca, después evalúa, después manda el correo— porque ninguno de los tres especialistas sabe cerrar un caso completo. El orquestador vuelve a ser el monolito, con el costo extra de tres llamadas al modelo. Por qué pasa: cortar por sistema es la partición más visible en el canvas, porque los nodos ya están agrupados así. Cómo detectarlo: intenta escribir el criterio de salida de cada agente; si te sale "termina cuando mandó el correo" en vez de "termina cuando el cliente supo el estado de su caso", cortaste por tarea. Cómo corregirlo: parte de los tipos de caso que llegan al sistema, no de los sistemas conectados; agrupa por "qué necesita el cliente" y deja que las tools caigan donde caigan.
Separar por síntomas de latencia o costo (conceptual). Qué pasa: el agente tarda quince segundos en responder, alguien concluye que "está sobrecargado" y lo parte en tres, y ahora tarda treinta. Por qué pasa: la palabra "sobrecargado" hace pensar en un problema de capacidad, como una máquina saturada, cuando en realidad la degradación del monolito es de precisión, no de velocidad. Cómo detectarlo: revisa intermediateSteps y cuenta cuántas tools llamó el agente antes de responder; si son muchas, tu problema es de prompt o de Max Iterations, no de arquitectura. Cómo corregirlo: la lección 7 pone los números —cada delegación agrega al menos una llamada completa al modelo, en serie— y deja claro que separar siempre suma latencia; si tu problema es tiempo de respuesta, la solución está en el prompt, en el modelo o en las tools, no en el equipo.
Dar el diagnóstico por hecho sin leer un solo log (práctico). Qué pasa: alguien lee esta lección, reconoce los cuatro modos, y rediseña el sistema entero basándose en que "seguro me está pasando el modo 2". Después de la separación, el problema real —que era una tool con la Description mal escrita— sigue ahí, ahora repartido en dos agentes. Por qué pasa: los cuatro modos son reconocibles y suenan a diagnóstico apenas los lees, sin necesidad de evidencia. Cómo detectarlo: si no puedes citar un número de ejecución concreto donde ocurrió el defecto que dices tener, no tienes diagnóstico. Cómo corregirlo: activa returnIntermediateSteps, revisa entre 20 y 40 ejecuciones reales, y arma la tabla de hallazgos del ejemplo trabajado antes de mover un solo nodo; el trabajo de una tarde te ahorra rediseñar dos veces.
Dejar al orquestador con conocimiento de dominio "por si acaso" (práctico). Qué pasa: al separar, alguien copia el system prompt viejo completo dentro del triage_agent "para que tenga contexto", y le conecta además los especialistas. Ahora el sistema tiene el prompt diluido del monolito más el costo de las delegaciones. Por qué pasa: quitar texto de un prompt que funcionaba da miedo, y "más contexto no puede hacer daño" suena razonable. Cómo detectarlo: busca en el prompt del orquestador cualquier número, plazo, monto o nombre de política; ninguno debería estar ahí. Cómo corregirlo: el orquestador solo necesita saber qué especialistas existen y cuándo llamar a cada uno — su prompt debería poder escribirse sin conocer una sola regla de negocio de TuTienda.
Ejercicios
Ejercicio 1 — Clasifica el modo de degradación. Para cada uno de estos cuatro hallazgos en un log, di cuál de los cuatro modos indica y por qué:
(a) El agente confirma que una devolución procede y dos turnos después dice que no procede, con los mismos datos.
(b) Un cliente que reporta que nunca recibió su pedido termina la conversación con un cupón de descuento ofrecido espontáneamente.
(c) lookup_charge y lookup_order se llaman de forma intercambiable cuando el cliente menciona "mi compra".
(d) El agente leyó un correo entrante con una tool y en el mismo turno usó send_email para reenviar parte de ese contenido a otra dirección.
Ver solución
(a) Modo 2, dilución del prompt. La regla de plazo existe pero no se aplica de forma estable; la inconsistencia entre turnos es la firma característica de una instrucción que compite con otras por atención. También podría ser el modo 1 si hay dos tools de elegibilidad, así que el paso siguiente es mirar en intermediateSteps si se llamó la misma tool las dos veces: si sí, es dilución; si no, es colisión.
(b) Modo 3, contaminación de rol. No hay ninguna tool mal llamada. El agente hizo algo perfectamente permitido por su prompt —fue amable y ofreció valor— en un contexto donde ningún diseñador lo habría querido. Es el modo que ninguna corrección de texto arregla del todo.
(c) Modo 1, colisión de tools. La palabra "compra" es igualmente compatible con un pedido y con un cargo. Aquí la primera corrección no es separar: es reescribir las dos descripciones para que sean mutuamente excluyentes ("usa esta tool solo cuando el cliente mencione un monto o una tarjeta", "usa esta tool solo cuando el cliente mencione un número de pedido o un envío").
(d) Modo 4, radio de daño. Una tool de lectura alimentó una tool de escritura en una secuencia que nadie diseñó. Es el modo silencioso, y es también la puerta de entrada del problema de seguridad que el Módulo 7 trata a fondo.
Por qué funciona: los cuatro modos se distinguen por dónde se ve el defecto — en la elección de tool (1), en el cumplimiento de una regla (2), en el registro de la respuesta (3), o en la combinación de acciones (4). Nombrar el modo te dice qué corrección probar primero.
Ejercicio 2 — Aplica la regla del criterio de salida. Un equipo propone estos cinco agentes para un sistema de reservas de un restaurante. Para cada uno, escribe su criterio de salida en una frase y decide si es una responsabilidad legítima o si hay que fusionarlo con otro:
(a) booking_agent — crea reservas.
(b) availability_agent — consulta mesas disponibles.
(c) cancellation_agent — cancela reservas.
(d) menu_agent — responde preguntas sobre el menú, alergias e ingredientes.
(e) triage_agent — recibe al cliente y reparte.
Ver solución
(a), (b) y (c) son una sola responsabilidad, no tres. Escribe el criterio de salida de (b): "termina cuando devolvió la lista de mesas disponibles". Eso no cierra ningún caso de un cliente — nadie escribe a un restaurante para recibir una lista de mesas. Es una tarea, no una responsabilidad. Lo mismo (a) y (c): crear y cancelar son dos acciones del mismo ámbito, y un cliente que quiere cambiar su reserva necesita las dos en el mismo razonamiento. El corte correcto es un reservations_specialist con criterio de salida "termina cuando la reserva del cliente quedó en el estado que pidió: creada, modificada, cancelada o registrada como imposible por falta de disponibilidad", con las tres tools adentro.
(d) sí es una responsabilidad separada: su criterio de salida —"termina cuando el cliente tiene la información de menú, ingredientes o alergias que pidió"— no comparte tools ni conocimiento con las reservas, y el dominio de alergias tiene reglas propias que uno no quiere diluidas en un prompt de reservas.
(e) es una responsabilidad legítima, la de orquestación: "termina cuando cada tema del mensaje fue atendido por el especialista correcto y el cliente recibió una respuesta única".
Resultado: tres agentes, no cinco.
Por qué funciona: la pregunta "¿cierra esto un caso de un cliente real?" separa tareas de responsabilidades mejor que cualquier intuición sobre qué tan importante es cada acción. Consultar disponibilidad es importantísimo y aun así no cierra nada.
Ejercicio 3 — Defiende el no separar. Un agente de una clínica dental atiende un solo tipo de caso: agendar, reagendar y cancelar citas. Tiene seis tools: check_availability, create_appointment, reschedule_appointment, cancel_appointment, get_patient_record y send_confirmation. El equipo quiere partirlo en tres agentes "porque tiene demasiadas tools". Escribe la defensa de no separarlo, usando el criterio de esta lección, y di qué evidencia te haría cambiar de opinión.
Ver solución
La defensa: las seis tools pertenecen a un único criterio de salida —"termina cuando la cita del paciente quedó en el estado que pidió, o quedó registrado que no fue posible"—. No hay dos dominios que puedan contaminarse mutuamente (modo 3), no hay reglas de negocio de ámbitos distintos compitiendo en el prompt (modo 2), y las seis descripciones se pueden hacer mutuamente excluyentes sin acrobacias porque cada acción es claramente distinta: consultar, crear, mover, cancelar, leer historial, confirmar. El número de tools no es el criterio; el número de responsabilidades sí, y aquí es uno. Separar agregaría latencia y costo (lección 7) a cambio de nada.
La evidencia que cambiaría la decisión: hallazgos concretos en el log de los modos 1, 2 o 3. Por ejemplo, si reschedule_appointment y cancel_appointment se confunden sistemáticamente, la primera corrección es reescribir sus descripciones, no separar. Pero si a la clínica le agregan un dominio nuevo —"y además responde dudas sobre precios y planes de financiamiento"— ahí sí aparece una segunda responsabilidad, con sus propias reglas y su propio tono, y el corte se justifica.
Por qué funciona: poder defender un "no" con el mismo criterio con el que defiendes un "sí" es lo que separa un criterio de diseño de una moda. Multi-agente es una herramienta con costo; se usa cuando compra algo medible.
Resumen y siguiente paso
Ya tienes el diagnóstico. Un agente monolítico se degrada de cuatro formas distintas: colisión de tools (elige mal entre descripciones parecidas), dilución del prompt (una regla específica pierde fuerza entre muchas), contaminación de rol (mezcla el registro de un dominio con otro) y radio de daño (todas las acciones quedan disponibles en todo momento). Los cuatro son invisibles para el motor de ejecución de n8n, así que se diagnostican leyendo conversaciones con returnIntermediateSteps activado, no mirando indicadores de estado. Y el corte se hace por responsabilidad —un ámbito con un criterio de salida único— y no por tarea ni por sistema conectado.
Antes de avanzar deberías poder: nombrar los cuatro modos y decir qué evidencia confirma cada uno; escribir el criterio de salida de un agente candidato y detectar si tiene un "o" que en realidad separa dominios; y defender por qué un agente con seis tools de un solo dominio no se separa.
Lo que todavía no tienes es la forma del sistema resultante. Tienes cuatro responsabilidades recortadas —tres especialistas y un orquestador— pero no una arquitectura: quién manda, quién habla con el cliente, quién guarda la memoria de la conversación, y qué pasa cuando un especialista no puede resolver. Ese reparto de papeles tiene un nombre y un patrón conocido, y es lo que arma la lección 3: orquestador y trabajadores.
Recursos
- How tools work — n8n Docs — cómo el modelo compara la petición del usuario contra la descripción de cada tool; el mecanismo exacto detrás del modo 1.
- AI Agent node — n8n Docs — referencia de las opciones del nodo, incluyendo
Return Intermediate Steps, tu instrumento de diagnóstico en esta lección. - View past executions — n8n Docs — cómo revisar el historial de ejecuciones, filtrarlo y abrir el detalle de cada corrida para armar la tabla de hallazgos.
- Building Effective AI Agents — Anthropic — la recomendación explícita de empezar con la solución más simple y agregar complejidad multi-agente solo cuando mejora un resultado medible; el contrapeso a "más agentes es mejor".
- Use AI for parameters ($fromAI) — n8n Docs — la referencia que necesitas si tu diagnóstico apunta a descripciones de parámetros mal escritas y no a un problema de arquitectura.