En el capítulo anterior tratamos cómo conectar herramientas externas mediante MCP a un solo agente. Hasta aquí ya tienes en marcha un agente autónomo con «cabeza, herramientas, memoria y bucle». Sin embargo, cuando el trabajo crece, el diseño de meterlo todo en un solo agente acaba rompiéndose en algún punto. En este capítulo ordenamos, a nivel conceptual e independiente del framework, el «diseño multiagente», que reparte los papeles y resuelve con varios agentes, y su forma de coordinación (A2A: Agent-to-Agent).
La meta es saber juzgar «cuándo y cómo dividir para volverse más fuerte»
Cuándo un solo agente deja de bastar
Un solo agente es simple, fácil de ver de un vistazo y de seguir en su comportamiento; por eso, precisamente, lo correcto es empezar por uno solo. El problema surge cuando le vas añadiendo papeles sin parar. Si metes en un mismo prompt un montón de responsabilidades —«investiga, escribe, revisa, traduce y también publica…»—, a partir de cierto punto la precisión empieza a caer de golpe.
Las causas son, sobre todo, 3. ①Las instrucciones se vuelven largas y ambiguas (cuanto más apilas «esto y aquello», más duda el modelo sobre qué priorizar). ②El contexto se infla (arrastra hasta información irrelevante y las instrucciones clave se diluyen). ③Hay demasiadas herramientas (cuantas más opciones, más fácil es elegir la equivocada). Un solo agente sobrecargado es, por así decirlo, «una oficina en caos donde una persona hace de todo a la vez».
💡 Un cambio de enfoque. En vez de seguir haciendo más listo a un solo agente, pasa al enfoque de «hacer cooperar a varios agentes pequeños, cada uno centrado en un único papel». Ese es el punto de partida del diseño multiagente. Por la misma lógica con la que una organización humana reparte el trabajo, cuanto más estrecha y clara sea la responsabilidad de cada uno, más estable es el conjunto.
Ahora bien, dividir no siempre mejora las cosas. Repartir arrastra siempre un coste de coordinación. Por eso el tema central de este capítulo no es solo «cómo dividir», sino discernir «si conviene dividir siquiera». Veamos primero las 3 formas más representativas y luego pasemos a ese criterio de decisión.
Los 3 patrones básicos
Se pueden dibujar infinitas configuraciones multiagente, pero el esqueleto que aparece una y otra vez en la práctica se condensa en 3. Combinando estos 3 puedes explicar casi cualquier configuración. Captemos uno a uno su papel y para qué sirve y para qué no.
El padre (orquestador) traza el plan general, reparte las tareas a los hijos (trabajadores) para que las ejecuten y recoge e integra los resultados. Los hijos no se conocen entre sí y solo miran al padre. Su fuerza es que es centralizado y fácil de controlar.
Cuándo conviene: puedes dividir la tarea y quieres correrla en paralelo.
Alineas las etapas y pasas la salida del agente anterior como entrada del siguiente. Por ejemplo, «investigar → redactar → corregir». Como cada etapa asume una sola fase, las responsabilidades son nítidas y es fácil de verificar.
Cuándo conviene: el procedimiento es lineal y las etapas están definidas.
Como «encargado de investigar», «de código» y «de revisar», preparas agentes especialistas con su área fuerte y los invocas según la situación. Al poder acotar las instrucciones y herramientas de cada uno, sube la especialización.
Cuándo conviene: las capacidades exigidas difieren mucho según el dominio.
Estos 3 no son excluyentes. Un sistema real, con frecuencia, adopta una estructura anidada: por ejemplo, «un orquestador dirige a trabajadores del tipo especialista y uno de ellos, por dentro, es un pipeline». Es fácil de manejar la forma de ir apilando: primero fijas un esqueleto en la capa más externa y solo en los puntos necesarios usas otro patrón por dentro.
📊 Si dudas, empieza por el ①. El más versátil de los 3 es orquestador + trabajadores. Como el padre concentra en el centro la planificación y la integración, es fácil de controlar y es la forma básica de muchas configuraciones multiagente. Para ordenar el conjunto de patrones, consulta Qué es multiagente; para entenderlo como sistema, también Qué es un sistema multiagente.
Cuándo dividir y cuándo no
Al conocer los patrones, entran ganas de dividirlo todo. Pero repartir siempre conlleva un «coste de coordinación»: el trabajo de pasar información entre agentes, encajarla y esperarse mutuamente. Multiagente solo es la respuesta correcta cuando el beneficio de dividir supera ese coste de coordinación. Veamos primero los dos lados en paralelo.
- Se puede paralelizar: corres subtareas independientes a la vez y ahorras tiempo
- Hace falta especialización: acotar instrucciones y herramientas por dominio sube la precisión
- La exploración es amplia: quieres repartirte varias perspectivas o candidatos
- Quieres separar el contexto: cortas el contexto por papel y evitas mezclas
- En realidad es simple: complicas sin necesidad un proceso que basta con uno solo
- Aumenta el coste: cuantos más agentes, más se acumulan llamadas al LLM y tokens
- La coordinación pesa: el trabajo de pasar y esperar se come el beneficio de repartir
- Fuerte dependencia secuencial: depende mucho del resultado anterior y casi no hay margen para paralelizar
⚠️ Primero pregúntate «¿basta con uno solo?». Multiagente es potente, pero no es lo que eliges en el primer movimiento. La regla de oro es subir de nivel por escalones: uno solo → afinar el prompt → añadir herramientas → si aún no basta, dividir. Añade complejidad solo tras confirmar «si el agente único de ahora es de verdad el límite». Dividir se puede hacer después.
Como guía práctica, imagina «si, al explicarle ese papel a un colega humano, cabe con naturalidad en la descripción de un solo puesto». Si se puede escribir con un único título, aún basta con un solo agente. El momento en que quieres separarlo en personas distintas —«esta es la de investigar, esta la de escribir»— es cuando toca plantearse dividir. Para el panorama completo del criterio, ve también a Cómo crear un sistema multiagente.
La cooperación entre agentes (A2A)
Si decides dividir, el siguiente reto de diseño es «cómo intercambian información los agentes entre sí». En un equipo humano, equivale a decidir el formato del documento de traspaso y las reglas de reporte. Si esto es ambiguo, por muy buenos que sean cada uno, el conjunto no encaja. Los puntos a cuidar en la cooperación son, a grandes rasgos, 2.
Decides qué pasar y en qué formato. Si conviertes en acuerdo explícito «la instrucción de la tarea, la entrada necesaria y el formato de salida esperado», el receptor no duda. Un traspaso estructurado es más estable que soltar texto libre sin más.
La fase de reunir varias salidas en una. Decide de antemano quién tiene la responsabilidad final de integrar. Incluye en el diseño la prioridad cuando lleguen resultados contradictorios y la forma de reunirlos (resumir, cotejar, votación por mayoría).
El movimiento por estandarizar más este enfoque de «que los agentes se repartan papeles y cooperen» es A2A (Agent-to-Agent). Frente al MCP del capítulo anterior, que era el acuerdo para conectar «agente ↔ herramientas/datos», entiende A2A como el acuerdo para conectar «agente ↔ agente»: la forma común de saber qué puede hacer el otro agente, encargarle una tarea y recibir el resultado.
💡 Recuerda MCP y A2A por contraste. A grandes rasgos: MCP = conectarle «manos» al agente; A2A = «conectar» agentes entre sí. El primero es conexión de herramientas y datos; el segundo, la forma de cooperar. Basta con retenerlo como concepto; los protocolos concretos también los tocaremos en capítulos posteriores. Para más detalle, consulta Qué es el protocolo A2A. Comparándolo con MCP y conexión de herramientas del capítulo anterior, la diferencia queda clara.
Lo importante no es memorizar el nombre del protocolo, sino la actitud de diseño de que «la cooperación necesita acuerdos explícitos». Quién tiene cada tarea, con qué entrada empieza, qué devuelve y, si falla, a quién se le devuelve: decidir estos acuerdos por adelantado es el cimiento de un sistema que no se derrumba aunque crezca la escala.
Gestión del contexto y del coste
El mayor riesgo práctico del multiagente es el inflado del contexto y del coste. Cuantos más agentes y más se pasen información entre sí, más engorda el contexto que carga cada agente y más se acumulan el número de llamadas al LLM y la cantidad de tokens. Si lo dejas a su aire, tiende a un sistema lento, caro e inestable. Coge las riendas en la fase de diseño.
A los hijos, pásales solo lo que esa tarea necesita. No vuelques el historial completo tal cual. El contexto irrelevante también baja la precisión.
Los resultados largos, resúmelos a lo esencial antes de pasarlos. La idea de entregar «conclusión y fundamento», no el log en bruto.
Fija un tope al número de hijos que corren a la vez. Aumentarlos sin límite rompe el sistema por coste y límites de tasa.
Para el padre de razonamiento pesado y los hijos de trabajo simple, usa modelos de tamaño distinto. No pongas todo en el modelo más potente.
«Acotar la información que pasas», en especial, es una decisión de diseño de gran efecto. En el tipo orquestador + trabajadores, el padre tiene la visión global, pero a los hijos les pasa solo la tarea recortada y la entrada mínima. Cuanto más pequeño mantengas el contexto que carga cada hijo, más sube la precisión y más baja el coste. Entiéndelo como la ingeniería de contexto vista en los capítulos anteriores, ahora extendida a varios agentes.
⚠️ El coste pesa como «número de agentes × número de pasos». Añadir un agente hace que sus llamadas se acumulen tantas veces como vueltas del bucle. Cuidado con que cuantos más agentes, más se multiplica en el conjunto el desperdicio de cada uno. Decide desde el principio el tope de paralelismo y el tope de pasos de cada agente (cuándo parar). Este asunto de «medir cuánto estás usando» enlaza con la observabilidad del siguiente capítulo.
Atascos y cómo evitarlos con el diseño
El multiagente tiene fallos propios que no ocurrían con uno solo. En todos, lo básico es prevenirlos de antemano con el diseño, no dejarlos a la suerte en tiempo de ejecución. Retengamos los 3 más representativos y sus medidas.
Varios agentes hacen por partida doble el mismo trabajo, o «de quién es esto» es ambiguo y no lo hace nadie.
Cómo evitarlo: reparte la responsabilidad de cada agente sin solapes y sin huecos, hasta poder enunciar la frontera en una frase.
A se lo pasa a B, B a A… se endosan el trabajo mutuamente y nunca terminan, o repiten el mismo intercambio.
Cómo evitarlo: pon siempre condición de fin y tope de idas y vueltas / pasos. Que el centro (el padre) tenga la decisión final reduce el descontrol.
El fallo o la salida errónea de un agente fluye tal cual al siguiente y detiene el conjunto o fabrica un resultado equivocado.
Cómo evitarlo: verifica la salida antes de traspasarla y decide el plan alternativo ante el fallo (reintentar, alternativa, escalar a un humano).
La lección común a los 3 es decidir «frontera, condición de fin y verificación» antes de escribir el código. Quién se encarga de qué (frontera), cuándo se detiene (condición de fin) y qué se comprueba antes de pasar (verificación). Si tejes estos 3 puntos en el diseño, la mayor parte de los problemas propios del multiagente se previenen de antemano.
📊 «Lo que no se ve, no se arregla». De estos fallos solo te das cuenta cuando qué hizo cada agente se puede rastrear después. Con varios agentes implicados, «dónde ocurrió qué» se vuelve aún más difícil de ver que con uno solo; por eso, precisamente, la evaluación y la observabilidad del siguiente capítulo cobran una importancia todavía mayor en el multiagente.
- Sobrecargar un solo agente baja la precisión. Se resuelve con la cooperación de agentes pequeños de papel estrecho.
- Los patrones básicos son 3: orquestador + trabajadores, pipeline y reparto de papeles. Se pueden anidar.
- Se divide cuando hace falta paralelismo, especialización o exploración amplia. Si es simple, sigue con uno solo. Primero pregúntate «¿basta con uno solo?».
- La cooperación se hace con acuerdos explícitos (A2A = la forma de conectar agentes entre sí). Gestiona el contexto y el coste acotándolos.
- Las trampas propias (duplicidad, pelotas fuera, fallos en cadena) se evitan decidiendo antes en el diseño frontera, condición de fin y verificación.
Cuando varios agentes empiezan a moverse, lo siguiente que necesitas es «medir si de verdad funcionan bien y visibilizar su comportamiento». En el siguiente capítulo 5, «Evaluación y observabilidad», avanzaremos hacia cómo medir la calidad del agente y dejar su comportamiento interno rastreable.