How to manage a solo software project with several AI agents
Run specialist repository agents without becoming the human message router between unrelated terminals.
Reviewed against Agents City 0.3.0-beta.22 · commit c985198 ↗The real problem
A solo builder owns a backend, mobile app, documentation site, and release checks. Starting one assistant in every folder creates parallel output, but the builder still has to reconstruct which answer owns the product decision.
Target outcome
One personal product city remembers the goal, repositories, roles, runtimes, skills, and decision history while the seat remains the coordination boundary.
side-project
backenddevAPI, persistence, migrations, and runtime failures
appproduct-designUser flow, accessibility, and client integration
docspoInstallation, onboarding, and public product contract
qaqualityAcceptance evidence and independent verification
Before you start
- 01
Your product repositories cloned locally or available through the GitHub picker.
- 02
At least one authenticated supported runtime; every window may use the same one.
- 03
One written product goal that is narrower than a permanent roadmap.
How to do it
Step 01 Create the product city once
Use onboarding to select the software domain, chair role, repositories, goal, and runtimes. The city persists across later sessions.
$agents-city setup --city side-projectStep 02 Give each repository a real responsibility
Assign roles based on what evidence the repository owns. Inspect live-recognised skills before choosing which member should execute a task.
$agents-city seat --city side-project --agent-roles$agents-city skills side-projectStep 03 Open only today’s working set
Keep all repositories on the owner card, but launch only backend and app when documentation and QA are not needed. The filter does not erase configuration.
$agents-city seat --city side-project --only backend,appStep 04 Use a committee only for cross-repo decisions
Routine implementation stays inside one repo window. Open a committee only when evidence from several repositories can change an API, release, or product decision.
$agents-city committee open --input product-decision.json
What you should get
- The product goal and repository responsibilities survive terminal restarts.
- You can use one model everywhere or select a different runtime per window.
- Cross-repository decisions are recorded without making every task a meeting.
What this does not solve
- Agents City does not replace issue tracking, source control, or product judgment.
- Opening more agents increases cost and coordination load; start with the smallest useful city.
- Save work before closing a live tmux session with agents-city exit.