La razón por la que solo se abre un único problema aunque 12 agentes analicen simultáneamente

src/ Imaginemos la situación en la que se deben encontrar llamadas a API obsoletas dispersas en varios directorios. La intuición sugiere que si asignamos doce agentes de IA simultáneamente a doce directorios, también surgirán doce incidencias. Sin embargo, en el flujo de trabajo agéntico de GitHub (gh-aw), por muchos agentes que se movilicen, solo se abre una incidencia al final. El secreto no reside en complejas técnicas de resolución de conflictos, sino en un diseño que, desde el principio, no otorga a los agentes permisos de escritura (lápiz) sobre el repositorio.

Los tokens de GitHub que poseen los agentes carecen por completo de permisos de escritura. Aunque se instruya: «Push this code to the repository», la operación se rechaza a nivel del token, haciendo físicamente imposible el guardado. La única salida que tienen los agentes es dejar datos de solicitud con el contenido: «Please create this content as an issue». En este artículo, analizamos cómo funcionan varios agentes analizando en paralelo sin provocar conflictos en el repositorio ni trabajos duplicados.

El paralelismo está en la ‘lectura’, y la ‘escritura’ detrás de un filtro

GitHub ha convertido su flujo de trabajo agéntico en vista previa pública el 11 de junio de 2026. Esta función permite ejecutar agentes de programación mediante GitHub Actions para gestionar tareas repetitivas como la clasificación de incidencias o resúmenes semanales. Uno de los pilares del diseño de seguridad de este sistema es proporcionar a los agentes únicamente tokens de solo lectura y bloquear el acceso a los valores secretos (secrets) ¹.

Es decir, el procesamiento paralelo existe solo en la fase de «lectura y análisis del repositorio». Aunque varios agentes puedan abrir simultáneamente diferentes archivos y comprender su contenido, ninguno puede registrar directamente sus resultados en el repositorio. El guardado real lo asume un trabajo (job) separado con permisos de escritura. Esta estructura de desconexión elimina de raíz los conflictos y duplicados que podrían surgir durante la ejecución paralela.

Safe Outputs: La propuesta la hace el agente, la ejecución el sistema

El mecanismo denominado ‘Safe Outputs’ en la documentación oficial de GitHub gestiona este guardado separado. Los agentes generan únicamente datos estructurados (solicitudes) sin permisos de escritura, y un Job separado con permisos de lectura invoca las llamadas reales a la API ². Si un agente deja la instrucción: «Please create an issue with this title», un sistema distinto con permisos issues: write se encarga de procesarla ².

Aquí reside un valor predeterminado clave para la prevención de duplicados. Salvo configuración distinta, la función create-issue se activa automáticamente y su límite superior (max) se fija en ‘1’ ². Las etiquetas y los prefijos del título también están controlados mediante su vinculación con el ID del flujo de trabajo ². Aunque 12 agentes soliciten simultáneamente «crear incidencia», el sistema que actúa como filtro lo verifica y lo ejecuta una sola vez.

Cada solicitud posee un ID único (so_...) y, si es necesario ordenar entre trabajos, se utiliza depends-on para hacer referencia al ID del trabajo anterior y crear una cola. El siguiente trabajo se ejecuta únicamente cuando se completa el anterior, y si las dependencias se entrelazan (fail-closed), la ejecución se detiene por seguridad ². La fusión de pull requests también sigue esta regla: el agente no posee directamente permisos de fusión, sino que el sistema valida las políticas y procesa solo las solicitudes aprobadas ²³.

El límite entre paralelismo y secuencialidad visto en el código real

El código de ejemplo de api-sweep, publicado por Start Debugging, ilustra bien este flujo. Este ejemplo asigna un agente a cada subdirectorio de src/ para buscar llamadas a API obsoletas (HttpClientFactory.Legacy) ³.

// .github/extensions/api-sweep/extension.mjs (Start Debugging 예제 기반)
const dirs = await ctx.step("dirs-v1", async () =>
  (await readdir("src", { withFileTypes: true }))
    .filter((d) => d.isDirectory())
    .map((d) => `src/${d.name}`),
);
// ctx.parallel(): 디렉터리 수만큼 에이전트를 동시 실행 (읽기/분석)
const results = await ctx.parallel(dirs.map((dir) => () =>
  ctx.agent(
    `List every call to ${api} under ${dir} and the replacement it needs. ` +
    `Return an empty list if there are none.`,
    { label: `sweep:${dir}`, schema: HITS },
  ),
));
// 결과를 합치는 단계는 순차적으로 진행됨
return { hits: results.filter(Boolean).flatMap((r) => r.hits) };

La ejecución paralela se limita a la sección que utiliza la función ctx.parallel(). Cada agente devuelve únicamente los hallazgos en formato JSON. Una vez que los datos devueltos se integran en uno solo, en la última etapa se genera una única incidencia final conforme a la configuración safe-outputs (max: 1) ³. Aunque doce agentes traigan los hallazgos obtenidos individualmente, todo converge a uno solo en el filtro final.

Tres modos operativos y el límite común de seguridad

Las formas de utilizar agentes múltiples se dividen esencialmente en tres categorías, distinguidas por la presencia o ausencia de permisos de escritura ³.

1. /fleet (ejecución instantánea): En una sesión de Copilot CLI, cuando el usuario lanza un prompt, los subagentes dividen inmediatamente las tareas. Es adecuado cuando una persona supervisa y orienta el proceso, permitiendo el guardado mediante los permisos otorgados a la sesión ³.
2. Flujos de trabajo dinámicos (scripts): El plan de división se define previamente mediante código JavaScript. Se utiliza para tareas que requieren ejecuciones repetitivas o límites de presupuesto, y la posibilidad de guardar se determina según los permisos de la sesión y el código ³.
3. gh-aw (automatización desatendida): Se ejecuta en momentos sin supervisión humana, desencadenado por eventos o programaciones. En este entorno, los jobs de agentes deben ser estrictamente de solo lectura, y toda escritura debe pasar por el filtro de Safe Outputs ³.

Si empresas como Carvana o Marks & Spencer emplean gh-aw para cambios complejos de sistemas o mantenimiento, se debe precisamente a la confianza generada por estos controles integrados ¹. Carvana atribuyó su capacidad de delegar a los agentes cambios que afectan simultáneamente a múltiples repositorios a la «flexibilidad y los controles integrados», mientras que Marks & Spencer recuperó el tiempo de desarrollo que se perdía en la clasificación de incidencias y el mantenimiento de dependencias, convirtiéndolo en un catálogo reutilizable de flujos de trabajo.

Conclusión

La razón por la que múltiples agentes de IA no generan conflictos al trabajar sobre el mismo repositorio no es que compitan inteligentemente. Los agentes bajo la arquitectura de gh-aw poseen tokens de solo lectura, por lo que les resulta físicamente imposible escribir en el repositorio ³¹. En cambio, las solicitudes generadas se validan en un filtro separado equipado con límites max y reglas de etiquetado, asegurando que, aunque lleguen múltiples propuestas, la aplicación final se realice una sola vez ². El paralelismo se mantiene seguro no gracias a técnicas complejas de fusión, sino porque la escritura se ha desplazado a priori detrás de un único filtro.