Para ejecutar agentes de programación en paralelo, proporcione a cada agente su propio git worktree y rama, alimente a los agentes desde una cola de planes previamente revisados por un humano, ejecute pruebas y linters dentro de cada worktree antes de que nadie lea el diff, y registre con precisión el coste de cada plan. La mayoría de los equipos alcanzan esta arquitectura pasando por tres patrones previos: un único agente en una ventana de chat, un agente por rama iniciado manualmente y una cola con procesos de trabajo (workers). Cada patrón resuelve un problema puntual y deja al descubierto el siguiente. Esta guía analiza los cuatro patrones, qué falla en cada escalón y las seis responsabilidades indispensables que un orquestador debe asumir.

Los cuatro patrones

Los "8 niveles de desarrollo asistido por IA" de Steve Yegge (2025) constituyen un marco de referencia muy útil. El bucle iterativo fundamental —razonar sobre un paso, actuar, observar el resultado, repetir— es el formalizado en Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, y cada patrón que veremos a continuación representa una respuesta diferente a quién supervisa dicho bucle. Al momento de escribir este artículo, la mayoría de los equipos se encuentran en los niveles 2 y 3: un desarrollador da instrucciones a un agente, revisa el resultado y hace commit. La orquestación con agentes paralelos, memoria persistente y filtros de revisión corresponde al nivel 8.

Patrón 1: Un único agente en una ventana de chat

Un desarrollador abre un terminal o un panel en su IDE, describe una tarea y observa cómo el agente edita archivos directamente en el directorio de trabajo. El rendimiento se limita a una tarea por desarrollador a la vez, dado que el agente y el ingeniero comparten el mismo checkout. Si se inicia una segunda tarea antes de concluir la primera, ambas modificaciones se mezclarán en el mismo árbol de directorios y el diff resultante perderá todo sentido.

Patrón 2: Un agente por rama, iniciado de forma manual

El siguiente paso consiste en asignar a cada tarea su propia rama y su propio checkout. Git worktrees permiten lograr esto de manera eficiente: un único almacén de objetos compartido y múltiples directorios de trabajo aislados.

# Desde el checkout principal:
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."

Un desarrollador ahora puede ejecutar dos o tres agentes simultáneamente, cada uno en su propio directorio. Lo que se quiebra aquí es el control administrativo: nadie documenta qué worktree corresponde a qué tarea, y los prompts quedan sepultados en el historial del terminal. Además, si dos agentes modifican los mismos archivos, los conflictos de fusión solo se descubrirán al momento de intentar el merge.

Patrón 3: Una cola con agentes worker en worktrees aislados

Cuando un equipo intenta operar más de un puñado de agentes, el paso de inicio manual se convierte en el eslabón más lento. La solución natural es una cola: las tareas se encolan, procesos worker las recogen, crean un worktree, ejecutan el agente, publican la rama y abren un pull request. Marcos de investigación multi-agente como AutoGen formalizan este mismo esquema de workers y colas.

Sin embargo, apartar al humano del inicio de cada tarea provoca la aparición de un nuevo fallo sistémico. Nada valida la tarea antes de que el agente comience a trabajar, por lo que tareas mal planteadas consumen costosos tokens en pull requests que nadie desea fusionar. Nada valida el código antes de abrir el pull request, por lo que los revisores humanos se transforman en el cuello de botella. Y como la cola opera sin supervisión activa, los costes se acumulan de manera descontrolada.

Patrón 4: Ciclo de vida del plan con puntos de control humanos

El último patrón introduce dos puntos de control humanos y una fase de verificación automatizada. Toda tarea se convierte en un plan escrito. Un humano lee y valida el plan antes de que se escriba una sola línea de código. Los agentes se ejecutan en worktrees estrictamente aislados. Las pruebas unitarias, linters y el resumen del diff se ejecutan dentro del worktree —aplicando el mismo principio de la integración continua, pero por agente en lugar de por desarrollador. Un humano revisa el diff final. Solo entonces se procede a abrir el pull request.

Ivy denomina a este patrón una "fábrica de software" (software factory): un flujo de trabajo predecible y estandarizado en el que cada cambio transita por las mismas etapas y supera exactamente las dos mismas aprobaciones humanas. Consulte Qué es una fábrica de software para obtener la definición completa.

Qué falla en cada escalón

Patrón	Qué problema soluciona	Qué falla a continuación
Agente individual en chat	Nada aún; representa la línea base	Solo una tarea por desarrollador; directorio compartido
Un agente por rama, manual	Tareas concurrentes sin colisiones de carpetas	Pérdida de contexto, prompts no registrados, conflictos tardíos
Cola desatendida con workers	Elimina el inicio manual de tareas	Tareas y salidas sin revisar, descontrol de costes
Ciclo de vida del plan con checkpoints	Evita código inútil y cambios no verificados	Requiere herramientas que gestionen cola, aislamiento, verificación, costes y memoria

Las seis responsabilidades indispensables de un orquestador

Un orquestador es la pieza de software encargada de ejecutar de forma fiable el patrón 4. Debe asumir seis responsabilidades críticas; si alguna de ellas falta, terminará realizándose de forma manual y volverá a convertirse en el cuello de botella del equipo:

