# Merge queue para agentes de IA: mantén main en verde

URL: https://agentvera.dev/es/blog/merge-queue-for-ai-agents/ · Publicado: 2026-10-18

Por qué las ramas de agentes de IA en paralelo rompen main aunque cada una pase, qué es un merge queue y cómo AgentVera fusiona, comprueba y aterriza ramas en orden.

**En resumen:**

- Ramas que pasan sus propios tests pueden romper main juntas, porque cada una se probó contra una base más antigua.
- El merge queue de AgentVera fusiona cada rama sobre la punta actual de la rama destino en su propio worktree y ejecuta una comprobación sobre el resultado.
- Un conflicto abre un agente resolutor y una comprobación fallida recibe como máximo dos rondas de arreglo; por defecto, una rama que pasa espera tu aprobación para aterrizar.

Un merge queue para agentes de IA es la forma más fiable de mantener main en verde en cuanto ejecutas más de un agente a la vez. Con un solo agente no hay drama: trabaja en una rama, la miras, la fusionas. Pero cuando tres o cuatro agentes empiezan a terminar trabajo en sus propias ramas, la cosa cambia. Cada rama pasa por separado, las fusionas una tras otra y main queda en rojo.

Este artículo explica por qué las ramas de agentes en paralelo rompen main, cómo lo arregla un merge queue y cómo funciona paso a paso el merge queue de AgentVera.

## Verde por separado, rojo en conjunto

Empecemos con un ejemplo. Main tiene una función `formatPrice(amount)`. Ejecutas dos agentes a la vez:

- **El agente A** añade un parámetro de moneda: `formatPrice(amount, currency)`, y actualiza todos los puntos de llamada.
- **El agente B** construye una pantalla de facturas nueva que llama a `formatPrice(amount)`.

Ambas ramas partieron del mismo main. Los tests de A pasan, porque en el mundo de A la pantalla de facturas no existe. Los tests de B pasan, porque en el mundo de B la función aún recibe un argumento. Git tampoco ve conflicto: las dos ramas tocaron archivos distintos.

Fusionas A y luego B. Git no dice nada. Pero ahora main llama a una función de dos parámetros con un argumento, y la comprobación de tipos falla.

Este es un conflicto semántico: no hay conflicto textual, pero los cambios se rompen entre sí. Los agentes en paralelo lo hacen más común porque:

- **Los agentes no se ven entre sí.** Cada uno trabaja en su propio worktree y no sabe qué hacen los demás.
- **Las ramas se acumulan rápido.** A media tarde pueden esperar cinco o seis ramas.
- **Cada rama se probó sobre una base antigua.** Cuanto más espera una rama, más rancia es su base.
- **Fusionar en orden a mano es tedioso.** Tras cada merge actualizas la siguiente rama, vuelves a ejecutar los tests y arreglas conflictos. La gente empieza a saltárselo.

## ¿Qué es un merge queue?

Un merge queue pone en cola las ramas que esperan aterrizar y fusiona cada una sobre la punta actual de la rama destino, y luego prueba ese resultado. La idea es simple: antes de que una rama aterrice, prueba cómo será realmente main después de aterrizar.

Comparación con fusionar a mano:

| | Fusionar a mano | Merge queue |
| --- | --- | --- |
| Sobre qué corre el test | La base propia de la rama | Punta actual de main + la rama |
| Conflictos semánticos | Se descubren después de llegar a main | Se detectan antes de aterrizar |
| Orden | Quien pulse primero | Orden de la cola |
| Una rama rota | Rompe main | Se rechaza, main sigue limpio |

GitHub también tiene un merge queue a nivel de repositorio que pone en cola pull requests y los prueba junto con la última versión de la rama destino. La cola de AgentVera aplica la misma idea en tu escritorio, para las ramas de tus agentes, y añade agentes que resuelven conflictos de merge y arreglan comprobaciones fallidas por el camino.

## Cómo funciona el merge queue de AgentVera

La cola vive en la app de escritorio, en **Details → Automation → Merge queue**. Cada proyecto tiene una cola; en un proyecto multi-repo, cada repo tiene su propia cola y ajustes. Las ramas aterrizan de una en una.

### 1. Una rama entra en la cola

Hay tres formas de entrar:

- **A mano:** escribe el nombre de la rama en el campo **Branch**, opcionalmente dale un **Title** y pulsa **Add to queue**.
- **Desde un equipo en paralelo:** cuando un equipo en paralelo termina, pulsa **Queue** para enviar su rama de integración.
- **Desde una automatización:** elige **Add to the merge queue** como entrega de una regla de automatización, y la rama del agente terminado entra directamente en la cola.

Las tarjetas de la bandeja Review también ofrecen **Send to the merge queue**. Cada elemento muestra de dónde viene: manual, equipo en paralelo o automatización.

### 2. Se fusiona sobre la punta actual del destino

