Complete Community Edition under Apache 2.0. No telemetry.See the source
Agents City

How to coordinate AI agents across multiple repositories

Give API, web, and QA separate evidence roles while one chair owns the release goal and the final decision.

Reviewed against Agents City 0.3.0-beta.22 · commit c985198 ↗
01

The real problem

A release touches the API contract, the web client, and regression coverage. Three agents can work faster than one, but lateral chat makes authority and evidence hard to trace. The team needs parallel expertise without three competing decisions.

02

Target outcome

One release act records the isolated positions, conflicts, decision, executor, and independent verification instead of leaving the conclusion scattered across terminals.

product

Domain
software
Goal
Decide whether release 0.4 is safe to ship and verify the chosen action.
Chair seat
cpto or po · Codex, Claude, OpenCode, or Kimi
Units and evidence
apidev

Contract changes, migrations, and backend failure modes

webproduct-design

Client behaviour, accessibility, and user-visible regressions

qaquality

Test evidence, release gates, and independent verification

04

Before you start

  1. 01

    Agents City installed from npm or the current source, with at least one supported runtime authenticated.

  2. 02

    The API, web, and QA repositories available locally or selectable through the repository picker.

  3. 03

    A release question narrow enough to produce one decision and a definition of done.

05

How to do it

  1. Step 01

    Create the product city

    Create a stable city instead of opening three unrelated agent sessions. During onboarding, set the software domain and write the release goal in operational terms.

    TERMINAL
    agents-city setup --city product
  2. Step 02

    Assign repositories and evidence roles

    Select the three repositories, then assign roles that describe the evidence each member owns. Roles change perspective and knowledge; they do not give a repo agent chair authority.

    TERMINAL
    agents-city seat --city product --reposagents-city seat --city product --agent-roles
  3. Step 03

    Open a bounded release committee

    Inspect the installed schema and prepare a brief containing the question, constraints, participants, authority, and definition of done. Invite only repositories whose evidence can change the decision.

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

    Decide, execute, and verify

    Let the seat synthesise disagreements, record one attributed decision, name an executor, and assign verification to a different member. Inspect the legal next state instead of bypassing the protocol.

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

What you should get

  • Every repository contributes evidence from its own working context.
  • The release decision has one owner, rationale, executor, dissent record, and verifier.
  • A failed verification returns the act to replanning instead of silently closing it.
07

What this does not solve

  • Agents City does not decide whether the release is correct; it makes authority and evidence explicit.
  • The chair must still write a precise brief and select genuinely relevant participants.
  • Repository agents run with the permissions and network boundary of their configured runtime.