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:

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:

1. Un system prompt estrecho por subagente - menos alucinaciones «fuera de rol».
2. Un juego de tools separado - un investigador no puede borrar por accidente un deal en el CRM.
3. Paralelismo - varios subagentes pueden trabajar a la vez (búsqueda + borrador + contrastación de hechos).
4. 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

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

1. Soporte: orquestador → Research (base de conocimiento/RAG) → Writer (respuesta) → el humano aprueba el envío.
2. Leads y CRM: cualificación → enrichment → escritura en el CRM → tarea al manager; campos críticos los revisa un humano o una regla.
3. Desarrollo: orquestador en Cursor / agent runtime → subagente explore → coder → reviewer; deploy solo tras approve.
4. Contenido y GEO: research del tema → writer → subagente de fact-check → publicación con checklist.
5. 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.

Cuándo un sistema multiagente no encaja

• El proceso es lineal y predecible, sin ramificaciones reales - una automatización simple (n8n, un workflow estándar) es más barata y fiable.
• El volumen es bajo y el coste del error es bajo - el trabajo manual o un solo agente bastan sin el sobrecoste de orquestar.
• En el equipo nadie puede mantener un audit log ni revisar los fallos - sin eso, un sistema multiagente se convierte en una caja negra sin control.
• No hay presupuesto ni voluntad de limitar pasos y tokens - la cadena de llamadas puede acabar costando más que el trabajo manual que sustituye.
• Necesitas un SLA duro y predecible ahora mismo - el enrutado por LLM añade variabilidad justo donde hace falta estabilidad garantizada.

Cómo diseñar roles en un día

Una checklist pragmática corta:

1. Describe el happy path en papel: entrada → 3-6 pasos → artefacto de salida.
2. Nombra los roles con verbos: «encontrar», «comprobar», «escribir», «registrar en CRM» - no «agente listo nº3».
3. Para cada rol, fija: entrada, salida (esquema/JSON), tools, prohibiciones.
4. Decide quién orquesta: planificador LLM o grafo determinista (a menudo un híbrido: grafo + LLM dentro de los nodos).
5. Inserta human-in-the-loop donde el coste del error sea alto.
6. 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

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

1. Elige un escenario con un KPI medible (tiempo de respuesta, tasa de error, minutos del manager).
2. Monta orquestador + dos subagentes (p. ej. research + writer, o coder + reviewer).
3. Congela los contratos de entrada/salida y un checklist de escalado a humanos.
4. Ejecuta 20-50 casos reales y etiqueta los fallos por tipo.
5. 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.

Si necesita ayuda con el desarrollo, la implementación de IA o el soporte del sitio para su proyecto - escríbame.

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.

Términos del artículo

CRM — Customer Relationship Management — gestión de relaciones con clientes

human-in-the-loop — human approval before risky agent actions — aprobación humana antes de acciones riesgosas del agente

if-then — conditional if → then rule

LLM — Large Language Model — modelo de lenguaje grande

system prompt — hidden instructions that steer the model for a task — instrucciones ocultas que guían el comportamiento del modelo

RAG — Retrieval-Augmented Generation — generación aumentada por recuperación

MCP — Model Context Protocol — protocolo de contexto del modelo

webhooks — HTTP callbacks when events happen — llamadas HTTP cuando ocurren eventos

pipeline — sequence of processing stages

GEO — Generative Engine Optimization — optimización para respuestas de buscadores generativos

n8n — open-source workflow automation platform — plataforma open-source de automatización de workflows

audit log — chronologically recorded trail of who did what — registro de quién hizo qué y cuándo

happy path — main success scenario without errors or edge cases — escenario principal de éxito sin errores ni casos borde

SLA — Service Level Agreement — acuerdo de nivel de servicio

timeout — max wait before aborting

guardrails — rules and filters that keep AI outputs safe and on-policy — reglas y filtros que mantienen las salidas de IA seguras y a norma

API keys — secret tokens that authenticate API callers — tokens secretos que autentican llamadas a la API

definition of done — checklist that marks work complete

KPI — Key Performance Indicator — indicador clave de rendimiento