¿Qué es la orquestación de agentes de IA para programar?

Es la capa que coordina varios agentes de programación en una misma tarea: algo divide el trabajo, los agentes comparten estado mediante valores devueltos, una lista de tareas o mensajes, y sus cambios se combinan con un merge o una revisión en lugar de chocar en una carpeta.

¿Con qué patrón de orquestación empiezo?

Empieza con orquestador y workers, como los subagentes de Claude Code, para investigar y revisar dentro de una sesión. Pasa al reparto en git worktrees cuando varios agentes deban escribir código a la vez, y añade al final un paso de merge con los tests.

¿Los equipos de agentes de Claude Code están listos para producción?

A octubre de 2026 son experimentales y vienen desactivados. Se activan con el ajuste CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, y la documentación cita límites como que no se pueden reanudar sesiones de compañeros en proceso o que solo hay un equipo por sesión.

¿Cómo evito que dos agentes editen el mismo archivo?

Da a cada agente que escribe su propio git worktree y rama, divide el trabajo por carpetas e integra las ramas de una en una, con los tests sobre el resultado combinado. Las reglas de propiedad de archivos también pueden rechazar ediciones fuera de las rutas de cada agente.

Orquestación de agentes de IA para programar: 5 patrones

Q: ¿Por qué la orquestación multiagente cuesta mucho más?

Cada agente tiene su propia ventana de contexto y vuelve a leer el código que necesita. Los mensajes de coordinación suman tokens. La documentación de Anthropic dice que los equipos de agentes gastan bastantes más tokens que una sesión, así que mantén equipos pequeños y limita el gasto por agente.

La orquestación de agentes de IA para programar es la forma de poner a varios agentes de código a trabajar en una misma tarea sin que se pisen. Cualquier montaje responde a tres preguntas: quién divide el trabajo (tú, un agente líder o un planificador), cómo comparten estado los agentes (resultados que vuelven a quien los llamó, una lista de tareas compartida o mensajes directos) y cómo se juntan sus cambios (en un solo contexto, con un git merge o con una revisión). Cuando eliges esas tres cosas ya has elegido tu patrón; la herramienta va después.

Este artículo recorre los cinco patrones de orquestación que importan para agentes de programación, lo que sale mal en cada uno y qué herramientas los implementan a octubre de 2026: subagentes y equipos de agentes de Claude Code, Codex cloud, Conductor, Claude Squad, Vibe Kanban y AgentVera. AgentVera publica este blog, así que también decimos dónde encajan mejor las demás. Los datos de terceros se comprobaron en la documentación o el repositorio de cada herramienta.

Si buscas una comparativa de herramientas, lee las mejores herramientas para agentes de programación en paralelo. Aquí hablamos de la arquitectura que hay debajo.

Las tres decisiones detrás de cada montaje

Antes de ver patrones conviene poner nombre a las piezas:

Descomposición: quién convierte «añadir facturación» en tareas. Una persona que divide a mano es lenta pero predecible; un agente planificador es rápido, pero puede cortar por donde no toca.
Estado compartido: cómo se entera el agente B de lo que hizo el agente A. De más estricto a más laxo: un valor devuelto a quien llama, una lista de tareas compartida con dependencias y mensajes libres entre agentes.
Integración: cómo aterriza el código. El trabajo de solo lectura devuelve texto. Los agentes que escriben o comparten una carpeta (arriesgado) o trabajan en git worktrees separados cuyas ramas se fusionan después.

Casi todos los errores de orquestación vienen de dejar una de estas tres cosas implícita; por ejemplo, dos agentes que creen que el archivo del router es suyo.

Cinco patrones de orquestación

1. Orquestador y workers

Un agente mantiene la conversación y manda encargos concretos a los workers. Cada worker empieza con un contexto limpio, hace una sola cosa y devuelve un resumen. El que llama nunca ve la transcripción completa del worker, solo su resultado.

Bueno para: investigar, buscar en el código, revisar, analizar tests. Cualquier cosa en la que el worker lee mucho e informa poco.
Flojo en: escribir en paralelo. Los workers suelen editar la misma copia de trabajo que quien los llama.
Ejemplo: los subagentes de Claude Code.

2. Líder y compañeros con lista de tareas compartida

