One orchestrator, many workers

In three weeks, more than two hundred pull requests moved across eleven repositories, each one through the same gates, from ticket to verified deployment. Coding agents did the work. People made the decisions that matter.

The platform belongs to a client in the built environment. It runs on seven .NET services, a shared library suite, an infrastructure repository, an Angular front end and a test-automation suite. Each of those eleven repositories has its own build, its own contract surface and its own history.

Most features touch more than one of them. A single new permission changes the service that owns it, the two services that enforce it and the interface that shows it.

Agents write code quickly. What slows a cross-service feature down is everything around the code: which service owns the change, what the contract between two services looks like, which one ships first, who reviews what, and how anyone knows it works on a live environment rather than in a chat window that says it does.

So the question was never whether an agent can write a feature. It was whether agents can carry one from a ticket to a verified deployment, every time, with a person involved at a few fixed points.

What we built

The setup has two levels of sessions. One orchestrator covers the whole workspace: it plans the work, breaks it down and reviews the result, and it never writes service code. One worker runs per repository: it implements, and it never sees the overall plan. A single file per repository is the bridge between the two.

Five supporting pieces keep that core honest:

• A rulebook the tool loads into every session.
• A message format the sessions use to talk to each other.
• Hooks that enforce the rules that must never be broken.
• A memory that turns repeated observations into rules.
• A fixed model assignment, so the large model handles judgement and the small one handles everything that needs none.

The life of one feature

Every feature follows the same path, and people step in at two points only: approving the plan, then merging, publishing and deploying.

Work moves down the page and across lanes: the orchestrator plans and gates, the workers build and prove, and people decide only at the two highlighted points.

Triage. A feature arrives as a work item. The orchestrator, a Claude Code session opened at the workspace root, sorts it into one of three tiers: an edit it may make on its own (a version bump, a documentation fix), a single-service change, or a cross-service change. The tier decides how much process follows. A task can move up a tier when it turns out larger than it looked. It never moves down.

Reading before designing. The orchestrator goes through the architecture document, the contract documentation of every service involved, the work item with its full comment thread, and the git history of the code it is about to change. A board column saying "to do" does not prove the work is actually missing. Only then does it design the change: which services are affected, which contracts move, and in what order.

One approval. The design becomes a plan file plus a short list of questions, at most four per round and at most two rounds. For cross-service work, a plan-checker agent reads the plan backwards from the goal and lists everything that would stop it getting there. Then a person reads the plan and says go.

Dispatch by file. The orchestrator writes one TASK.md into each target repository: why the feature exists, what changes here and what does not, the contract in both directions, dependencies on sibling work, the evidence expected at the end, and the branch name. Then it stops, and one worker session opens per repository.

Build and prove. Each worker reads its TASK.md, plans, implements test-first, and runs the build and the full test suite. Then comes one adversarial check: a separate agent, in its own git worktree, briefed only to find bugs in this implementation. Every finding is a claim until the worker reproduces it. The worker opens a pull request, writes its report into the plan file, and sends a DONE message with a fixed list of evidence fields.

The gate. The orchestrator compares the diff against the contract line by line, runs convention scans and a read-only reviewer agent, and for contract changes adds an independent verifier in its own worktree. It reports the verdict and asks how to proceed. Merging, publishing and deploying stay human actions; the orchestrator arms the merge when told to and confirms afterwards that it happened.

Live verification. After the deploy, scripted probes check the feature on the live environment, returning PASS or FAIL per operation and cleaning up the test records they create. The orchestrator then writes the QA handover, records what it learned, and archives the plan.

Under the hood

For the engineers reading, here are the mechanics.

Three layers of instructions. The orchestrator's CLAUDE.md stays under two thousand words, with no project names and no dates: it covers tiers, phases, gates and boundaries. Project facts (repository host, work tracker, package feed, deploy paths, naming conventions) live in a separate bindings file. Domain rules such as gRPC conventions, cross-service database views, Entity Framework pitfalls and GraphQL schema duties are short files that load only when a task touches that area, with longer reference text kept apart. Every worker guide is a byte-identical copy of one template; rules specific to a repository live in that repository. Rulings go into a dated ledger, so the rulebook stays undated and the history stays searchable.

A message format between sessions. Orchestrator and workers talk over the tool's session messaging, in a fixed shape. Every message opens with the repository and the round. Every worker decision is numbered (QUESTION#3, DEVIATION#4), and every answer cites the number. A DONE missing a required field goes back. No message can change a task's scope; only an explicit answer from the orchestrator can, and that answer is written into the plan file.

Hooks for the rules that must not be broken. The main one is a pre-write hook that refuses to overwrite an existing TASK.md, because a worker may be in the middle of it. Each enforced rule is listed next to the script that enforces it. If the text and the script ever disagree, that is a bug.

Models by task class. This is where the cost goes, so it is written down.

Every agent call names its model.

Memory that moves up. Each session keeps a file-based memory where observations and incidents land first. An observation that repeats becomes a rule file. A rule that must never be broken becomes a hook. Contract shapes are the one exception: they are never copied into memory or rules, because they live only in the service documentation the workers maintain.

Evidence over claims. A deploy is confirmed from the pipeline's run record, not from a message. A published package is checked on the feed, not inferred from a green build. Live checks refresh the schema first, wait for the service to report healthy, and only then probe. A stale deploy shows up as transport errors on every new field, which makes it easy to spot.

What we learned

A review finding is a claim. Grading a test suite by mutating the code costs a lot relative to what it finds on a small pull request. So the adversarial check got a single brief, find bugs in this implementation, and an eight-minute budget. A reviewer with that mandate will also readily invent inputs the upstream API never sends, and each such finding costs a fix and a CI run. The rule now: the worker reproduces every finding before touching code.

• Reproduced on an input a real user or system can produce: a bug.
• Reproduced only on a constructed input: deferred.
• Not reproducible: refuted, with evidence attached, and one re-check at most.

Two agents in one working tree is a race. One verifier deliberately breaks the code to prove the tests catch the failure. Sharing a checkout with a reviewer, it would hand that reviewer an intentional breakage to report as a real defect. Any agent that edits files now gets its own git worktree, and every read-only agent is told it is read-only each time it starts.

The board is not the record. A work item's description can be overridden by its newest comment, and that comment by a later, unannounced edit to a wiki page. Reading the whole thread, then the revision history, is now a fixed step before anything is dispatched. Running git log on the code a task says is missing belongs to the same step.

Date every ruling. Rules change, sometimes several times in a month, and the reason should always be recoverable. Every ruling carries a date, a source and the file it lives in, while the rulebook itself stays undated. Superseded rulings are marked, never deleted.

Put the human at fixed points. The places where a person sits in the loop were decided early and have not moved:

• One plan approval.
• Questions in batches of four, as options with free text, never left in a file to be discovered later.
• Merging, publishing, and releasing to acceptance or production stay human actions the orchestrator does not offer to take.
• Every action on a live environment is announced in the conversation before it runs.

The fewer and clearer those decisions are, the more of the work the sessions can carry between them.

What's next

The structure has held. The open questions now are cost and recall.

On cost, token spend is being measured per round, and more of the mechanical reads are moving to the smallest model. On recall, the test is whether file-based memory still finds the right ruling after a year of entries, or whether it will need an index. And more rules keep becoming hooks: the second time the model needs reminding of a rule, the question changes from how to remind it to how to make the tool refuse.

The next structural step is supervision. Workers that start, report and pause under the orchestrator instead of under a person, with the human points kept exactly where they are: approve the plan, arm the merge, release.

If you run agents across more than one repository and have found that the code is the easy part, we would be glad to compare notes.