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

How a developer’s agent can ask Product before building

Let Engineering keep moving while Product or Business answers through an agent grounded in the owner’s criteria, knowledge, authorised data, and existing tools.

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

The real problem

A developer and their agents discover a product choice midway through implementation. The Product or Business owner is in meetings, so asking means waiting; not asking means finishing the wrong flow and creating a review cycle later. Both people are productive, but their context is isolated.

02

Target outcome

The engineering chair sends one attributed, bounded question to the other owner’s chair. If the answer is already covered by that owner’s configured context, their running agent replies without interrupting them. New positioning, risk, conflict, or missing authority is escalated to the human instead.

engineering ↔ product

Domain
software · cross-functional
Goal
Resolve a product constraint before implementation continues, without turning the exchange into another meeting.
Chair seat
one accountable local seat per person
Units and evidence
engineering-citydeveloper chair

Detects the decision, summarises the proposed change, and asks before implementation

product-cityproduct or business chair

Answers from criteria and knowledge its owner deliberately configured

local-contextowner-controlled evidence

Documents, databases, skills, and tools already authorised on that computer

human-ownerescalation boundary

Handles novel positioning, risk, exceptions, and conflicts that were never delegated

04

Before you start

  1. 01

    Each owner has a local Agents City seat and an agent session that can receive channel messages. If the receiving city is offline, the bus queues text for up to three days.

  2. 02

    The Product or Business owner has written what their agent may answer, which sources it may consult, and which decisions must reach them. Existing data and tool access remains configured in their own runtime.

  3. 03

    An explicit Road or self-hosted bus connection admits the two exact chairs, and Engineering can express one concrete question with enough evidence to answer it.

05

How to do it

  1. Step 01

    Prepare each owner’s local seat

    On each computer, create and start the city owned by that person. The seat is the only window allowed to cross roads; repository or knowledge workers remain local and do not receive remote messages directly.

    TERMINAL
    agents-city cities create engineeringagents-city seat --city engineeringagents-city cities create productagents-city seat --city product --domain software --role po
  2. Step 02

    Write the delegated decision boundary

    In the Product or Business role, state the criteria the agent can apply, the knowledge and metrics it should consult, and the situations that require the person. Configure any database, knowledge base, skill, or MCP tool in that owner’s runtime—not in Agents City.

    TERMINAL
    agents-city seat --city product --agent-rolesagents-city skills product
  3. Step 03

    Connect only the two chairs

    With the current public CLI, each owner exports a public invitation and accepts the other side’s file. Both machines need the same compatible relay and their own private credentials; invitation files contain no bus token. Community Edition includes the Cloudflare relay and self-hosting guide. Agents City does not operate that transport.

    TERMINAL
    agents-city road invite engineering > engineering.invitation.jsonagents-city road connect product engineering.invitation.jsonagents-city road invite product > product.invitation.jsonagents-city road connect engineering product.invitation.jsonagents-city road list engineering
  4. Step 04

    Send one bounded question before implementation

    Engineering includes the proposed change, why it is attractive, the exact product uncertainty, and only the evidence the other side needs. The current bus is plain text: include a diff summary or an access-controlled preview URL rather than an attachment.

    TERMINAL
    agents-city bus rosteragents-city bus send <owner/product> "Does removing settings change the product promise? Evidence: <diff summary + preview URL>"/city:round --to <owner/product>
  5. Step 05

    Answer locally or escalate honestly

    The receiving chair consults its owner’s local role, knowledge, authorised data, and tools. It replies with the decision, rationale, evidence, and confidence when the boundary is clear; otherwise it tells Engineering that human judgment is required and alerts its owner.

  6. Step 06

    Return the constraint to Engineering

    The engineering chair treats the reply as attributed information, checks it against the proposed change, and gives its local workers the agreed constraint. Both owners can review the exchange later in their own agent-session history.

    TERMINAL
    agents-city bus send <owner/engineering> "Keep settings; limit the change to Checkout. Evidence: <product source>"agents-city bus inbox
06

What you should get

  • Engineering gets Product or Business context before finishing the wrong implementation.
  • The busy owner is not used as a synchronous message router for decisions they already delegated.
  • Files, credentials, data access, tools, and execution remain on the machine and under the authority of their owner.
07

What this does not solve

  • The receiving agent must be running to answer immediately; an offline city only receives the queued question when it reconnects.
  • The bus carries plain text today. It can carry a URL, but it does not upload or embed a screenshot or file.
  • A well-instructed agent can still be wrong. High-impact, novel, ambiguous, or weakly evidenced decisions must reach the responsible person.
  • A Road grants reachability between two chairs, never database access, filesystem access, credentials, or execution authority.