Las arquitecturas de un solo agente chocan contra un techo. Tu agente de código escribe —pero no puede revisar su propia salida. Tu agente de facturación resuelve —pero no puede hablar con el equipo de envíos. La misma perspectiva, los mismos puntos ciegos.
Agregas más y más herramientas. La latencia se dispara. Las ventanas de contexto se desbordan. El techo es estructural, no algo que se resuelva ahondando en el prompt.
La solución: agentes especializados —experiencia acotada, ejecución paralela, protocolos definidos.
Te llevarás tres patrones de orquestación (Supervisor-Worker, Peer-to-Peer, Hierarchical) con código Python, un mapeo rol-modelo que reduce costos un 50-70%, y una topología de trace que convierte una lista plana de spans en un mapa del sistema.
¿Cuándo se rompe un solo agente?
El techo de la complejidad
Los agentes individuales fallan de forma predecible en cuatro escenarios:
Experiencia en múltiples dominios. Un agente que debe ser a la vez experto en código, revisor legal y analista financiero. Inflado del prompt —el system prompt crece para abarcar los tres dominios. Confusión de roles —el modelo mezcla tonos y prioridades. Una revisión legal escrita en jerga de ingeniería informal. Un análisis financiero que salta las verificaciones de cumplimiento porque la persona del “experto en código” domina.
Ejecución paralela. Tres subtareas independientes que podrían ejecutarse en paralelo —investigar precios de la competencia, analizar reseñas de usuarios, resumir especificaciones de producto— procesadas de forma serial por un solo agente. La latencia total es la suma de las tres. Con tres agentes especializados corriendo en paralelo, la latencia es el máximo de las tres.
Autocrítica. Un solo agente genera una salida y evalúa su propia salida. Al mismo proceso cognitivo que produjo la respuesta se le pide encontrar sus fallas. No puede. La revisión entre pares —un agente separado con un prompt diferente, un modelo diferente, una perspectiva diferente— detecta errores que el agente generador no ve.
Explosión del alcance de herramientas. Quince herramientas está bien. Con veinticinco, la precisión del modelo para seleccionar herramientas cae de forma medible —elige la herramienta equivocada más seguido, no encuentra la correcta, o llama las herramientas en el orden incorrecto. Agentes especializados con 5-8 herramientas cada uno superan a un generalista con 25.
Multi-agente no siempre es la respuesta
Los sistemas multi-agente agregan un costo real: latencia de comunicación entre agentes, costo en tokens de los mensajes entre agentes, riesgo de inconsistencia cuando dos agentes producen respuestas contradictorias, y complejidad de depuración cuando no puedes saber qué agente en una cadena de 5 produjo la salida incorrecta. Si tu tarea puede manejarla un agente bien prompteado con 5-10 herramientas bien acotadas, no introduzcas la complejidad multi-agente. Empieza con uno solo. Ve a multi solo cuando el agente individual falle de forma demostrable —confusión de herramientas, inconsistencia de roles, o latencia serial que la ejecución paralela eliminaría.
Nuestra guía de arquitectura de agente individual cubre los fundamentos. Este artículo asume que has llevado el diseño de un solo agente a su límite y ahora estás chocando con el techo.
Tres patrones de orquestación
Patrón 1: Supervisor-Worker
Un agente supervisor orquesta. Descompone la tarea, asigna subtareas a los workers, agrega resultados y ejecuta un control de calidad antes de devolver la salida. Los workers son especializados —cada uno tiene su propio system prompt, conjunto de herramientas y modelo. Los workers no hablan entre sí. Solo se comunican con el supervisor.
class SupervisorAgent:
def __init__(self, model: str, workers: list[WorkerAgent]):
self.model = model
self.workers = {w.name: w for w in workers}
async def execute(self, task: str) -> dict:
plan = await self._decompose(task)
results = {}
for subtask in plan["subtasks"]:
worker = self.workers[subtask["assigned_to"]]
results[subtask["id"]] = await worker.execute(subtask)
synthesis = await self._synthesize(task, results)
quality = await self._quality_gate(synthesis)
if quality["passed"]:
return synthesis
else:
return await self._retry_or_escalate(task, quality["issues"])Ideal para: tareas que se descomponen limpiamente en subtareas independientes, necesitan control de calidad central y tienen una estructura de equipo relativamente fija. Compensación: el supervisor se convierte en un cuello de botella y un punto único de falla. No es adecuado cuando los workers necesitan negociar dinámicamente entre sí.
Patrón 2: Peer-to-Peer
Sin jerarquía. Todos los agentes son pares. Cualquier agente puede iniciar comunicación con cualquier otro a través de un bus de mensajes compartido. Los agentes descubren las capacidades de los demás y negocian transferencias de tareas dinámicamente.
class PeerAgent:
def __init__(self, name: str, role: str, model: str, message_bus: MessageBus):
self.name = name
self.role = role
self.model = model
self.bus = message_bus
self.bus.subscribe(self.name, self._handle_message)
async def _handle_message(self, msg: Message):
if msg.type == "request":
result = await self._execute_task(msg.content)
await self.bus.send(Message(
to=msg.from_agent,
type="response",
content=result,
correlation_id=msg.correlation_id
))Ideal para: negociación dinámica —un agente de revisión de código descubre un bug y le envía directamente el arreglo al agente de código, sin supervisor en el bucle. Sin cuellos de botella. Flujos de trabajo flexibles. Compensación: depurar es más difícil —el grafo de conversación puede volverse complejo, y los bucles infinitos de mensajes o las salidas contradictorias entre pares requieren mecanismos explícitos de detección de bucles y resolución de conflictos.
Patrón 3: Hierarchical
Escalación de múltiples niveles. Los agentes de primera línea manejan casos rutinarios. Los casos complejos o inusuales escalan a agentes senior. Los casos más difíciles llegan a un agente principal o a un humano. La calidad y el costo del modelo escalan con el nivel —Tier 1 usa modelos baratos, Tier 2 usa nivel medio, Tier 3 usa frontier.
class TieredAgentSystem:
def __init__(self, tiers: list[AgentTier]):
self.tiers = sorted(tiers, key=lambda t: t.level)
async def execute(self, task: str) -> dict:
for tier in self.tiers:
result = await tier.agent.execute(task)
if result["confidence"] >= tier.confidence_threshold:
return result
return await self._escalate_to_human(task)Ideal para: flujos de soporte con niveles naturales de complejidad, moderación de contenido con auto-filtro —revisión senior —escalación a humano, y cualquier dominio donde la mayoría de las solicitudes son simples y una minoría requiere experiencia profunda. Compensación: la lógica de escalación requiere ajustes a partir de datos de producción —necesitas un bucle de retroalimentación para calibrar los confidence thresholds de cada nivel.
Protocolos de comunicación entre agentes
Function calling como protocolo entre agentes
El enfoque más simple: el agente A llama a una herramienta send_message_to_agent_b. La herramienta está definida en el schema de function calling del agente A. Compatible con la infraestructura existente. Cero protocolos nuevos que aprender. Limitación: bloqueo síncrono. Cada mensaje es un viaje de ida y vuelta completo de llamada de herramienta. En conversaciones de varios turnos entre agentes, la latencia se acumula linealmente. Cuando las definiciones de herramientas necesitan abarcar varios proveedores con schemas inconsistentes, nuestra guía de function calling y uso de herramientas cubre la capa de normalización que hace que las llamadas de herramientas entre agentes sean portables entre modelos.
MCP para la comunicación entre agentes
Cada agente expone sus capacidades como un servidor MCP. Otros agentes, actuando como clientes MCP, descubren e invocan esas capacidades. Nuestra guía de MCP cubre los fundamentos del protocolo. En los sistemas multi-agente, MCP proporciona descubrimiento de capacidades estandarizado —un agente no necesita saber de antemano qué pueden hacer otros agentes. Consulta el ecosistema MCP y descubre capacidades dinámicamente.
Google A2A
Diseñado específicamente para la comunicación agente-a-agente (especificación A2A). Agent Cards para el descubrimiento de capacidades. Ciclo de vida estructurado de la Task: submitted —working —completed o failed. Actualizaciones en streaming durante la ejecución de la tarea. Intercambio de contenido multimodal. Cross-framework —agentes construidos con diferentes frameworks pueden interoperar si hablan A2A. Ideal para sistemas multi-agente heterogéneos donde distintos equipos usan distintas tecnologías.
Bus de mensajes personalizado
Redis Pub/Sub o NATS con un schema de mensajes estructurado. Control máximo sobre enrutamiento, persistencia, reintentos y observabilidad. Esfuerzo de implementación máximo. El schema: {agent_id, correlation_id, message_type, payload, timestamp}. Elígelo cuando tus patrones de comunicación entre agentes sean lo suficientemente únicos como para que ningún protocolo estándar encaje —o cuando necesites garantías (entrega exactly-once, entrega ordenada) que los protocolos de más alto nivel no brindan.
Mapeo rol-modelo
La trampa de costos más grande en los sistemas multi-agente: todos los agentes reciben un modelo frontier. Tu agente clasificador que enruta “facturación” vs. “soporte técnico” no necesita Claude Opus a $15/M de tokens de entrada. Necesita GPT-4o Mini a $0.15 —y la precisión de clasificación es idéntica.
| Rol del agente | Modelo recomendado | Costo/1M de entrada | Justificación |
|---|---|---|---|
| Clasificador/Enrutador | DeepSeek V3.2 / GPT-4o Mini | $0.14-0.15 | Clasificación simple. Los modelos baratos rinden igual que los frontier. |
| Q&A básico / FAQ | GPT-4o Mini / Claude Haiku | $0.15-0.25 | Respuestas factuales con retrieval aumentado. Capacidad de nivel medio, precio mínimo. |
| Generación de contenido | GPT-4o / Claude Sonnet 4 | $2.50-3.00 | El tono, la estructura y la creatividad importan. Vale la pena el premium de nivel medio. |
| Generación de código | Claude Sonnet 4 / DeepSeek V4 Pro | $0.42-3.00 | Los datos de SWE-bench impulsan esta elección. El rendimiento de código de DeepSeek por dólar es excepcional. |
| Revisión de código / Quality Gate | Claude Opus 4 / GPT-5.5 | $10-15.00 | Encontrar bugs requiere razonamiento frontier. Un bug que se escapa cuesta más que el premium del modelo. |
| Síntesis final | Claude Opus 4 | $15.00 | La salida que ve el usuario. Vale la pena el premium por tono, precisión y seguimiento de instrucciones. |
El seguimiento de costos por agente —gen_ai.cost.total en cada span de LLM con agent_id como atributo del span— te da un reporte de costos por agente. Rápidamente identificarás al agente que consume el 40% de tu presupuesto multi-agente. Bájalo de Opus a Sonnet y verifica si la calidad de salida realmente cambia. A menudo, no cambia. Más allá de la selección de modelos por agente, nuestra guía de optimización de costos de LLM API en 12 formas cubre prompt caching, procesamiento por lotes y patrones de caché semántica que se combinan a través de toda tu flota de agentes.
Depuración y monitoreo de sistemas multi-agente
El problema de la topología de trace
Una sola solicitud de usuario puede disparar: agente A (clasificar) —agente B (investigación) + agente C (código) en paralelo —agente A (sintetizar) —seis llamadas al LLM, diez llamadas de herramientas, tres mensajes entre agentes. Una lista plana de 19 spans es imposible de depurar. No puedes ver el grafo de ejecución.
La solución: kind de span AGENT de OpenInference con modelado jerárquico. Span raíz: sesión de usuario. Nivel 1: decisión del orquestador. Nivel 2: ejecución por agente. Nivel 3: llamadas de herramientas por agente. Tu visor de traces renderiza el grafo de ejecución, no una lista plana. Cuando falla la llamada de herramienta del agente C, lo ves en contexto —qué agente, qué paso, qué ocurrió antes y después.
Consulta nuestra guía de observabilidad para la configuración completa de OpenTelemetry.
Modos de falla comunes en multi-agente
Bucle infinito de mensajes. Agente A —agente B —agente A —agente B. Prevención: límite de profundidad de conversación y detección de bucles a nivel del bus de mensajes. En la capa de API, los límites de tasa por agente agregan un tope de presupuesto —cuando un agente excede su cuota de solicitudes, el bucle se detiene sin importar lo que permita la lógica del bus de mensajes.
Salidas contradictorias. El agente A dice reembolso. El agente B dice sin reembolso. No hay mecanismo de resolución. Prevención: patrón de supervisor con resolución explícita de conflictos, o mecanismo de votación entre agentes.
Fuga de permisos de herramientas. El agente de código obtiene accidentalmente acceso a la herramienta de reembolso del agente de facturación a través de un registro de herramientas mal configurado. Prevención: listas de permitidos de herramientas por agente. Identidad del agente en cada rastro de auditoría de herramientas.
Falla silenciosa del agente. Un agente lanza un error no manejado. El orquestador no lo nota. El usuario recibe una respuesta parcial a la que le falta información crítica. Prevención: reporte de errores estructurado en el protocolo entre agentes. Verificaciones de salud a nivel del orquestador antes de la síntesis.
FAQ
¿Cuándo NO debo usar arquitectura multi-agente?
Si un solo agente bien prompteado con 10 o menos herramientas bien definidas maneja tu tarea, no introduzcas la complejidad multi-agente. El costo de comunicación, la dificultad de depuración y el costo de los mensajes entre agentes superan los beneficios. Agente individual primero. Multi-agente solo cuando el agente individual falle de forma demostrable —confusión de herramientas, inconsistencia de roles, o latencia serial que la ejecución paralela arreglaría.
¿Con cuántos agentes debe empezar mi sistema?
De dos a tres, cubriendo roles claramente distintos. No empieces con seis. La complejidad de coordinación escala de forma no lineal —un sistema de 6 agentes no es 3× más difícil que uno de 2. Está más cerca de 9×. Agrega agentes solo cuando un agente existente muestre fallas consistentes en una subtarea específica que requiere experiencia distinta.
¿Con qué patrón de orquestación debo empezar?
Supervisor-Worker. Control centralizado, gestión de estado clara, depuración más simple. Pasa a Peer-to-Peer solo cuando los workers realmente necesiten negociación dinámica entre sí. Pasa a Hierarchical solo cuando tengas niveles de complejidad claros con confidence thresholds medibles. Empieza simple. Agrega complejidad solo cuando los datos demuestren que la necesitas.
¿Cómo manejo un agente que comete errores de forma consistente?
No empieces ajustando su prompt. Primero: análisis de trace. Encuentra el patrón de falla —¿qué entradas disparan el error? ¿Qué paso de su ejecución sale mal? Segundo: acota el alcance del agente. Puede estar manejando demasiados tipos de tarea. Tercero: agrega un agente de control de calidad —un revisor que verifica las salidas antes de que lleguen al usuario. Cuarto: si al agente le falta conocimiento del dominio, agrega RAG —no fine-tuning, no más prompting.
¿Cuál es el costo operativo real de un sistema de 5 agentes que corre en 3 niveles de modelos?
El costo operativo no son los tokens —es la fragmentación. Cada nivel de agentes potencialmente toca un proveedor distinto. Eso significa API keys separadas, seguimiento de límites de tasa separado, dashboards de costos separados. Cuando tu agente clasificador (DeepSeek Flash a $0.14/M) y tu revisor de código (Claude Opus a $15/M) corren a través de proveedores distintos, pasas más tiempo gestionando credenciales que optimizando el comportamiento de los agentes. La solución es arquitectónica: un solo endpoint para todos los agentes sin importar el modelo. La atribución de costos por agente se convierte en un atributo del span, no en un ejercicio de hojas de cálculo entre proveedores. Para la observabilidad y el ajuste de latencia que hacen que este enfoque de endpoint único esté listo para producción, la guía de optimización de producción de TokSpan cubre connection pooling, colas de solicitudes y configuración de timeouts por modelo a través de toda tu flota de agentes.
La arquitectura multi-agente no es más sofisticada —es una respuesta a modos de falla específicos. Cuando tu agente individual confunde herramientas entre dominios, cuando la ejecución serial hace la latencia inaceptable, cuando la autoevaluación no puede detectar sus propios errores —esas son las señales. No antes.
Empieza con Supervisor-Worker. Mapea roles a modelos sin piedad —tu clasificador no necesita Opus. Instrumenta los spans de cada agente con agent_id. Observa el reporte de costos por agente durante una semana. Encontrarás al menos un agente que está sobre-modelado y puede bajar un nivel sin impacto en calidad.
El patrón de orquestación importa menos que la disciplina de saber cuándo no agregar otro agente.
El reporte de costos de tu flota de agentes no debería requerir unir exportaciones CSV de cuatro dashboards de proveedores distintos. Despliega tus agentes en TokSpan —atribución de costos por agente, límites de tasa centralizados y cada modelo que tus agentes necesitan detrás de un solo endpoint.