Cuando le toca el turno, la rama se fusiona sobre la punta actual del destino en el worktree separado propio de la cola. Tu carpeta de trabajo y las carpetas de tus agentes no se tocan. Si el repo tiene un remoto, primero se hace fetch del destino y el merge se hace sobre la última versión de `origin`.

Eliges la estrategia en los ajustes: **Merge commit** o **Squash**. Si la rama ya está contenida en el destino, el elemento se marca como aterrizado.

### 3. Un conflicto recibe un agente

Si el merge entra en conflicto, la cola no se detiene. Abre un agente resolutor y el elemento pasa a «resolving conflicts». Al agente se le indica que conserve la intención de ambos lados, que no deje marcadores de conflicto y que haga commit del resultado.

Cuando el agente termina, AgentVera no se fía solo de su palabra. Comprueba si quedan archivos sin fusionar, busca marcadores `<<<<<<<` y `>>>>>>>` y confirma que la rama está realmente fusionada. Si algo de eso falla, el elemento falla y no aterriza.

Con el modelo automático activado, el modelo del resolutor se elige según la dificultad del trabajo.

### 4. La comprobación corre sobre el resultado fusionado

Cuando el resultado fusionado está listo, la cola ejecuta un comando de comprobación. Deja **Check** vacío y usará el comando de test del proyecto, o escribe el tuyo, como `pnpm typecheck && pnpm test`.

Si la comprobación falla, el agente resolutor recibe el final de la salida e intenta arreglarlo. Hay como máximo dos rondas de arreglo. Si la comprobación sigue en rojo, el elemento se **rechaza** y la cola sigue adelante. La rama rota nunca llega a main.

Eso es exactamente lo que pasa en el ejemplo de `formatPrice`: la rama de B se fusiona sobre un main que ya tiene A, la comprobación de tipos falla, el resolutor actualiza la llamada de la pantalla de facturas a la nueva firma y la comprobación se pone en verde.

### 5. Aprobación y aterrizaje

Una rama que pasa queda lista. Por defecto **Land passing branches automatically** está desactivado, así que el elemento espera como «ready, awaiting approval» y recibes una notificación. Échale un vistazo y pulsa **Land** cuando estés conforme.

El aterrizaje funciona así:

- **Con un remoto,** el resultado fusionado se envía con push a la rama destino. Los repos de GitHub usan el inicio de sesión de GitHub de tu ordenador.
- **Sin remoto,** la rama destino local avanza en fast-forward. Nunca se mueve por debajo de trabajo sin commit.
- **Si el destino se movió entretanto,** el elemento se reconstruye sobre la nueva punta y se comprueba de nuevo. Eso ocurre como máximo tres veces; si el destino sigue moviéndose, el elemento falla.

Si cierras y vuelves a abrir la app, el trabajo interrumpido no se pierde; vuelve a la cola.

## Ajustes

No hay muchos, y todos están en la misma pestaña:

| Ajuste | Qué hace | Por defecto |
| --- | --- | --- |
| Target branch | La rama donde aterriza el trabajo | Vacío: rama por defecto |
| Merge | Merge commit o Squash | Merge commit |
| Check | Comando que se ejecuta sobre el resultado fusionado | Vacío: el comando de test del proyecto |
| Land passing branches automatically | Aterriza las ramas que pasan sin aprobación | Desactivado |

En los elementos en cola puedes reordenar con **Up** y **Down**, detener uno con **Cancel** y reiniciar uno fallido o cancelado con **Retry**. Cada elemento tiene su propio log e historial, y los elementos con un pull request tienen un botón para abrirlo en GitHub.

La cola comparte recursos con otras tareas en segundo plano y va primero: los merges van antes que las automatizaciones y los equipos en paralelo. Los agentes que inicias tú nunca se ponen en cola.

## Equipos en paralelo y la cola juntos

El merge queue rinde más con un equipo en paralelo. Un equipo en paralelo divide un trabajo grande en hasta ocho partes; por defecto se ejecutan tres agentes a la vez, cada uno en su propio worktree. Las partes se fusionan en una rama de integración, y un agente de integración se ocupa de los conflictos y de la comprobación.

Cuando el equipo termina tienes una rama de integración. Pulsa **Queue** para enviarla. Otro equipo o una automatización pueden haber enviado algo a main entretanto; la cola los toma todos en orden, probando cada uno sobre el último main.

Para ver el panorama general de trabajar con varios agentes, consulta [agentes de código en paralelo](/es/blog/parallel-coding-agents/).

## Errores comunes

