Un solo agente de IA puede responder preguntas, clasificar tickets o redactar correos electrónicos. Pero cuando la tarea requiere coordinar múltiples capacidades especializadas —investigación, análisis, escritura, ejecución de código y supervisión humana— un solo agente alcanza sus límites rápidamente. Ahí es donde entran en juego los sistemas multiagente.
Este post explica cómo diseñamos sistemas multiagente de producción: los patrones de orquestación, la selección de modelos para cada rol, un ejemplo de código real y por qué construimos soluciones a medida en lugar de utilizar frameworks comerciales.
¿Por qué múltiples agentes en lugar de uno solo?
La idea central es la misma que hace que los equipos de ingeniería sean efectivos: la especialización supera al generalismo a escala.
Un solo "mega-prompt" que intente manejar la investigación, el análisis, la escritura, la verificación de hechos y el formato:
- Alcanzará los límites de la ventana de contexto rápidamente a medida que se introduzcan más instrucciones y definiciones de herramientas.
- Producirá una calidad inconsistente porque el modelo está haciendo malabarismos con demasiados objetivos.
- Será imposible de depurar: cuando el resultado sea incorrecto, no se podrá saber qué "fase" falló.
- Costará más, porque cada tarea se ejecuta a través del modelo más capaz (y más caro), incluso cuando un modelo más simple sería suficiente.
Un sistema multiagente divide el trabajo en roles especializados. Cada agente tiene un prompt enfocado, un conjunto limitado de herramientas y un modelo elegido para ajustarse a la complejidad de su tarea. Un orquestador coordina el flujo de trabajo, pasando los resultados de un agente como entradas para el siguiente.
Arquitectura: Orquestador y Trabajadores
Nuestra arquitectura multiagente estándar sigue un patrón de orquestador-trabajador:
El Orquestador
El orquestador es el "gestor de proyectos" del sistema. Recibe la solicitud inicial, la divide en subtareas, asigna cada subtarea al agente trabajador adecuado, recopila los resultados, gestiona los errores y reintentos, y ensambla el resultado final.
Elección del modelo: Claude Opus 4.6. El orquestador necesita capacidades sólidas de razonamiento, planificación y gestión de errores. Toma decisiones críticas: ¿debe reintentarse, reasignarse o escalarse una subtarea fallida? ¿Es necesario reformatear el resultado del Trabajador A antes de que el Trabajador B pueda usarlo? Estas decisiones requieren el modelo más capaz disponible. El coste está justificado porque el orquestador procesa muchos menos tokens que los trabajadores (se encarga de resúmenes y decisiones de enrutamiento, no de contenido bruto).
Agentes Trabajadores
Cada agente trabajador maneja un tipo de tarea. Ejemplos de un flujo real de generación de contenido:
| Trabajador | Rol | Modelo | Por qué este modelo |
|---|---|---|---|
| Investigador | Busca en bases de conocimientos, extrae datos relevantes, resume fuentes | Claude Sonnet 4.6 | Necesita buena comprensión y uso de herramientas; no necesita razonamiento nivel Opus |
| Escritor | Produce borradores a partir de resúmenes de investigación y esquemas | Claude Sonnet 4.6 | Calidad de escritura sólida a un coste menor que Opus |
| Verificador de hechos | Verifica afirmaciones contra documentos fuente, señala declaraciones sin respaldo | Claude Sonnet 4.6 | Necesita una comprensión de lectura cuidadosa; Sonnet maneja esto bien |
| Formateador | Aplica guías de marca, corrige markdown, genera metadatos | Claude Haiku 4.5 | Transformaciones simples basadas en reglas; Haiku es 60 veces más barato que Opus |
| Clasificador | Enruta solicitudes entrantes, etiqueta contenido, prioriza tareas | Claude Haiku 4.5 | Rápido, barato y preciso para tareas de clasificación |
Por qué importa la selección del modelo
Usar el modelo adecuado para cada rol no se trata solo de ahorrar dinero (aunque eso importa). Se trata de la fiabilidad. Haiku responde en 200-400 ms; Opus puede tardar de 5 a 15 segundos para razonamientos complejos. Si su agente clasificador usa Opus, cada solicitud entrante espera 10 segundos para una tarea que Haiku podría resolver en 300 milisegundos. En un sistema que procesa miles de solicitudes al día, esa latencia se acumula en una experiencia de usuario terrible y en un desperdicio de cómputo.
Comparación de costes para 100.000 tareas al mes:
- Todo Opus: aproximadamente 1.200 $ en costes de API.
- Modelos mixtos (orquestador Opus, trabajadores Sonnet, Haiku para tareas simples): aproximadamente 180 $ en costes de API.
- Eso es una reducción de costes del 85 % sin pérdida en la calidad del resultado, porque cada modelo se ajusta a la complejidad que realmente necesita manejar.
El bucle de latido (Heartbeat Loop): Manteniendo vivos a los agentes
En producción, los agentes pueden detenerse: una llamada a la API agota el tiempo de espera, un trabajador devuelve un resultado mal formado o una subtarea tarda más de lo esperado. Un bucle de latido (heartbeat loop) garantiza que el orquestador esté al tanto del estado de cada trabajador y pueda intervenir cuando algo sale mal.
Aquí hay una versión simplificada del patrón que utilizamos:
import asyncio
import time
from dataclasses import dataclass, field
@dataclass
class WorkerStatus:
worker_id: str
last_heartbeat: float = field(default_factory=time.time)
status: str = "idle" # idle, working, stalled, failed
current_task: str = ""
retries: int = 0
class Orchestrator:
def __init__(self, max_retries=3, heartbeat_timeout=30):
self.workers: dict[str, WorkerStatus] = {}
self.max_retries = max_retries
self.heartbeat_timeout = heartbeat_timeout
async def heartbeat_loop(self):
"""Continuously monitors worker health."""
while True:
now = time.time()
for worker_id, status in self.workers.items():
if status.status == "working":
elapsed = now - status.last_heartbeat
if elapsed > self.heartbeat_timeout:
if status.retries < self.max_retries:
status.retries += 1
status.status = "working"
status.last_heartbeat = now
await self.retry_task(
worker_id, status.current_task
)
else:
status.status = "failed"
await self.escalate(
worker_id, status.current_task
)
await asyncio.sleep(5)
async def retry_task(self, worker_id, task):
"""Re-dispatches a stalled task to the same or different worker."""
print(f"Retrying {task} on {worker_id} "
f"(attempt {self.workers[worker_id].retries})")
# Re-dispatch logic here
async def escalate(self, worker_id, task):
"""Escalates a persistently failing task for human review."""
print(f"Escalating {task} from {worker_id} - "
f"max retries exceeded")
# Send alert to Slack, email, or monitoring dashboard
Los elementos clave:
- Detección de tiempo de espera: Si un trabajador no ha enviado un "latido" en 30 segundos, se asume que se ha detenido.
- Reintentos automáticos: Reintenta hasta 3 veces antes de rendirse. Cada reintento reinicia el temporizador de latido.
- Escalamiento: Después del máximo de reintentos, se alerta a un humano en lugar de fallar silenciosamente. En producción, esto envía un mensaje de Slack con los detalles de la tarea y el contexto del fallo.
- No bloqueante: El bucle de latido se ejecuta de forma asíncrona junto con el flujo de trabajo principal, por lo que la monitorización no ralentiza la ejecución de las tareas.
Por qué construimos a medida (no CrewAI, AutoGen o LangGraph)
Existen frameworks de código abierto populares para sistemas multiagente. Los evaluamos todos exhaustivamente y decidimos construir una orquestación a medida para despliegues de producción. He aquí por qué:
CrewAI
Fortalezas: API limpia, buena para prototipos, abstracción agradable de "crews" (equipos) y "tasks" (tareas). Limitaciones: Muy rígido en cuanto a los patrones de comunicación entre agentes. Control limitado sobre la lógica de reintento, la gestión de errores y el enrutamiento de modelos. Añade una capa de dependencia que oculta qué prompts se están enviando realmente. La monitorización en producción requiere añadir herramientas externas. Cuando algo se rompe a las 3 AM, necesitas depurar a través de las abstracciones de CrewAI antes de poder ver las llamadas reales a la API.
AutoGen (Microsoft)
Fortalezas: Patrones conversacionales sólidos, buen respaldo de investigación. Limitaciones: Configuración pesada, diseñada principalmente para escenarios de investigación. El paradigma de "conversación entre agentes" funciona de maravilla en demostraciones, pero se vuelve difícil de controlar en producción, donde se necesitan flujos de trabajo deterministas con presupuestos de error y requisitos de latencia estrictos.
LangGraph
Fortalezas: Definición de flujo de trabajo basada en grafos, buena gestión de estados, se integra con el ecosistema LangChain. Limitaciones: Estrechamente acoplado a LangChain, lo que añade una complejidad significativa y capas de abstracción. La rotación de versiones es alta: los cambios que rompen la compatibilidad entre lanzamientos son comunes. La abstracción de grafos es potente pero está sobrediseñada para muchos flujos de trabajo del mundo real que son fundamentalmente secuenciales con ramificaciones condicionales.
Por qué lo "a medida" gana en producción
Nuestra capa de orquestación personalizada tiene aproximadamente 800 líneas de Python. Maneja:
- Enrutamiento dinámico de modelos por agente basado en la complejidad de la tarea.
- Lógica de reintento estructurada con retroceso exponencial (exponential backoff) e interruptores automáticos (circuit breakers).
- Seguimiento del presupuesto de tokens y asignación de costes por agente.
- Monitorización de latidos con escalamiento a Slack.
- Registro estructurado que captura cada prompt, respuesta y decisión para depuración y evaluación.
- Degradación gradual: si Opus no está disponible, el orquestador puede recurrir a Sonnet con prompts ajustados.
Los frameworks añaden más de 10.000 líneas de código de dependencia para lograr una funcionalidad similar, pero con menos control sobre los detalles que más importan en producción: gestión de errores, control de costes y observabilidad. Cuando el flujo de trabajo de un cliente falla a escala, necesitamos ver exactamente qué sucedió a nivel de API, no navegar a través de las abstracciones de un framework.
Dicho esto, si estás creando un prototipo o construyendo una herramienta interna donde los requisitos de fiabilidad son menores, CrewAI o LangGraph pueden ahorrarte tiempo al empezar. El enfoque personalizado vale la pena cuando necesitas fiabilidad de grado de producción y control de costes.
El SDK de Agentes de Anthropic: un nuevo punto medio
Desde que construimos originalmente nuestra orquestación personalizada, Anthropic ha lanzado el Agent SDK, un framework de Python específicamente para construir agentes impulsados por Claude con gestión de herramientas integrada, salvaguardas y orquestación multiagente. Ocupa un punto medio útil entre los frameworks pesados mencionados anteriormente y una construcción totalmente personalizada. El Agent SDK es firme donde importa (seguridad, ejecución de herramientas, transferencias entre agentes) pero minimalista donde no, dándote más control que CrewAI y requiriendo menos código repetitivo que construir desde cero. Para nuevos proyectos, ahora lo evaluamos junto con nuestra orquestación personalizada.
Otro desarrollo digno de mención: el Model Context Protocol (MCP) se ha convertido en el estándar de la industria para conectar agentes con herramientas externas y fuentes de datos. Con el respaldo de la Linux Foundation y el apoyo de Anthropic, OpenAI, Google, Microsoft y AWS, el MCP proporciona una interfaz universal que cualquier agente —ya sea en un sistema multiagente o independiente— puede usar para descubrir e invocar herramientas. Esto es particularmente valioso en arquitecturas multiagente donde diferentes agentes trabajadores necesitan acceso a diferentes conjuntos de herramientas.
El SDK de Agentes de Anthropic: un nuevo punto medio
Desde que construimos originalmente nuestra orquestación personalizada, Anthropic ha lanzado el Agent SDK, un framework de Python específicamente para construir agentes impulsados por Claude con gestión de herramientas integrada, salvaguardas y orquestación multiagente. Ocupa un punto medio útil entre los frameworks pesados mencionados anteriormente y una construcción totalmente personalizada. El Agent SDK es firme donde importa (seguridad, ejecución de herramientas, transferencias entre agentes) pero minimalista donde no, dándote más control que CrewAI y requiriendo menos código repetitivo que construir desde cero. Para nuevos proyectos, ahora lo evaluamos junto con nuestra orquestación personalizada.
Otro desarrollo digno de mención: el Model Context Protocol (MCP) se ha convertido en el estándar de la industria para conectar agentes con herramientas externas y fuentes de datos. Con el respaldo de la Linux Foundation y el apoyo de Anthropic, OpenAI, Google, Microsoft y AWS, el MCP proporciona una interfaz universal que cualquier agente —ya sea en un sistema multiagente o independiente— puede usar para descubrir e invocar herramientas. Esto es particularmente valioso en arquitecturas multiagente donde diferentes agentes trabajadores necesitan acceso a diferentes conjuntos de herramientas.
Resultados en Producción
Aquí hay métricas reales de sistemas multiagente que hemos desplegado:
Pipeline de Producción de Contenido (Cliente de Medios)
- Arquitectura: Orquestador + 4 trabajadores (investigador, escritor, verificador de hechos, formateador).
- Volumen: 120 artículos por semana, cada uno de 1.500 a 3.000 palabras.
- Calidad: 94 % de los artículos publicados con cero ediciones humanas. El 6 % restante necesitó ajustes menores, no reescrituras.
- Coste por artículo: 0,42 $ en costes de API (promedio entre todos los agentes y modelos).
- Tiempo por artículo: 4,2 minutos de media desde el briefing hasta el borrador final, comparado con las 3-4 horas de un redactor humano.
- Rol humano: Revisión editorial y dirección estratégica. El equipo pasó de "producir contenido" a "dirigir la estrategia de contenido".
Sistema de Triaje de Soporte (Cliente SaaS)
- Arquitectura: Orquestador + 3 trabajadores (clasificador, resolutor, redactor de escalamiento).
- Volumen: 4.200 tickets al mes.
- Tasa de autoresolución: 67 % (frente al 12 % con su sistema anterior basado en reglas).
- Tiempo medio de resolución: 22 segundos para tickets autoresueltos.
- Coste: 320 $ al mes en costes de API para todo el sistema.
- Tasa de falsos positivos: 1,2 % (tickets autoresueltos incorrectamente que requirieron seguimiento humano).
Pipeline de Análisis de Datos (Cliente Fintech)
- Arquitectura: Orquestador + 3 trabajadores (redactor de consultas, analista, formateador de informes).
- Volumen: 45 informes por semana en 6 departamentos.
- Precisión: 99,1 % en resultados numéricos (validado contra cálculos manuales).
- Ahorro de tiempo: 28 horas de analista por semana liberadas para trabajo estratégico.
- Coste: 89 $ al mes en costes de API.
Cuándo usar un sistema multiagente
No todas las tareas de IA necesitan múltiples agentes. Use una arquitectura multiagente cuando:
- El flujo de trabajo tiene fases distintas que se benefician de diferentes prompts, herramientas o modelos.
- La calidad requiere controles y equilibrios: un agente escritor y un agente verificador de hechos producen mejores resultados que un solo agente intentando hacer ambas cosas.
- La escala exige optimización de costes: enrutar tareas simples a modelos baratos mientras se reservan los modelos caros para razonamientos complejos.
- La fiabilidad es crítica: la lógica de reintento, la monitorización de latidos y la degradación gradual son más fáciles de implementar cuando cada agente es una unidad aislada.
Para casos de uso más simples —una sola tarea de clasificación, un bot de preguntas y respuestas directo, una transformación de datos de un solo paso— un solo agente es más sencillo, más barato e igual de efectivo.
Para aprender más sobre cómo funcionan los agentes de IA autónomos individuales antes de escalar a sistemas multiagente, comience con esa base. Y si está listo para explorar lo que un sistema multiagente podría hacer por su flujo de trabajo específico, nuestro servicio de agentes de IA cubre todo el proceso, desde el diseño hasta el despliegue.
