On a typical day, several AI coding sessions are working at once: one on a mobile release, one on a web feature, one on this site. One person can’t hold all of that in their head, and nor can any single agent. What makes it work isn’t a smarter model. It’s a small amount of structure that every session follows.
Three roles
- Agents do the work. Each one is a Claude Code session, usually working on one app, in its own git worktree so it never trips over another session’s half-finished changes.
- A manager session keeps the overview. It tracks what’s in flight, asks agents for status, notices when two pieces of work collide, and turns the owner’s decisions into issues.
- The business advisor works at portfolio level: which app gets attention, what to charge, which channel to bet on. The advisor never needs to read code, only the summaries below.
The owner makes the decisions that are genuinely theirs: product trade-offs, names, prices, anything public or irreversible.
One shared issues repo
Our code lives in several repositories, but all the work is tracked in one private GitHub issues repo, partly so every agent can use the same gh command-line tool. Labels carry the workflow:
ready-for-agent: scoped and ready to pick up. An agent claims it by assigning itself and switching the label toin-progress.blocked: waiting on a decision only the owner can make. The agent explains what it needs in a comment instead of guessing.- One label per app, so each app’s work can be listed on its own.
Commits mention the issue number, and the agent closes the issue once the work is merged. Nothing is “done” just because a session said so.
Status files: one per app, under 25 lines
Every app has a status file in the issues repo, with the same headings each time: what it is, who it’s for, its state, what shipped, the open issues, blockers, the next milestone, and questions for the owner. Agents update their app’s file at the end of each session and whenever a milestone changes, such as a launch or an app store approval.
Two rules keep these files honest:
- Numbers only when measured. Installs, sign-ups and revenue are reported only if the agent read them from a real source this session. Otherwise the file says “not visible to agent”. An estimate in a status file eventually ends up in a decision.
- Your own file only. Several sessions push to the same repo, so an agent edits only its own app’s file. If a push is rejected because someone else pushed first, it rebases and tries again. It never force-pushes.
A decisions log
Strategy goes in a separate, append-only decisions file, newest first: which channel we’re betting on, what we’ve deliberately said no to for now, and when we’ll judge whether a bet paid off. Agents are pointed to it before starting anything substantial, so they don’t cheerfully build something the owner already decided against.
Rules in the repo, not in someone’s head
Each repository has a CLAUDE.md of standing rules. Never wipe the shared test database. Never touch another session’s uncommitted files. Pushing to the main branch deploys, so ask first. Every new database table gets row-level security in the same migration. When something goes wrong, the fix usually includes a new line in that file, so the same mistake doesn’t happen twice.
What we’ve learned
- Coordination is mostly writing things down. Short, structured text that any session can read beats any clever orchestration.
- Asking beats guessing. A blocked issue costs an hour. A confident wrong guess can cost a week.
- Verify, then report. Agents check their work against the real thing, such as the live URL or the test run, before saying it’s done.
This structure lets a small studio run several products at once without anyone, human or AI, needing to remember everything.