Un agente líder crea tareas con dependencias; los compañeros las reclaman, las terminan y se escriben entre sí. El estado vive en la lista de tareas y no en la cabeza de un agente, así que un compañero puede coger una tarea que quedó desbloqueada hace un minuto.

Bueno para: trabajo que cambia sobre la marcha, cuando un tester tiene que devolver un bug al desarrollador sin que tú hagas de intermediario.
Flojo en: coste y seguridad de archivos. Compañeros que comparten carpeta pueden sobrescribirse.
Ejemplo: los equipos de agentes de Claude Code; la mensajería entre agentes y la lista de tareas de AgentVera.

3. Reparto en worktrees y luego merge

Un planificador divide un cambio en partes independientes. Cada parte corre en su propio worktree y rama, y las ramas terminadas se fusionan de una en una en una rama de integración, con los tests al final.

Bueno para: cambios grandes con partes separables: API, interfaz, migración.
Flojo en: partes que dependen entre sí sin que se note. El conflicto aparece al fusionar, no al editar.
Ejemplo: Conductor, Claude Squad y Vibe Kanban te dan los worktrees; el equipo paralelo de AgentVera añade el planificador y el merge. Más contexto en git worktrees para agentes en paralelo.

4. Relevos en cadena

El planificador pasa el trabajo al implementador y el implementador al revisor. Cada paso recibe la salida del anterior y nada más. Es el montaje planificador-implementador-revisor que casi todo el mundo prueba primero.

Bueno para: trabajos repetibles en los que quieres leer el plan antes de que se escriba código.
Flojo en: velocidad. Nada corre en paralelo y un relevo vago estropea todos los pasos siguientes.
Ejemplo: lo tratamos a fondo en flujos de trabajo con agentes de IA y equipos de agentes de IA.

5. Best-of-N

La misma tarea va a varios intentos y tú, o un agente revisor, os quedáis con el mejor. No hay coordinación alguna, y de eso se trata.

Bueno para: bugs difíciles y trabajo de interfaz poco definido, donde la primera respuesta rara vez es la mejor.
Flojo en: coste, más o menos N veces los tokens, y tiempo de revisión.
Ejemplo: codex cloud exec --attempts, o dos CLI distintas con el mismo prompt en worktrees separados.

Los patrones, uno al lado del otro

Patrón	Quién divide	Estado compartido	Cómo aterriza el código	Riesgo principal
Orquestador y workers	El agente que llama	Resultados devueltos a quien llama	La copia de quien llama	Workers editando sus archivos
Líder y lista de tareas	Agente líder	Lista de tareas y mensajes	Normalmente una carpeta	Sobrescrituras, coste en tokens
Reparto y merge	Planificador o tú	Plan escrito de antemano	Ramas fusionadas con una comprobación	Conflictos tardíos
Cadena de relevos	Tú, al diseñarla	La salida del paso anterior	La rama del último paso	Lentitud, relevos vagos
Best-of-N	Nadie	Ninguno	Eliges un diff	N veces el coste

Qué sale mal y cómo arreglarlo

Conflictos

Dos agentes en una carpeta acabarán editando el mismo archivo. Las soluciones se apilan: un worktree por agente que escribe, una división por carpetas en vez de por funcionalidades, propiedad de archivos explícita y fusionar las ramas de una en una sobre la punta más reciente, para que el segundo merge vea el primero. Una cola de merge es ese último paso bien hecho.

Coste

Cada agente vuelve a leer el código que necesita y cada mensaje entre agentes son más tokens. La documentación de Anthropic dice que los equipos de agentes gastan bastantes más tokens que una sola sesión y recomienda empezar con 3 a 5 compañeros. Mantén pocos agentes, da a los workers un modelo más barato donde la documentación lo permita y pon un tope por agente para que un bucle no se coma el presupuesto del día.

Deriva y bucles

Un agente puede desviarse del plan, repetir el mismo comando fallido durante veinte minutos, o dos agentes pueden preguntarse lo mismo una y otra vez. Criterios de aceptación claros por tarea, una señal explícita de «terminado» o «atascado», límites de mensajes y un vigilante que detecte comandos repetidos atrapan casi todo.

Confianza entre agentes

Si los agentes pueden escribirse, un mensaje de otro agente no es un mensaje tuyo. Trátalo como información, no como permiso: un agente no debería borrar una rama ni hacer push a main porque otro se lo pida.

Las herramientas, según el patrón

