--- title: "Usa varios agentes de código en IA en un repo — CommitCycle" description: "Da a cada agente una task, en una rama, con un acceso que caduca. Los paths que harían daño reciben un owner, y mover un muro cuesta una aprobación." url: https://commitcycle.com/es/ language: es --- # Varios agentes de código en IA en un repo. Uno revierte al otro en silencio. > Da a cada agente una task, en una rama, con un acceso que caduca. Los paths que harían daño reciben un owner, y mover un muro cuesta una aprobación. [Instala El plugin, con el hook, se instala sin invitación](https://commitcycle.com/docs/start/install/) CommitCycle le da a ese trabajo un sitio donde vivir. Los paths que harían daño reciben un owner y un risk level; cada agente, en su propio checkout, obtiene acceso para una task en una rama, y ese acceso caduca solo. Mover un muro cuesta una aprobación — con un motivo, y queda constancia. [Pide una invitación](https://commitcycle.com/es/#start) [Mira cómo funciona](https://commitcycle.com/es/zones/) CommitCycle se construye bajo CommitCycle, y funciona hoy — boards, el connector para agentes, la configuración de repositorios y el plugin que deniega una escritura antes de que ocurra, que puede instalar cualquiera. Lo que necesita invitación mientras esto es nuevo es un board, y eso es una cola, no una página de «próximamente». **Claude:** Añade la URL del connector del board y Claude registra y acota la task desde el chat — sin instalar nada. No puede aprobar accesos: deciden el gate y el owner de la zone. **Cursor:** El mismo connector en Cursor: empieza la task, mira por qué cambió un fichero la última vez, entrega el trabajo. Con el connector solo, nada en la máquina bloquea una escritura. **Consola:** En la consola una task cruza el gate hacia In Progress, y el owner de una zone responde a un access request — por una hora, cuatro, o hasta que la task se cierre. **Claude Code:** El hook rechaza la escritura antes de que ocurra, nombra la zone y su owner, y el agente pide acceso en vez de buscar otro camino. Claude Code es donde se ha visto funcionar este bloqueo. **Terminal:** Desde una terminal, cycle hace cada paso con un comando: start trae el grant a la máquina, submit lo devuelve. ## Qué hace CommitCycle Cuatro cosas, en el orden en que te las encuentras: **captura** el trabajo, le da al agente el **contexto** con el que funciona este repo, lo mantiene dentro de los **límites** que declaró la task, y deja un **registro** de lo que pasó de verdad. - ### [Un board de cinco estados](https://commitcycle.com/docs/concepts/the-board/) [Una línea llegó a Triage 4,0 s después del clic, con el tecleo automatizado — medido una vez, el 2026-08-04. De Triage a Done, con dos transiciones que pasan por el gate: la entrada a In Progress y la entrada a Done.](https://commitcycle.com/docs/concepts/the-board/) - ### [Un servidor MCP](https://commitcycle.com/docs/reference/mcp/) [Registra y acota trabajo sin salir de tu sesión. No aprueba nada — empezar el trabajo sigue siendo decisión del gate.](https://commitcycle.com/docs/reference/mcp/) - ### [Contexto que lee cada agente](https://commitcycle.com/docs/concepts/agents-md/) [El bloque de AGENTS.md se genera a partir del mismo mapa de zones — un fichero, al día, sin reescribirlo en cada sesión.](https://commitcycle.com/docs/concepts/agents-md/) - ### [Zones con owner](https://commitcycle.com/es/zones/) [Path patterns, un risk level y una default policy, en un fichero que revisas como código. Un repositorio empieza sin ninguna, en modo memory, hasta que eliges governance.](https://commitcycle.com/es/zones/) - ### [Grants just-in-time](https://commitcycle.com/es/zones/) [Atados a una task y a una rama. Caducan solos, así que nadie tiene que acordarse de cerrarlos.](https://commitcycle.com/es/zones/) - ### [Una aprobación para mover un muro](https://commitcycle.com/es/zones/) [Una zone protegida se abre para la task una vez, con un motivo, y se cierra cuando caduca el grant. El hook sólo restringe — los avisos de permiso de tu harness siguen aplicando. Una decisión costó 68–83 ms en p95 en una máquina en reposo, medido el 2026-08-03; CC-1377 lo volvió a medir en octubre de 2026 en dos VM en la nube y depende del host: 211–228 ms en p95 en la más lenta.](https://commitcycle.com/es/zones/) - ### [Bash contenido, no adivinado](https://commitcycle.com/es/zones/) [Las escrituras de shell corren contra un snapshot de git, y los cambios en paths protegidos que la task no tiene abiertos se revierten, byte a byte — salvo los ficheros ignorados por git, y lo que un comando deja corriendo (una ejecución en segundo plano, que el hook pregunta antes, un timeout, un cmd &) sólo lo comprueba el cierre.](https://commitcycle.com/es/zones/) - ### [Un registro de gobierno por task](https://commitcycle.com/docs/operations/audit-record/) [No es autoría por línea — declarado frente a tocado, quién aprobó, qué se resolvió con un override y por qué. Sobrevive a la herramienta.](https://commitcycle.com/docs/operations/audit-record/) ## Cada cifra de aquí lleva sus límites impresos al lado Salen de audit records de este repositorio, no de un benchmark diseñado para ganar. CC-3 25 / 25 Vectores de escape de Bash contenidos `sed -i`, `python -c`, `tee`, redirecciones, `git checkout --` y un `npm run` cuyo script de build escribe en un path protegido. Ejecutados contra un fixture repo y verificados byte a byte, no simulados. **Lo que no demuestra** Medido el 2026-08-03. Los paths ignorados por git dentro de una zone no están cubiertos — y `.env` está ignorado por git y es el secreto por excelencia. CC-3 0 / 20 falsos positivos en comandos corrientes El allowlist conservador paró 24 de 24 ataques y bloqueó 8 de 20 comandos legítimos, `mkdir` y `cp` entre ellos. Un 40% de falsos positivos es la desinstalación de la segunda semana llegando con un marcador perfecto, así que el diseño se invirtió. **Lo que no demuestra** Veinte comandos que elegimos nosotros, medidos el 2026-08-03 — no veinte tasks reales. En su primer día sobre este repositorio rechazó tres comandos legítimos en cinco minutos. La fase 6 es la prueba de verdad y no ha corrido. CC-1 68–83 ms añadidos a una tool call, p95 Sobre 120 arranques de proceso en frío — el hook es un proceso nuevo en cada llamada, y los tiempos en caliente lo habrían favorecido. **Lo que no demuestra** Una máquina, en reposo, el 2026-08-03, con la primera build del hook. El p99 llegó a 102 ms contra un presupuesto de 100 ms. CC-1377 lo volvió a medir en octubre de 2026 en dos VM en la nube: en la más lenta, wrapper y núcleo llegaron a 211–228 ms en p95 (carga 0,74–1,04), y el coste del hook sobre un proceso node lanzado por shell fue de 84–111 ms allí frente a 44–48 ms en la más rápida, con el mismo código. Dos hosts, no un estudio. ## Cuatro cosas se rompen cuando un equipo apunta agentes a un mismo repo. ¿Cómo se comparte el contexto entre agentes de código en IA en un equipo? ### Contexto que vive en un portátil Un vault de Obsidian privado, un CLAUDE.md que se quedó atrás hace tres sprints, un AGENTS.md del que nadie se fía. Mantenimiento por persona, respuestas por persona. `cycle sync` escribe el mapa de zones entre marcadores en `AGENTS.md`, sin tocar nada fuera de ellos — el mismo fichero para cada persona y cada agente, revisado como código. La task activa, sus zones abiertas y sus non-goals van a un `CLAUDE.local.md` ignorado por git, que carga Claude Code. [El bloque de contexto](https://commitcycle.com/docs/concepts/agents-md/) ¿Cómo se ejecutan varios agentes de código en IA en el mismo repositorio sin que se pisen entre sí? ### Dos agentes, un repo, ningún árbitro Los dos convencidos de que el mismo módulo es suyo. Uno revierte al otro en silencio, y el arreglo honesto es volver a un agente cada vez. Un grant está atado a una task **y** a una rama, abre sólo las zones que esa task declaró y **caduca solo** — así que salirse de él se rechaza en el momento, no se descubre en la revisión. Los worktrees aíslan; no deciden. CC confina cada checkout — dos agentes en un mismo directorio comparten su task y su grant — y no arbitra entre ellos. [Grants y access requests](https://commitcycle.com/docs/concepts/grants/) ¿Cómo evito que un agente de código en IA edite ficheros que no debería tocar? ### Un prompt no es un permiso AGENTS.md le pide al agente que no entre en migrations/. Pedirlo funciona justo hasta que deja de funcionar, y ninguna línea de ningún log muestra que dejó de hacerlo. Marca los paths irreversibles como zones con un **owner** y un risk level — escribir en cualquier zone exige un grant, sea cual sea su default policy (`deny` cierra también la lectura), y un grant abre sólo lo que la task declaró, y sólo hasta que caduca. El modelo de zones es agnóstico del agente; el punto de enforcement necesita un adaptador pequeño por harness, y **hoy sólo el de Claude Code se ha visto denegar en una instalación real**. 25 de 25 vectores de escape contenidos el 2026-08-03, sobre un corpus que elegimos nosotros. [Las zones, y qué no declarar](https://commitcycle.com/docs/concepts/zones/) ¿Se pueden crear y acotar tasks para un agente de código sin salir de la sesión en la que estás? ### Describir el trabajo cuesta más que hacerlo La task vive en una pestaña del navegador en la que no estás, así que el trabajo empieza sin describir y el primer registro de su alcance es el diff. Un servidor MCP registra y acota la task desde dentro de la sesión en la que ya estás — mapa de zones, cuatro campos, guardado. Ninguna herramienta de ahí aprueba acceso ni se salta el gate: el `cc_start` del connector alojado se lo pide, y mover una task lo decide el gate, con las mismas reglas pregunte el cliente que pregunte. [El servidor MCP](https://commitcycle.com/docs/reference/mcp/) ## Tres capas: una aconseja, otra deniega, otra vuelve a comprobar Capa 1 ### Contexto AGENTS.md Le dice al agente las reglas en un lenguaje que lee, y no impone absolutamente nada. Esta capa es documentación, y preferimos llamarla así. consultiva Capa 2 ### Policy enforcement Hook previo a la tool call Comprueba cada tool call contra el grant en disco y deniega lo que no cubre. Nunca responde allow, así que los avisos de permiso de tu harness siguen aplicando. Nunca toca la red, así que una caída no puede abrir una zone. El modelo de zones es agnóstico del agente — esta capa necesita un adaptador pequeño por harness, y sólo el de Claude Code se ha visto denegar en una instalación real. bloqueante Capa 3 ### Check del pull request GitHub Action Vuelve a ejecutar el mismo matching de zones contra el pull request, con la misma implementación. Comprueba lo que declaró la task, no el grant; pasa cuando el board no responde; y sólo para un merge donde la protección de rama lo exige. Corre sólo en este repositorio y no está publicado. comprueba Medimos, el 2026-08-03, qué hace Claude Code cuando el hook falla — colgado más allá de su timeout, caído, devolviendo una salida malformada, o sin instalar. **En los cuatro casos la escritura se hizo.** Un hook es fail-open salvo que construyas lo que lo cierra, así que lo construimos: un wrapper que siempre responde, y responde _deny_ cuando el núcleo no lo hace — si la failure policy del repositorio está en closed. Eso cubre tres de los cuatro. Por defecto, la failure policy es open: las llamadas siguen bajo tus propios permisos y la sesión queda avisada. El cuarto — una sesión que corrió sin hook instalado — es invisible para la capa 2 por construcción, que es por lo que la capa 3 vuelve a comprobar el diff en el pull request — y eso sólo para un merge donde el check es obligatorio. ## Lo que CommitCycle no hará Decisiones de la spec, no una hoja de ruta disfrazada. ### ~~Ejecutar tu código~~ Ni tus tests, ni tus migraciones, ni tu deploy. CC pide evidencia y la comprueba. Cualquier cosa que se ejecute en tu nombre es blast radius que estaríamos añadiendo — la única excepción son los comandos spike\_cleanup y spike\_verify que configuras tú, y que ejecuta cycle discard. ### ~~Alojar entornos de preview~~ La evidencia visual es una URL que ya tienes, o una captura que adjuntas. Alojar previews es un producto, no el efecto secundario de un punto de una checklist. ### ~~Sustituir tu tracker~~ La primera versión trae su propio board — cinco estados fijos son lo que permite que el gate signifique algo. El intake es una API — un POST con un título — así que un pequeño puente que escribas tú puede alimentarlo desde lo que uses hoy. ### ~~Imponer nada a través de MCP~~ El servidor MCP registra, redacta e informa, y el connector alojado puede pedirle al gate que empiece, entregue o cierre una task. Ninguna herramienta aprueba accesos, y ninguna impone nada. Un agente elige si llama a una herramienta, y un límite que se puede decidir no llamar no es un límite. ### ~~Soportar Windows, todavía~~ Sólo macOS y Linux, y es la única negativa de esta lista que no es para siempre: D-25 deja Windows para después del MVP, y ninguna task del board lo está construyendo. Decirlo ahora nos sale más barato a los dos que una matriz de soporte que en silencio no te incluye. ## Pide una invitación El registro está cerrado mientras esto es pequeño. No porque no haya nada que usar — lo hay, y los pasos del [quickstart](https://commitcycle.com/docs/start/quickstart/) son los de verdad — sino porque a la gente que lo usa pronto se le responde en persona, y eso deja de ser cierto a partir de cierto número. Cuéntanos qué pondrías detrás de un gate. Dos preguntas, y deciden lo que se construye después tanto como deciden la cola. Si tu configuración es una que podemos soportar bien hoy, tendrás noticias pronto; si no, preferimos decírtelo a que lo descubras tú. - Tu dirección va a nuestra propia base de datos y a ningún otro sitio. - Gratis para todo el que entre en esta fase, y te lo diremos nosotros antes de que eso cambie. ¿Ya tienes cuenta? [Inicia sesión](https://dash.commitcycle.com/).