Community Edition completa bajo Apache 2.0. Sin telemetría.Ver el código

Cómo coordinar agentes de IA entre varios repositorios

Da a API, web y QA responsabilidades de evidencia separadas mientras un solo asiento posee el objetivo y la decisión de release.

Revisado con Agents City 0.3.0-beta.22 · commit c985198 ↗
01

El problema real

Un release afecta al contrato de API, al cliente web y a la cobertura de regresión. Tres agentes pueden trabajar más rápido que uno, pero una conversación lateral vuelve difusas la autoridad y la evidencia. El equipo necesita especialización paralela sin tres decisiones rivales.

02

Resultado buscado

Un acta de release conserva las posiciones aisladas, los conflictos, la decisión, el ejecutor y la verificación independiente, en vez de dejar la conclusión repartida entre terminales.

producto

Dominio
software
Objetivo
Decidir si la versión 0.4 puede publicarse y verificar la acción elegida.
Asiento principal
cpto o po · Codex, Claude, OpenCode o Kimi
Unidades y evidencia
apidev

Cambios de contrato, migraciones y fallos de backend

webproduct-design

Comportamiento cliente, accesibilidad y regresiones visibles

qaquality

Evidencia de pruebas, gates y verificación independiente

04

Antes de empezar

  1. 01

    Agents City instalado desde npm o desde el código actual y al menos un runtime soportado autenticado.

  2. 02

    Los repositorios API, web y QA disponibles localmente o mediante el selector de repositorios.

  3. 03

    Una pregunta de release suficientemente acotada para producir una decisión y una definición de terminado.

05

Cómo hacerlo

  1. Paso 01

    Crea la ciudad de producto

    Crea una ciudad estable en lugar de abrir tres sesiones de agentes inconexas. En el onboarding selecciona software y redacta el objetivo de release en términos operativos.

    TERMINAL
    agents-city setup --city producto
  2. Paso 02

    Asigna repositorios y responsabilidades

    Selecciona los tres repositorios y asigna roles que describan la evidencia de cada miembro. Los roles cambian perspectiva y conocimiento; no convierten al agente de repo en presidente.

    TERMINAL
    agents-city seat --city producto --reposagents-city seat --city producto --agent-roles
  3. Paso 03

    Abre un comité de release acotado

    Consulta el schema instalado y prepara un brief con pregunta, límites, participantes, autoridad y definición de terminado. Invita sólo a repositorios cuya evidencia pueda cambiar la decisión.

    TERMINAL
    agents-city committee schema openagents-city committee open --input decision-release.json
  4. Paso 04

    Decide, ejecuta y verifica

    El asiento sintetiza desacuerdos, registra una decisión atribuida, nombra un ejecutor y asigna la verificación a otro miembro. Consulta el siguiente estado legal sin saltarte el protocolo.

    TERMINAL
    agents-city committee show <deliberation-id>
06

Qué deberías obtener

  • Cada repositorio aporta evidencia desde su propio contexto de trabajo.
  • La decisión tiene propietario, razones, ejecutor, disenso y verificador.
  • Una verificación fallida devuelve el acta a replanteamiento en vez de cerrarla en silencio.
07

Qué no resuelve

  • Agents City no decide si el release es correcto; hace explícitas la autoridad y la evidencia.
  • El asiento aún debe escribir un brief preciso y elegir participantes realmente relevantes.
  • Los agentes de repo conservan los permisos y la red de su runtime configurado.