Subagentes de Claude Code (orquestador y workers)

Los subagentes son archivos Markdown con frontmatter YAML en .claude/agents/ (proyecto) o ~/.claude/agents/ (usuario). Cada uno corre en su propia ventana de contexto y devuelve el resultado a quien lo llamó; su uso cuenta para los mismos límites. Puedes restringirlos con tools o disallowedTools y elegir model. A octubre de 2026, los subagentes pueden lanzar sus propios subagentes hasta tres niveles de profundidad por defecto, algo que controla CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (ponlo a 1 para desactivar el anidamiento).

---
name: test-triager
description: Ejecuta los tests que fallan e informa de la causa raíz. Úsalo tras una ejecución de CI en rojo.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Ejecuta los tests que fallan, encuentra el primer error real e informa de archivo, línea y causa en menos de 15 líneas. No edites archivos.

Equipos de agentes de Claude Code (líder y lista de tareas)

Los equipos de agentes son experimentales y vienen desactivados a octubre de 2026. Una sesión hace de líder; cada compañero es una instancia propia de Claude Code con su propio contexto. Comparten una lista de tareas con estados pendiente, en curso y completada, más dependencias, reclaman tareas por su cuenta y se escriben directamente. Se activa en settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Por defecto los compañeros se muestran en el mismo proceso, o en paneles divididos con tmux o iTerm2. La documentación enumera límites reales: no se pueden reanudar sesiones de compañeros en proceso, el estado de las tareas puede ir con retraso, solo hay un equipo por sesión, no hay equipos anidados y el líder es fijo. También avisa de que dos compañeros editando el mismo archivo acaban sobrescribiéndose, así que reparte por archivos. Los hooks TeammateIdle, TaskCreated y TaskCompleted te dejan imponer reglas; el código de salida 2 bloquea la acción.

Codex cloud (reparto y best-of-N, en remoto)

Codex cloud ejecuta tareas en un entorno en la nube que configuras tú, cada una en su propio espacio de trabajo, y sigue trabajando mientras tu portátil duerme. Revisas el diff, pides ajustes y luego abres un PR o lo aplicas en local. El comando codex cloud está marcado como experimental a octubre de 2026:

codex cloud exec --env ENV_ID --attempts 3 "Arregla el test de fechas inestable de billing/"
codex cloud list --env ENV_ID
codex apply TASK_ID   # aplica el diff en local; sale con código distinto de 0 si git apply falla

--attempts acepta de 1 a 4 y es el best-of-N más sencillo que hay. Codex cloud es mejor opción cuando quieres sacar el trabajo de tu máquina; solo ejecuta Codex.

Conductor (reparto, Mac)

Conductor ejecuta Claude Code, Codex, Cursor y OpenCode en paralelo, cada tarea en su propio espacio de trabajo con su rama, terminal y diff, y después revisión, PR, merge y archivo. Solo funciona en Mac. Planes a octubre de 2026: Free, Pro por 50 $ al mes y Teams por 60 $ por usuario al mes. Si todo tu equipo usa macOS y quieres una interfaz de reparto pulida, es una opción sólida.

Claude Squad (reparto, terminal)

Claude Squad es una interfaz de terminal que ejecuta Claude Code, Codex, Gemini, Aider, OpenCode o Amp en worktrees separados dentro de tmux. Tiene licencia AGPL-3.0 y necesita tmux y la CLI de GitHub; en Windows funciona dentro de WSL.

brew install claude-squad
cs              # Claude Code por defecto
cs -p "codex"   # otro agente

n abre una sesión, Enter se conecta, Ctrl-q se desconecta y s hace commit y push. Si vives en la terminal, es la opción más ligera.

Vibe Kanban (reparto, tablero)

Vibe Kanban convierte las tareas en tarjetas y cada tarjeta recibe un espacio de trabajo con su rama, terminal y servidor de desarrollo; los comentarios en el diff vuelven al agente y este puede abrir PR. Soporta Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode, Droid, CCR y Qwen Code. Su README dice ahora que el proyecto se está cerrando, así que a octubre de 2026 tómalo como mantenido por la comunidad (Apache-2.0, npx vibe-kanban).

AgentVera (los cinco, en local)

AgentVera es una app de escritorio para macOS, Windows y Linux que ejecuta muchas CLI de programación una al lado de otra, así que puede alojar cada patrón en lugar de uno solo:

