# Orquestación de agentes: quién decide qué hace cada agente

> La orquestación de agentes define quién planifica, quién ejecuta y cómo se reparte y se revisa el trabajo entre varios agentes de IA. Guía para diseñadores.

*Tags: ia, agentes, orquestacion, multi-agente*

---


> [!info] Definición Rápida
> La **orquestación de agentes** es el diseño de cómo varios agentes de IA se reparten el trabajo: quién planifica, quién ejecuta cada parte, qué información comparte cada uno y quién revisa el resultado final. Un sistema orquestado tiene una lógica explícita de coordinación; un grupo de agentes sin ella solo tiene varias ventanas abiertas.


## ¿Qué es orquestar agentes?

Un [[que-es-un-agente-de-ia|agente de IA]] es un modelo que puede usar herramientas y actuar en varios pasos. Cuando una tarea es grande, con partes que se pueden separar, una sola conversación se llena rápido: el contexto crece, el modelo olvida detalles y cada cambio se mezcla con los anteriores.

Orquestar es poner un nivel de coordinación encima. Alguien (una persona o un agente principal) decide:

- qué subtareas existen,
- qué agente o herramienta resuelve cada una,
- qué información recibe cada agente,
- cómo se juntan los resultados,
- y quién confirma que el resultado sirve.

La idea es vieja en software. Lo nuevo es que los trabajadores son modelos que leen instrucciones en lenguaje natural, así que el diseño de la orquestación se parece más a escribir un brief bien hecho que a programar un flujo rígido.

## ¿Por qué le importa a un diseñador?

Porque la orquestación define la experiencia del que supervisa. Si el orquestador devuelve un resumen confuso, la persona no sabe qué revisar. Si cada agente trabaja en silencio durante veinte minutos, la persona pierde la noción de avance. Si dos agentes tocan la misma pantalla, aparecen conflictos que nadie vio venir.

Hay tres decisiones de diseño que cambian la experiencia:

1. **Visibilidad**: qué ve la persona de lo que hace cada agente (estado, plan, cambios propuestos).
2. **Puntos de control**: en qué momentos el sistema se detiene y pide una decisión humana.
3. **Formato de entrega**: cómo vuelve el resultado de cada trabajador, para que el orquestador pueda juntarlo sin adivinar.

## ¿Qué patrones existen?

En la práctica aparecen tres configuraciones:

| Patrón | Quién tiene el control | Cuándo funciona |
|---|---|---|
| **Orquestador y trabajadores** | Un agente principal reparte y junta | Tareas separables, como investigar varias fuentes en paralelo |
| **Cadena o pipeline** | Cada agente pasa su resultado al siguiente | Pasos con orden fijo: redactar, revisar, traducir |
| **Par o mesa de revisión** | Dos agentes se revisan entre sí | Tareas donde un error cuesta caro y una segunda lectura ayuda |

Anthropic describe la función de investigación de Claude (Research) con un agente principal que planifica y lanza subagentes en paralelo, cada uno con su propia ventana de contexto. Los subagentes devuelven hallazgos y el principal decide si hace falta otra ronda. Un agente de citas revisa al final de dónde sale cada afirmación. En su evaluación interna, un sistema con Claude Opus 4 como principal y subagentes Claude Sonnet 4 superó en 90,2 % a Claude Opus 4 trabajando solo; el precio fue el consumo de tokens que se menciona más abajo.

El OpenAI Agents SDK distingue dos formas de delegar. Con un **handoff**, el control pasa al especialista, que toma la conversación y responde al usuario. Con **agente como herramienta**, el agente principal conserva el control, llama al especialista como si fuera una función y se queda con la respuesta final. La elección cambia quién habla con el usuario al final, y por tanto qué tono y qué reglas aplican.

## ¿Cómo se le explica la tarea a cada trabajador?

