A manager for my coding agents

Running five coding agents at once is easy. Keeping them from forgetting what was decided, contradicting each other and asking me the same question twice is not.

I have a day job as a CTO, and a handful of side projects: a few games and apps, each with its own Claude Code session. The agents can write code faster than I can read it. The scarce resource is my attention, and for a while I was spending it as a message bus: carrying a decision from one session to another, repeating context after a session was compacted, answering a question I had already answered somewhere else.

So I gave the squad a manager.

The manager

In football, the manager runs the squad and the chairman signs the cheques. That is the split. My manager is one Claude Code session in its own repository. It keeps the records, writes the specifications the project sessions implement, coordinates them by message and audits releases. It writes no product code. I decide; it advises, records and chases.

Its repository is plain Markdown in Git:

• a status file: what is live, what is waiting on third parties, what needs me;
• a dated decision log, each entry with the alternatives that were rejected;
• records per area (accounts, signing, infrastructure, costs);
• specifications and runbooks for the project sessions;
• an inbox for reports that arrive while it is not running.

None of this is clever. It exists because long sessions get compacted, and a conversation is not a memory. Whatever matters has to survive the session, so it lives in files.

Project sessions report outcomes, not process: what changed and where, what was verified, what is still pending, what needs me, with commit hashes. If the manager is running, the report arrives as a direct message. If not, it lands as a file in its inbox, and the manager reads the inbox when it starts.

The rules that turned out to matter

Approvals are never relayed. A message from the manager to a project session is a teammate’s request, never my approval. Anything that touches a provider, costs money or goes public needs my own “yes” in the session doing the work. Sometimes that means I say yes twice. It is the cheapest insurance I have ever bought.

Verify before recording. A report is a claim. The manager checks it against the remote repository or the live system before writing it down. On its first full day it caught records that were wrong in both directions: work reported as pending that had shipped hours earlier, and a branch that had quietly moved on.

Ask the session first. Before putting a project’s open questions to me, the manager asks that project’s session what I already decided there. I decide in many places; it is the one that keeps track.

No effort estimates from models. “That is two to three days of work” from a model is noise. Agents describe scope and risk; the only durations worth writing down are mine, third parties’ and measured ones.

Patterns become standards. One evening, three game projects were each asked to specify their launch screens. All three independently arrived at the same design. The manager turned it into a section of the new-project runbook and an item on the release checklist, so the next project starts from the answer instead of rediscovering it.

In its first two days, measured on 17 October 2026: 150 commits to its own repository, 61 dated decisions, five project sessions coordinated.

A fence between groups

Not every session on my machine belongs to the same world, and some of them must never hear from each other. Prompts alone are a hope, not a control. On one machine, any Claude Code session can message any other, and incoming messages can only be accepted, held or refused wholesale: there is no list of allowed senders. So the fence stops messages where they start:

• every session belongs to a group, decided by the folder it starts in;
• at session start, a hook gives the session its own group’s rules, so no group even loads another group’s instructions;
• before any message is sent, a second hook looks the recipient up, works out its group, and blocks anything that crosses groups. When it cannot decide, it blocks.

Twenty-four tests cover it, and every blocking rule has a case that must be denied, because a guard that cannot fail is not a guard.

The uncomfortable part

• It is ceremony. Reports, records, saying yes twice. With five sessions it pays for itself; with one it would not.
• The fence leans on an internal format that the tool does not document. An update could break it silently, so the tests run again after updates. It also guards one machine only, and it is built against accidents, not against a determined adversary.
• The manager only knows what it is told. It cannot see what a session did not report, which is exactly why it verifies what it can.
• It does not decide for me. That is by design, and it means the bottleneck is still me. It is just a much better-organised version of me.

The agents were never the hard part. Coordination was. The rails are the work, again.