Orquestador y workers: con los agentes que abren agentes (activado por defecto), un agente lanza ayudantes con las herramientas spawn_agent, wait_agent, agent_status, message_agent y stop_agent. Un ayudante puede ser cualquier CLI instalada, puede trabajar en su propio worktree en una rama oto/… y aparece debajo de su agente padre. Por defecto cada agente puede abrir 3 ayudantes y pueden correr 6 en total; los ayudantes no pueden abrir agentes propios.
Líder y lista de tareas: la mensajería entre agentes da a cada agente send_message, reply_message, wait_reply y una lista de tareas compartida (task_add con responsable y dependencias, task_claim, task_done, task_release). Cuando terminan las dependencias de una tarea, esta queda lista y se avisa a su responsable. Funciona entre CLI distintas, así que Claude Code puede pasarle una tarea a Codex.
Reparto y merge: un equipo paralelo (planes Pro y Team) divide un trabajo en hasta 8 partes, cada una con criterios de aceptación y archivos previstos, las ejecuta en sus propios worktrees, 3 a la vez por defecto y 6 como máximo, y las fusiona en una rama de integración. La comprobación es el comando de tests del proyecto; un agente de integración arregla conflictos y fallos, y el equipo se detiene si la comprobación sigue en rojo tras dos rondas de arreglos.
Protecciones para cada fallo: la propiedad de archivos rechaza con un hook las ediciones de Claude Code fuera de las rutas de su dueño; la cola de merge fusiona una rama cada vez sobre la punta más reciente; los presupuestos de tokens (desactivados por defecto) limitan un agente por turno y por día; y el supervisor marca al agente que repite el mismo comando 5 veces en 15 minutos, recibe el mismo error 3 turnos seguidos o pasa 20 minutos sin cambiar un archivo.

Estas funciones son solo locales: los ayudantes abiertos por agentes y la mensajería no cubren agentes por SSH. Si quieres que las tareas sigan en la nube con el portátil cerrado, Codex cloud encaja mejor.

Cómo elegir patrón

¿El trabajo es sobre todo de lectura? Orquestador y workers. Con subagentes basta.
¿Varios agentes tienen que escribir código a la vez? Reparto en worktrees con un paso de merge. No compartas carpeta.
¿Las tareas cambian según aprendes? Un líder con lista de tareas compartida, con 3 a 5 agentes.
¿Ejecutas el mismo trabajo cada semana? Una cadena de relevos con aprobación antes del paso de código.
¿El problema es difícil y la respuesta incierta? Best-of-N, sabiendo lo que cuesta.

Luego elige la herramienta por plataforma: Conductor solo en Mac, Claude Squad si quieres terminal, Codex cloud si el trabajo debe correr en remoto y AgentVera si quieres varias CLI y patrones en una app de escritorio en cualquier sistema operativo.

Una orquestación pequeña para probar hoy

El reparto útil más pequeño solo necesita git y dos CLI:

git worktree add ../app-api -b feat/api
git worktree add ../app-ui -b feat/ui
(cd ../app-api && claude "Añade el endpoint /invoices. Toca solo src/api/.")
(cd ../app-ui && codex "Construye la página de facturas según el contrato de /invoices. Toca solo src/ui/.")
git checkout -b integrate/invoices
git merge feat/api && npm test
git merge feat/ui && npm test

Las reglas que lo hacen funcionar están en los prompts: una carpeta por agente, un contrato acordado entre ellos y una pasada de tests tras cada merge. Todo lo que añade una herramienta encima (planificación, listas de tareas, un supervisor, una cola) automatiza una de esas líneas. En agentes de programación en paralelo vamos más allá con Claude Code y Codex lado a lado.

Para terminar

La orquestación de agentes de IA para programar tiene menos que ver con la herramienta que con tres decisiones: quién divide el trabajo, dónde vive el estado compartido y cómo aterriza el código. Orquestador y workers sirve para leer, una lista de tareas para trabajo cambiante, el reparto con merge para cambios grandes y separables, las cadenas de relevos para trabajos repetibles y best-of-N para los difíciles. Elijas lo que elijas, pon protecciones contra conflictos, coste y deriva desde el primer día.

Si quieres probar varios patrones en un mismo sitio, descarga AgentVera y empieza con dos agentes y una lista de tareas compartida antes de activar un equipo paralelo.