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

How to isolate AI agent work between client projects

Give every client a separate city and open a road only when two chairs have a legitimate reason to exchange information.

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

The real problem

A consultancy works on a retail platform and a healthcare portal from the same laptop. Reusing one long-running agent workspace risks context bleed, confused goals, and accidental cross-client coordination.

02

Target outcome

Each client gets a stable identity, private configuration, repositories, knowledge, deliberations, runtime session, and road allowlist. Shared work crosses only an explicit seat-to-seat route.

client-retail · client-health · shared-platform

Domain
one autonomous city per responsibility
Goal
Keep client work isolated while allowing a narrow shared-platform dependency.
Chair seat
one independent seat per city
Units and evidence
client-retailclient city

Retail repositories, goal, knowledge, and deliberations

client-healthclient city

Healthcare repositories and a separate compliance context

shared-platforminternal city

Only the common dependency that may affect both clients

04

Before you start

  1. 01

    A clear list of which repositories and knowledge belong to each client.

  2. 02

    Separate local repository folders and provider permissions appropriate to each engagement.

  3. 03

    An explicit rule for what, if anything, may cross through a shared internal city.

05

How to do it

  1. Step 01

    Create one city per client

    Create managed cities instead of copying folders or reusing an identity. Configure each seat, goal, repositories, roles, and engines independently.

    TERMINAL
    agents-city cities create client-retailagents-city cities create client-healthagents-city cities list
  2. Step 02

    Configure and inspect each boundary

    Open each city separately. Confirm that its owner card contains only the intended repositories and that no road appeared implicitly.

    TERMINAL
    agents-city seat --city client-retail --reposagents-city seat --city client-health --reposagents-city road list client-retail
  3. Step 03

    Model shared work as its own city

    If both clients depend on an internal platform, give that responsibility its own goal and chair instead of connecting the client cities directly.

    TERMINAL
    agents-city cities create shared-platformagents-city seat --city shared-platform
  4. Step 04

    Open only the roads the dependency needs

    Connect each client seat to the shared-platform seat. Check the roster from the active seat before sending evidence. The road does not expose either client repository.

    TERMINAL
    agents-city road connect client-retail shared-platformagents-city road connect client-health shared-platformagents-city bus roster
06

What you should get

  • Switching cities does not merge goals, repo lists, knowledge, committees, or tmux sessions.
  • Client seats cannot address one another unless a road is deliberately added.
  • The shared platform receives only messages admitted through its own seat boundary.
07

What this does not solve

  • City isolation is an application boundary, not a separate operating-system account or VM.
  • Every configured runtime still runs as the local OS user unless you add stronger host isolation.
  • Do not send confidential client text across a road merely because the route exists.