More Agents, More Coordination

One coding agent is a tool. Two or more start to look like a team, and teams come with an old problem attached: coordination. Someone has to decide what gets done, someone has to remember where things stand, and someone has to check that “done” means done.

When I use Claude Code or Codex in a single session, I am all three of those people. That works until the work outgrows a single session. Then I’m the router, copying context from one conversation to another, remembering which change was waiting on which, and re-explaining decisions that were already made. The agents are fast. The coordination is me, and I’m not.

So I’ve been looking at tools that take coordination seriously. Not to build an autonomous software factory, but to understand which part of that job can be made explicit.

Three jobs that are easy to blur

Deciding the work. Which piece comes next, who picks it up, and with what instructions. This is orchestration.

Keeping state. What’s ready, what’s blocked, what’s in progress, and what depends on what. It has to survive the end of a session, because agents forget and so do I.

Verifying. Whether the result actually meets the criteria. It matters who does this. An agent that writes the code and then approves it hasn’t verified much.

Most of the confusion I’ve run into comes from one tool quietly doing all three, or from nobody clearly doing the third.

What I’ve been testing

Two tools from the same ecosystem map neatly onto the first two jobs. I didn’t build either of them; I’m a user trying to understand them.

Gas City describes itself as an orchestration-builder SDK for multi-agent coding workflows. It takes the reusable infrastructure behind Gas Town (runtime providers, work routing, formulas, health patrol) and makes it configurable. In my terms, it’s a candidate for deciding the work.

Beads is a persistent, dependency-aware issue tracker built for coding agents. Instead of a Markdown plan an agent may or may not reread, work is a graph of issues with explicit dependencies, so “what’s ready?” becomes a query rather than a guess. In my terms, it’s keeping state.

I set both up locally, alongside Serena, which gives agents symbol-level code navigation and editing through MCP instead of reading whole files. Then I ran a deliberately small end-to-end test on a synthetic fixture. The flow read an approved spec, produced a plan, had the plan reviewed, broke it into a task graph recorded in Beads, implemented the change in an isolated worktree, and ran protected checks. A separate session did the review before a final gate.

It passed. The change was a few lines in a toy calculation module.

I want to be precise about what that shows. It shows this flow can run end to end, with this setup, on something tiny. It doesn’t show that it scales, that it’s faster than me with one agent, or that it’s ready to build a real product. Getting there also took several diagnostic runs, which is its own data point about the cost of operating the thing.

Where verification lives

The part I find most interesting is the relationship between closing a task and proving it’s done. In a tracker, closing is a state change. What I want is for closing to require evidence: the checks that ran, on which commit, reviewed by whom. The system should be able to say “closed because these checks passed,” not just “closed.”

That’s also where I keep the spec and the decisions outside the tracking tool. The tracker holds execution state; the reasons behind the work live in documents that don’t change when I switch tools.

For the checks themselves, I’ve been reading about Dagger (pipelines as code, with a portable execution engine and caching) and about Nx’s affected-only runs. Neither is adopted in my setup, and I have no measurements to share about them. They’re on the list because “run everything, every time” gets expensive once agents start producing changes faster than CI finishes.

Open questions

• Where does orchestration reduce manual coordination, and where does it just create another system to operate? A multi-agent setup has its own configuration, failure modes, and upgrades. That cost is real.
• How much autonomy is useful before review becomes the bottleneck? More agents mean more changes to verify, and review doesn’t parallelize as nicely as code generation.
• What’s the smallest amount of context a task can get and still be done well? Too little and the agent guesses. Too much and it drowns.

I don’t have answers yet, and I’m suspicious of anyone who has them already. What I have is a clearer picture of the three jobs, and a strong feeling that the one worth protecting most is the last one: someone, or something independent, has to check the work.