Un trabajador solo conoce lo que el orquestador le escribe. Anthropic cuenta que, cuando las instrucciones a los subagentes eran vagas, dos de ellos repetían la misma búsqueda o dejaban huecos sin cubrir. Un buen encargo incluye cuatro cosas:

1. **Objetivo concreto**: qué pregunta debe responder, no un tema general.
2. **Formato de entrega**: lista corta, tabla o JSON, con los campos que el principal va a necesitar.
3. **Herramientas y fuentes**: dónde buscar y qué no tocar.
4. **Límites**: cuánto esfuerzo dedicar y cuándo parar, para que no investigue sin fin.

Si lo piensas como diseñador, es un brief con alcance y criterio de aceptación. Un encargo vago produce resultados que no encajan entre sí.

## ¿Cuándo NO conviene orquestar?

- Cuando la tarea es secuencial y cada paso depende del anterior. Anthropic señala que la mayoría de las tareas de programación tienen pocas partes realmente paralelas, y que los agentes que deben compartir el mismo contexto funcionan mal separados.
- Cuando el valor de la tarea no justifica el costo. Más agentes significan más tokens, más tiempo y más revisión.
- Cuando no sabes revisar el resultado. Un orquestador que entrega diez piezas que nadie lee es peor que un agente que entrega una.

Regla práctica: empieza con un agente, mide dónde se atora y separa solo esa parte. Si el cuello de botella es que no entiendes lo que hizo el agente, otro agente no lo arregla: necesitas mejor visibilidad y más puntos de control.

## Ejemplo

Ejemplo ilustrativo: quieres rediseñar la página de precios de un producto. Un agente principal lee el brief, y tres trabajadores revisan en paralelo la competencia, los textos actuales y los datos de conversión. Cada uno devuelve una lista corta con fuentes. El principal junta, descarta lo repetido y te entrega un solo documento con tres decisiones a aprobar. Tú apruebas antes de que cualquier agente toque la página.

Un caso real del sitio que muestra una orquestación con tickets y dos agentes está en el artículo del blog [Hice que Claude Opus 4.8 gestionara a otro agente de IA mientras yo trabajaba](/blog/es/claude-opencode-two-agent-workflow/). Según su descripción, es un flujo basado en tickets en el que Claude orquesta a OpenCode y que mantiene la revisión, la visibilidad y el control humano mientras reduce el desperdicio de tokens.

Para ordenar el trabajo en paralelo, lee [[git-worktrees-para-agentes|git worktrees para agentes]] y [[subagentes|subagentes]]. Para lo que pasa entre un agente y otro, revisa [[handoffs-entre-agentes|handoffs entre agentes]]. Para ver los patrones con más detalle, están [[orquestador-trabajador|orquestador-trabajador]] y [[patrones-multi-agente|patrones multi-agente]].

## Errores comunes

- Orquestar antes de tener una tarea clara. Si el brief es vago, el orquestador reparte mal.
- Dar a todos los trabajadores el mismo contexto completo. Gasta tokens y mezcla decisiones.
- No definir el formato de entrega. Cada trabajador responde distinto y el principal pierde tiempo interpretando.
- Dejar que el orquestador apruebe su propio trabajo. La revisión debe tener un ojo distinto, humano o de otro agente con criterios escritos.
- Medir la calidad por la cantidad de agentes activos. Lo que importa es el resultado revisado.

## Fuentes

- [How we built our multi-agent research system (Anthropic Engineering)](https://www.anthropic.com/engineering/multi-agent-research-system)
- [Subagents en Claude Code (documentación)](https://code.claude.com/docs/en/sub-agents)
- [Handoffs, OpenAI Agents SDK (documentación)](https://openai.github.io/openai-agents-python/handoffs/)
- [Agent orchestration, OpenAI Agents SDK para JavaScript (handoffs frente a agentes como herramienta)](https://openai.github.io/openai-agents-js/guides/multi-agent)


---

Source: https://www.fernandoux.com/es/wiki/ia/orquestacion-de-agentes/