Gestión de cola (Queue): Los planes aguardan en un orden predeterminado con estados transparentes: borrador (draft), aprobado (approved), en ejecución (executing), en verificación (verifying), en revisión (in review), fusionado (merged). El estado debe ser visible sin necesidad de abrir un terminal.
Aislamiento (Isolation): Cada plan en ejecución recibe su propio worktree y rama dedicados. La rama principal jamás recibe escrituras directas de un agente. Git worktrees para agentes de IA en paralelo detalla por qué los worktrees superan a los directorios compartidos y a los contenedores.
Verificación automatizada (Verification): Pruebas, análisis estático (lint), comprobación de tipos e inspección de diff se ejecutan dentro del worktree tras la ejecución del agente y antes de que un humano intervenga. Los fallos se devuelven al agente junto con el registro detallado del error.
Revisión humana (Review): Exactamente dos puntos de control —el plan y el diff—, cada uno con acciones explícitas para aprobar o rechazar. Rechazar a nivel de plan no consume tokens de codificación. Rechazar a nivel de diff solo cuesta una ejecución.
Contabilidad de costes (Cost accounting): Registro exhaustivo de tokens y dólares por plan y por tarea, permitiendo conocer con exactitud cuánto costó cada cambio fusionado y cuánto se invirtió en planes descartados.
Memoria contextual (Memory): Los aprendizajes adquiridos por un agente en un plan deben estar disponibles para los siguientes; de lo contrario, cada tarea parte desde cero y repite los mismos fallos del pasado.

Cómo implementa esto Ivy Tendril

Ivy Tendril es una aplicación de escritorio local-first (macOS, Windows y Linux) diseñada para operar el patrón 4 con cualquier agente de programación basado en CLI. También cuenta con modo desatendido mediante tendril --web.

Cola: La vista de Plans centraliza cada plan con su estado de ciclo de vida. Las secciones Drafts, Icebox y Recommendations organizan el trabajo pendiente de aprobación. Los planes pueden crearse automáticamente desde incidencias de GitHub y reportes de jam.dev vía webhooks, o mediante el servidor MCP, la API REST y la CLI.
Aislamiento: Al comenzar la ejecución, Tendril crea un git worktree y una rama dedicados para ese plan específico. Múltiples planes pueden ejecutarse concurrentemente en paralelo. Tras la fusión, Tendril elimina el worktree automáticamente. Ver Git worktrees para agentes de IA en paralelo.
Verificación: La aplicación de Review organiza las pruebas, el lint y el diff en pestañas claras para cada plan. En los planes Pro es posible importar resultados de verificación directamente desde el sistema de CI.
Revisión: En el control del plan, el revisor puede aplicar Expand, Split o Update sobre el borrador, o añadir comentarios inline para que el plan se reescriba. El control del diff se presenta tras la verificación. Nada genera un pull request sin ambas aprobaciones.
Contabilidad de costes: Los tokens y el gasto se auditan por plan y por trabajo, disponiendo de un Dashboard con indicadores KPI y gráficas de tendencias de costes.
Memoria: Cada etapa del ciclo de vida está gobernada por una unidad de promptware compuesta por un archivo Program.md con instrucciones iterables, un directorio Memory/ con conocimientos acumulados del repositorio, Tools/ con permisos acotados y registros de auditoría Logs/. Incluye unidades nativas como CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr y CreateIssue. Ver promptware.

Tendril es agnóstico respecto a los agentes. Admite Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode y cualquier otro agente de línea de comandos, permitiendo alternar de agente o modelo según el plan. El código fuente permanece en la máquina del desarrollador; las únicas comunicaciones externas son hacia la API del LLM configurado y hacia GitHub.

El equipo de ingeniería de Ivy informa que pasó de promediar unas 10 a más de 100 pull requests diarias tras la adopción de este flujo de trabajo.

Cómo empezar

Instale Tendril: ejecute curl -sSf https://cdn.ivy.app/install-tendril.sh | sh en macOS o Linux, o irm https://cdn.ivy.app/install-tendril.ps1 | iex en Windows. Guía completa en instalación.
Abra un repositorio local en la aplicación e introduzca la clave API del proveedor de modelos de su preferencia.
Genere un plan a partir de un ticket existente, revise el borrador, inicie la ejecución y examine el diff resultante en la interfaz de Review.
En cuanto se fusione su primer plan, cree tres planes simultáneamente y observe cómo se ejecutan en paralelo.

Tendril es gratuito y con código disponible bajo la Functional Source License; las funciones de trabajo en equipo, soporte para SSO, despliegue local on-premise y sincronización de verificación en CI forman parte de los planes Pro (59 USD por usuario al mes) y Enterprise.

Preguntas frecuentes

¿Son necesarios los contenedores para ejecutar agentes en paralelo?

No. Los git worktrees dotan a cada agente de su propio directorio de trabajo y rama compartiendo el almacén de objetos. Los contenedores añaden aislamiento en tiempo de ejecución, lo cual solo es imprescindible si los agentes instalan paquetes del sistema o abren puertos; la gran mayoría de tareas de desarrollo no lo precisan.

¿Cuántos agentes pueden ejecutarse simultáneamente?

El límite práctico suele ser la tasa de peticiones (rate limits) de la API del modelo y la potencia del equipo para compilar y ejecutar suites de pruebas, no el orquestador. Recomendamos comenzar con 3 a 5 planes concurrentes e incrementar la cifra mientras la verificación se complete con agilidad.

¿Qué sucede cuando dos planes modifican el mismo archivo?

El segundo plan que intente fusionarse generará un conflicto en su rama. La forma correcta de prevenirlo es en la fase de planificación: divida o establezca una secuencia para aquellos planes que afecten a los mismos módulos antes de ejecutarlos, que es justamente para lo que existe la acción Split en Tendril.

Primeros pasos con Ivy Tendril

¿Listo para la orquestación paralela de agentes a nivel de desarrollador?

Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.

Patrones de orquestación de agentes: cómo ejecutar agentes de código en paralelo