Sistemas multiagente: orquestador + subagentes en la práctica
Un solo agente de IA resuelve bien una tarea acotada. Cuando el escenario crece - tickets, documentos, código, CRM, soporte - un agente «universal» empieza a mezclar roles, inflar el contexto y encarecerse en cada paso. Un sistema multiagente lo resuelve de otra forma: un orquestador toma el objetivo y coordina el trabajo, mientras los subagentes ejecutan roles estrechos con herramientas e instrucciones propias. A continuación - cómo funciona en la práctica, cuándo compensa el patrón y qué errores matan un piloto.
- Orquestador - plan, enrutado, control de límites y ensamblado del resultado
- Subagentes - roles estrechos: investigación, código, revisión, redacción, CRM
- Contexto - cada agente recibe solo lo que necesita para su paso
- Control - human-in-the-loop en acciones críticas
- Inicio - 2-4 roles y un escenario medible, no un «zoológico de agentes»
- Riesgo - bucles infinitos, carreras de herramientas y responsabilidades borrosas
Qué es un sistema multiagente
Un sistema multiagente (multi-agent system) es una arquitectura en la que varios agentes de IA resuelven juntos una tarea bajo un coordinador. A diferencia de un solo agente con un prompt «gordo» para todos los casos, los roles están separados:
| Rol | Qué hace | Qué no hace |
|---|---|---|
| Orquestador | Entiende el objetivo, descompone, llama a subagentes, ensambla la respuesta | No toca tools ajenas sin necesidad |
| Subagente | Ejecuta una subtarea estrecha con sus propias herramientas | No replantea todo el proyecto |
| Humano | Aprueba riesgos: dinero, borrado, publicación, correos a clientes | No debe micromanagear cada tool-call |
La misma idea ya es familiar en la automatización de workflows: hay un despachador y ejecutores. La diferencia es que los pasos y ramificaciones los elige en parte un LLM, no solo reglas if-then rígidas.
Por qué separar orquestador y subagentes
Un agente con acceso a todas las API parece cómodo - y rápido se convierte en un problema:
- El contexto se infla. En un mismo diálogo se mezclan logs, borradores de emails, trozos de código y exportaciones del CRM - el modelo pierde el foco.
- El coste crece. Cada token de más en el chat «compartido» se paga en cada turno.
- Los permisos son demasiado amplios. Un agente que escribe código y también escribe al cliente es más arriesgado que un ejecutor estrecho.
- Es más difícil depurar. Cuando todo vive en un solo bucle, no queda claro qué se rompió: el plan, la tool o la redacción.
La separación de roles aporta:
- Un system prompt estrecho por subagente - menos alucinaciones «fuera de rol».
- Un juego de tools separado - un investigador no puede borrar por accidente un deal en el CRM.
- Paralelismo - varios subagentes pueden trabajar a la vez (búsqueda + borrador + contrastación de hechos).
- Observabilidad - en los logs se ve quién se llamó, con qué entrada y con qué salida.
Diseño base: orquestador + pool de subagentes
Un esqueleto mínimo práctico:
Usuario / trigger
│
▼
Orquestador
(plan, rutas, límites)
│
┌────┼────┬────────┐
▼ ▼ ▼ ▼
Research Coder Reviewer Writer
│ │ │ │
└────┴────┴────────┘
│
▼
Resumen + artefactos
(+ human approval ante riesgo)
Qué hace el orquestador
- acepta el objetivo y las restricciones (tiempo, presupuesto de tokens, prohibiciones);
- elige qué subagentes llamar y en qué orden;
- pasa a cada uno un brief comprimido, no el chat crudo completo;
- aplica límites de pasos y detiene bucles;
- ensambla el resultado en el formato que necesita el negocio (informe, diff, ficha de deal).
El orquestador puede ser «fino» (solo enrutado) o «grueso» (planifica y replantea él mismo). Para negocio suele ganar un orquestador fino + subagentes estrechos fuertes: más fácil de testear y más barato de mantener bajo control.
Subagentes típicos en escenarios de negocio y desarrollo
| Subagente | Tarea | Herramientas (ejemplo) |
|---|---|---|
| Research | Recopilar hechos, docs, competidores | búsqueda, RAG, navegador, MCP |
| Analyst | Tablas, métricas, conclusiones | SQL, Excel/Sheets, almacén de informes |
| Coder | Parches, scripts, tests | repo, terminal, CI |
| Reviewer | Control de calidad y riesgos | linters, checklists, diff |
| Writer | Emails, specs, release notes, FAQ | plantillas, base de tono de marca |
| CRM-agent | Fichas, tareas, estado | API del CRM, webhooks |
| Ops | Deploy, alertas, runbooks rutinarios | SSH/API, monitorización (con guardrails duros) |
No hace falta crear todos los roles el primer día. En un piloto suele bastar un orquestador + 2-3 subagentes.
Cuándo el patrón realmente compensa
El diseño multiagente tiene sentido cuando se cumplen al menos dos de estos puntos:
- la tarea es compuesta (varios skills: búsqueda + síntesis + acción);
- se necesitan distintos derechos de acceso a los sistemas;
- el volumen de contexto es grande - un solo agente «no cabe» sin perder calidad;
- hace falta un revisor aparte, no la autoevaluación del autor;
- el escenario se repite y se puede describir como un pipeline por roles.
Ejemplos prácticos
- Soporte: orquestador → Research (base de conocimiento/RAG) → Writer (respuesta) → el humano aprueba el envío.
- Leads y CRM: cualificación → enrichment → escritura en el CRM → tarea al manager; campos críticos los revisa un humano o una regla.
- Desarrollo: orquestador en Cursor / agent runtime → subagente explore → coder → reviewer; deploy solo tras approve.
- Contenido y GEO: research del tema → writer → subagente de fact-check → publicación con checklist.
- Operaciones: parseo de email entrante → clasificación → acciones vía n8n/API → escalado de excepciones a un humano.
Si la tarea es un if-then simple («llegó el formulario → crear deal»), los multiagentes son excesivos: mejor automatización nativa o n8n.
Cómo diseñar roles en un día
Una checklist pragmática corta:
- Describe el happy path en papel: entrada → 3-6 pasos → artefacto de salida.
- Nombra los roles con verbos: «encontrar», «comprobar», «escribir», «registrar en CRM» - no «agente listo nº3».
- Para cada rol, fija: entrada, salida (esquema/JSON), tools, prohibiciones.
- Decide quién orquesta: planificador LLM o grafo determinista (a menudo un híbrido: grafo + LLM dentro de los nodos).
- Inserta human-in-the-loop donde el coste del error sea alto.
- Define condiciones de stop: máx. pasos, máx. coste, timeout, «si no estás seguro - escalar».
Un contrato de subagente gana a un «prompt bonito»
Un buen contrato:
- entrada:
{ task, constraints, sources[] } - salida:
{ status, summary, artifacts[], confidence, needs_human } - prohibición: «no inventes URLs», «no toques prod», «no escribas al cliente directamente»
Así el orquestador puede fusionar respuestas con fiabilidad y decidir a quién llamar después.
Patrones de orquestación que funcionan
| Patrón | Cómo funciona | Cuándo usarlo |
|---|---|---|
| Pipeline secuencial | A → B → C | Proceso estable, pocas ramificaciones |
| Despachador | El orquestador elige 1 subagente por tipo de petición | Muchos tipos de petición entrante |
| Paralelo + merge | Varios research a la vez, luego un resumen | Hechos de varias fuentes |
| Debate / reviewer | Autor y crítico | Calidad de texto, código, decisiones |
| Jerarquía | Orquestador → team leads → workers | Programas grandes con subproyectos |
Para una pyme suele bastar pipeline + despachador. Los «debates entre agentes» quedan bien en demos y salen caros en producción sin un presupuesto duro de tokens.
Control, seguridad y coste
Un sistema multiagente sin guardrails se convierte rápido en un bot caótico y caro.
Mínimo imprescindible:
- API keys y permisos separados por rol (least privilege).
- Límites: pasos, tokens, paralelismo, timeouts.
- Acciones idempotentes (un reintento no debe crear 5 deals).
- Audit log: quién → con qué entrada → qué tool → qué salida.
- Secretos fuera del prompt: vault, env - no «pega el token en el system message».
- Human approval para acciones irreversibles: pagos, borrado, mailings, deploy a prod.
En coste, no cuentes solo el «precio del modelo», sino el precio de la cadena: orquestador × N llamadas a subagentes × reintentos. A veces una llamada fuerte con buen contexto sale más barata que cinco débiles que se pasan JSON de un lado a otro.
Errores frecuentes de implementación
- Crear 10 subagentes «para luego» sin un escenario que funcione.
- Dar a todos el mismo acceso a todas las tools.
- Pasar al subagente el log completo del orquestador en lugar de un brief corto.
- No limitar bucles - orquestador y reviewer discuten para siempre.
- Tratar el diseño multiagente como sustituto del proceso: sin un Definition of Done claro, el sistema imita actividad.
- Confundirlo con vibe coding: «que los agentes se apañen» sin roles ni contratos - camino a la deuda técnica.
Cómo arrancar un piloto de 2-3 semanas
- Elige un escenario con un KPI medible (tiempo de respuesta, tasa de error, minutos del manager).
- Monta orquestador + dos subagentes (p. ej. research + writer, o coder + reviewer).
- Congela los contratos de entrada/salida y un checklist de escalado a humanos.
- Ejecuta 20-50 casos reales y etiqueta los fallos por tipo.
- Solo entonces añade un tercer rol o paralelismo.
El tooling puede ser un framework de agentes (LangGraph, esquemas tipo Crew, runtime en IDE), un puente a n8n para los bordes deterministas, o un custom en Python. La arquitectura de roles importa más que el logo del framework.
Conclusión
Orquestador + subagentes es un patrón que funciona cuando la tarea supera un solo skill y necesitas derechos, contextos y controles de calidad distintos. La fuerza no está en el número de agentes - está en roles claros, tools estrechas y stops duros. Empieza con un circuito pequeño y un escenario medible: así un sistema multiagente se convierte en un palanca de velocidad, no en un teatro caro de autonomía.
Preguntas frecuentes
¿En qué se diferencia un sistema multiagente de un solo agente con un prompt largo?
Un agente con prompt largo intenta ser «todo a la vez» en un solo contexto y un solo juego de permisos. Un diseño multiagente separa roles: el orquestador coordina, los subagentes ejecutan de forma estrecha. Eso es más fácil de controlar, más barato en tokens en cadenas largas y más seguro porque cada ejecutor tiene menos superficie de acceso.
¿Siempre hace falta un orquestador LLM?
No. A menudo es mejor un grafo determinista (máquina de estados / workflow), con el LLM dentro de los nodos. Un orquestador LLM compensa cuando la entrada no está estructurada y la ruta no se puede fijar de antemano. El híbrido es la opción más habitual en producción.
¿Cuántos subagentes son óptimos al inicio?
Normalmente 2-4. Un orquestador más research y writer ya es un circuito útil para contenido y soporte; coder y reviewer - para desarrollo. Más roles solo tienen sentido cuando el piloto cumple el KPI de forma estable y los logs son legibles.
¿Cómo evitar quemar dinero en tokens?
Comprime briefs, prohíbe «recontar todo el diálogo», cachea el system prompt estable, limita el máx. de pasos, paraleliza solo donde reduzca el wall-time - no por lucimiento. Mide el coste del escenario de punta a punta, no de una respuesta bonita en la demo.
¿Hace falta un humano en el bucle si los agentes son «listos»?
Sí, en los riesgos. Un modelo no elimina la responsabilidad sobre dinero, datos personales, redacción legal y producción. Human-in-the-loop no es una debilidad de la arquitectura - es la condición bajo la cual el negocio permite acercar agentes a sistemas reales.