- **Un check vacío y ningún comando de test.** La cola fusiona igualmente, pero sin nada que verificar no puede detectar conflictos semánticos. Define el comando de test del proyecto o pon un comando en **Check**.
- **Solo tests unitarios.** Muchas roturas como la de arriba aparecen en la comprobación de tipos o en el build. Añádelos al check.
- **Activar el aterrizaje automático el primer día.** No actives **Land passing branches automatically** antes de haber observado la cola un tiempo. Aprueba a mano durante unas semanas.
- **Ramas enormes.** La cola las acepta, pero la probabilidad de conflictos y fallos crece con el tamaño. Da a los agentes trabajos pequeños y enfocados.
- **Ignorar los elementos rechazados.** Un rechazo suele señalar un choque de diseño real. Lee su log y, si hace falta, devuelve el trabajo al agente con una nota.

## Un día de ejemplo

### Mañana

Inicias tres agentes en tres trabajos: la página de checkout, la API de informes y una actualización de dependencias. Cada uno trabaja en su propio worktree. También hay un fallo de CI de anoche; una regla de automatización ya lo detectó y envió el arreglo a la cola.

### Media mañana

A medida que los agentes terminan, abres sus tarjetas en la bandeja Review. La página de checkout y la API de informes se ven bien, así que haces **Send to the merge queue** con ambas. La cola tiene ahora tres elementos: el arreglo de CI, la página de checkout y la API de informes.

### Mediodía

El arreglo de CI pasa su comprobación y espera aprobación. Pulsas **Land**. La página de checkout se fusiona sobre el nuevo main y pasa. La API de informes entra en conflicto con un tipo que cambió la página de checkout; el agente resolutor interviene, actualiza los puntos de llamada y la comprobación se pone en verde. Lo único que hiciste fue aprobar dos veces.

### Tarde

La actualización de dependencias sigue en rojo tras dos rondas de arreglo y se rechaza. Main sigue limpio. El log muestra un cambio de versión mayor en una biblioteca, así que devuelves el trabajo a un agente con instrucciones más acotadas.

## Lista de comprobación

- [ ] ¿Tiene el proyecto un comando de test, o hay un comando en **Check**?
- [ ] ¿Cubre el check la comprobación de tipos y el build?
- [ ] ¿Es correcta la **Target branch**? Vacío significa la rama por defecto.
- [ ] ¿Coincide la estrategia de merge con el hábito de tu equipo: Merge commit o Squash?
- [ ] ¿Está **Land passing branches automatically** activado o desactivado a propósito?
- [ ] En repos de GitHub, ¿has iniciado sesión en GitHub en este ordenador?
- [ ] ¿Son los trabajos de tus agentes pequeños y enfocados?

## Para terminar

Los agentes en paralelo son rápidos, pero una velocidad que rompe main no dura. Un merge queue fusiona y prueba cada rama sobre el último main, así que las ramas que pasan solas no pueden romper main juntas. En AgentVera la cola entrega los conflictos y las comprobaciones fallidas a un agente, verifica el resultado por sí misma y, por defecto, te deja la decisión final.

Más información:

- [Merge queue](/es/features/merge-queue/)
- [Equipo en paralelo](/es/features/parallel-team/)
- [Git y GitHub](/es/features/git-and-github/)
- [Git worktrees para agentes en paralelo](/es/blog/git-worktree-parallel-agents/)
- [Revisión de código con IA](/es/blog/ai-code-review/)

Para probar AgentVera, empieza en la [página de inicio](/es/).

## Preguntas frecuentes

**¿Qué es un merge queue?** Un merge queue pone en cola las ramas que esperan aterrizar y fusiona cada una sobre la punta actual de la rama destino, y luego prueba ese resultado fusionado antes de que aterrice. Dos ramas que pasan por separado no pueden romper main juntas.

**¿Por qué se rompe main si cada rama pasó sus propios tests?** Cada rama se probó contra un main más antiguo. Si main avanzó entretanto, dos cambios pueden entrar en conflicto de significado sin entrar en conflicto de texto, y solo probar el resultado fusionado lo revela.

**¿Qué hace el merge queue de AgentVera ante un conflicto?** Abre un agente resolutor que conserva la intención de ambos lados y hace commit. Después AgentVera comprueba que no queden marcadores de conflicto y que la rama esté realmente fusionada. Si no, el elemento falla y nunca aterriza.

**¿Las ramas que pasan aterrizan solas?** No por defecto. Con «Land passing branches automatically» desactivado, una rama que pasa sus comprobaciones espera tu aprobación y aterriza cuando pulsas Land. Puedes activar el ajuste.

**¿Qué plan incluye el merge queue?** El merge queue está en los planes Pro y Team. En la app de escritorio está en Details → Automation → Merge queue.

---

**Sobre AgentVera.** AgentVera es una app de escritorio para macOS, Windows y Linux, desarrollada por Solviera Teknoloji. Ejecuta 18 agentes de programación con IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) en paralelo, por proyecto, en terminales reales con las instalaciones y sesiones de CLI del propio usuario. El plan gratuito tiene agentes ilimitados. Descargar: https://agentvera.dev/es/download/ · Precios: https://agentvera.dev/es/pricing/