Chapter 14. Agent Orchestration¶
One agent is the beginning. We give it a task; it reads the code, writes, runs the tests, and comes back with a result. Everything this book has said about a session so far is about that agent: the context boundary, the proxy, norms, the control loop.
Mostly, though, we work with several agents. One breaks the task into parts and hands them to the others, each with its own context, often in parallel and on separate branches. Some of them work for five minutes, some for several hours without a pause. The results come back, get merged, and you receive a single message: done.
The agent that distributes the work and collects the results I’ll call the orchestrator; the ones it hands the parts to, subagents. Engineering already knows the word “orchestration” from Kubernetes, which came up in chapter 13: a system that distributes and restarts services across many machines on its own. You can also call this main agent a controller.
What changed for you? There are now several times more steps than you could read, and of those you see only the last message. Who holds the goal in a system like that?
Chapter 2 would answer briefly: every new agent adds machine variety, while yours stays the same — like the shepherd who had two more flocks added to his one. Chapter 13 assembled a control loop for a single agent; here there are several loops, and the most interesting part happens between them.
Copies are not yet a system¶
The first thing you want to do with agents is multiply them. One agent reviews a pull request well; three will review it three times as reliably. One looks for the cause of an incident; five will find it five times faster.
Sounds like arithmetic — only the arithmetic here is different.
Three agents on the same model, with the same system prompt and the same context, are not three checks but one check run three times. They have the same statistics, the same blind spots, and the same internal goal — plausibility, which chapter 6 was about. A mistake the first one doesn’t see, the other two most likely won’t see either. Together they produce not confidence but the feeling of it: three “approved” instead of one.
Systems theory has a rule for this: a collection of identical elements is a set, not a system, however many there are. What makes a system is the difference between elements — and precisely where they interact. Identical performers on the same job add no new properties to the whole.
So what does add them? Difference. The agent that writes the code and the agent that checks it have to differ where it matters for the check: a different context — the reviewer sees the specification and the tests but hasn’t seen the author’s reasoning; different criteria; sometimes a different model. Subagents hunting for the cause of an incident are useful when each looks at its own source: one at the application logs, the second at the worker logs, the third at the metrics and the deploy history. Every such difference is a distinction the other one didn’t have.
Identical agents can be used differently — as an instrument. Run the same task three times and take not the best answer but what coincided in all three: that’s how chapter 12 separated the decision from the noise. But then it’s no longer three performers; it’s a measurement, and the spread between runs shows where the noise is.
A renovation with a foreman¶
Imagine renovating an apartment.
An electrician, a plumber, a plasterer, a tiler. Each a master of their trade: the electrician can run the wiring with their eyes closed, the tiler lays tile joint to joint. Each works in their own room, with their own tools, on their own day. And each, if asked, will say they did a good job — and won’t be lying.
End of the working week. Yesterday the plasterer finished the hallway wall, ready for paint. Today the electrician came and cut a channel through it for a new switch: a hammer drill, dust over half the apartment, fresh plaster in chunks on the floor. The plumber ran a pipe exactly according to their diagram — to the spot where, by the designer’s drawing, a wardrobe will stand. The tiler raised the bathroom floor a centimeter higher than whoever ordered the doors had counted on, and now the doors don’t close.
Each did their part, and the apartment isn’t finished. The defect doesn’t live in anyone’s work; it lives at the seams — where one person’s work becomes the base for another’s.
Who’s responsible for that? The foreman. And a good foreman doesn’t lay tile. He doesn’t hold the drill and doesn’t stand behind the electrician’s back: if he did, he’d finish one room while the rest stood still. He holds something else.
The drawing — one for everyone. Floor height, outlet positions, where the wardrobe stands: all written down before the first tradesman walked in, and the same for all. The electrician and the tiler may never meet — they have the drawing.
The order of work. First wiring and pipes, then plaster, then tile — because each next layer covers the one before.
And acceptance. Construction has a document with a telling name — the hidden-works sign-off: an inspection of what is about to be covered up. Before the wiring is sealed under plaster, it’s accepted: looked at, measured, photographed. After that the wall is smooth, and what’s inside can no longer be seen. Checking whether the wire runs where it’s drawn would take a hammer drill. A foreman who missed that moment will never see the wiring again — only the switches on the wall.
The drawing, the order, acceptance before covering up, and the seams no single tradesman answers for — that’s what a foreman’s job is made of.
What’s visible from above¶
The foreman doesn’t stand behind the electrician’s back, and not out of laziness: the steps of the level below can’t be seen from the level above.
There’s no direct link between levels. A higher level affects a lower one only through the whole — through the task it gave and the result it accepted. The orchestrator gives a subagent a task and gets a result back. What the subagent did in between — which files it opened, which hypotheses it discarded, what it decided not to check — doesn’t exist for the orchestrator. For you, one more level up, even less so.
You can try to climb through the level and read every step of every agent. Then there’s no orchestration: there’s you and a pile of steps you read yourself — the same shepherd from chapter 2, only now with several flocks. Orchestration where a human watches every step differs from a single agent in nothing but fatigue.
Three consequences follow.
First: to the level above, a subagent is a point. What reaches the top is not the work but a brief report on it, and from that report you see only what deviated and what was agreed to be reported. What exactly has to come back is set before the start. Chapter 13 called this the visible trace, and here it’s needed at every seam. A subagent that wasn’t told what to return will return “done” — the shortest plausible report.
Second: you see only your own links. Your link is with the orchestrator. What the orchestrator wrote to a subagent, what the subagent replied, what two subagents left each other in a shared file — you never saw. Conversations between agents are as invisible to you as the deal between the electrician and the plasterer that “we’ll patch the channel later.”
Third: every level costs. The task has to be written up and handed out; the results collected, merged, and checked at the seams. Every intermediate level eats a share of time and tokens on this redistribution, and the more levels, the smaller the share of what’s spent reaches the actual work. So there should be as many agents as the task has genuinely independent parts, and no more. An orchestrator that launches ten subagents on a three-part task adds seven performers with no part of their own — but with seams to all the others.
A proxy of a proxy¶
Chapter 6 described a goal on three levels: in your head, in the input field, and in the system’s optimization. Between the first and the second stands the proxy — the wording you wrote in place of the goal.
In orchestration, the subagent’s input field isn’t written by you. The orchestrator writes it: it breaks your task down and words its own for each part. This is a proxy of a proxy. You worded the goal, the orchestrator retold it in parts, the subagent optimizes the retelling. If your wording had a gap, the orchestrator fills it with something plausible — and hands that filling to every branch at once.
In a system of agents, a mistake travels both ways. Top down: the orchestrator’s assumption goes into every branch, and each branch adds its own on top. Bottom up: one branch’s mistake rises along with its result and enters the assembled whole. The more branches and levels, the more places a mistake can be born, and the longer the path it travels unchecked.
Two rules follow.
First: one goal per subagent. Chapter 13 showed that an agent with two goals is two lines on one breaker. A task you can describe only with “and while you’re at it” is really two tasks. If the system has more goals than time and attention to see each through, the result isn’t guaranteed, whatever the performers do.
Second: the common measure is set by the level above. Two subagents’ results can be compared and merged only by a measure that’s the same for both. The subagents themselves don’t have one: each measures itself by what it was told. So the acceptance criteria are written by the level above them and not handed to those who are measured by them. An agent that writes its own criteria and accepts itself by them will always be accepted.
What’s left for the dispatcher¶
So what does the human do when the steps aren’t theirs to take?
They become the dispatcher: not supervising steps but distributing, accepting, and stopping. There’s no less work here than when you write the code yourself — just different work, and no agent will do it for you.
The same arithmetic as in chapter 2 applies. Whoever organizes a system has to be organized no worse than the system. If you can’t break the task into parts and name how to check each one, the orchestrator can’t either — it will only pretend it can.
The dispatcher holds the goal, the common measure, the norms, and the stop points — each of them before the start.
The goal. The goal note from chapter 6 — before launch: what I want to get and how I’ll check it. And one question before the start that you can skip with one agent but not with several: can what’s needed be obtained at all from what’s there? If the repository has no tests for a module, no set of subagents will tell you whether the migration broke it. Before the start, that’s visible in five minutes; after — once the agents have already worked for several hours.
The common measure. The foreman’s drawing. Acceptance criteria that are the same for every branch: the contract between layers, the report format for every subagent, the test the assembled result has to pass — not each part separately. And one more thing — who checks the seams: every subagent checks its own part, and nobody checks the seams until someone is given them specifically.
Norms. The normative base from chapter 12 is the only “understand” every subagent has before the start. A subagent didn’t hear your conversation with the orchestrator an hour ago: what’s in its session is what’s in play, and nothing else. A norm that lives only in your conversation never reaches it. And a large team with nothing to hold it together breaks into groups, each doing its own thing. A shared file of norms is that glue.
Stop points. The hidden-works sign-off. Before every step after which checking is no longer possible — a migration on the production database, a deploy, an email to a client, deleting a branch — the system stops and waits for a human. And a default rule for every subagent: if you don’t know for certain what to do — don’t; stop and return the question. Acting at random widens the gap between what’s needed and what’s done; stopping doesn’t.
But a stop costs time: the question goes up, the answer comes down, and while it travels, the branch stands still. So stops should be few, and they should stand where a mistake costs more than the wait.
One more thing from chapter 13 — springiness. A subagent that answers “that won’t work, and here’s why” is worth more than one that returns “done” to any task. With one agent you’ll hear the objection yourself. In a system of agents it has to be designed in: give the subagent a format in which “no” is a legitimate result, not a failure.
And the scope of autonomy of a system of agents is measured the same way as for a single agent in chapter 13: in portions — as much work as the system does in one go before a check — and in stops, when the work came back to a human. Only now the stops have to be counted on every branch separately and at the seams separately.
Seventeen thousand lines¶
I write this book with agents, and every chapter of it is a small system of agents.
First attempt. Chapter 2 was written by one agent in one evening: draft, review, polish, and three figures — in a single session. The monographs whose logic the book stands on it never opened — it retold them from memory. The review was done by the same agent that wrote, and the text passed it easily: same statistics, same blind spots. It drew the figures right away, without asking which were needed. From the outside, the chapter was ready, marked “reviewed and polished.”
The next day I had to rewrite a section where a regularity from practice was presented as a conservation law. And over the following weeks I left fifty-nine edits on the chapter. The agent handled every step on its own. What was missing was another position: everything was written and checked from one place.
Second attempt — this chapter. Now a chapter passes through several agents, and each differs from the others where it matters.
First — three reader agents, in parallel, one per monograph: seventeen thousand lines of OCR’d Russian text between them. Each with its own context — only its monograph — and a report format that was the same for all: the regularity, its essence, verbatim quotes with line numbers. The format is the common measure: a quote with a line number can be checked in a minute. They worked for two to five minutes each. Neither I nor the orchestrator saw their steps — only the notes, which went into a file and will outlive any session.
Then — a stop. The orchestrator drew up a plan for the chapter with three candidates each for the metaphor, the scenario, and the anti-pattern, and without my “yes” no text was written. The renovation with a foreman was my pick of the three.
Then my review; then a polishing agent with a fresh context and a different model. Figures — through a stop again. The English translation — by a separate agent, and only after the figures, when the text will no longer change: first the wiring, then the plaster.
The mistake appeared at the seam between the orchestrator and the readers.
Writing up the task for the readers, the orchestrator put its own assumption into it: it asked them to find in the monograph how defects pass from higher levels of a system to lower ones. I never saw that wording — it was the orchestrator’s proxy for the subagent. The reader returned notes with a caveat at the very top: in the source, defects pass the other way, from the bottom up. Another reader wrote that the words “delegation” and “coordination” don’t appear in its monograph at all — zero matches — and listed the nearest mechanisms separately, marked as a reconstruction, not the author’s claim.
Why did it work? The reader had a different context — the monograph itself, not the conversation with the orchestrator. And the format demanded quotes with line numbers: you can’t plausibly retell something that isn’t in the text and attach a line number to it. A difference in position and a trace that can be checked — and the false proxy stopped at the first seam instead of spreading through the chapter.
My steps in this process — two stops and a review. I didn’t write a single set of notes this time. On review I left sixteen edits on this chapter — against fifty-nine on chapter 2. But one mistake I would earlier have hunted for in the text myself never reached the text.
A committee of copies¶
This chapter’s anti-pattern looks like thoroughness.
A team has set up a pipeline of three agents. The first writes code from a ticket, the second reviews the pull request, the third reads the review and marks it “approved.” Same model, same system prompt, same context: the ticket and the code. Every pull request passes three checks. People see the final “approved” and merge.
The ticket says: “add a discount for regular customers.” The first agent decided that regular means three orders a year. It’s written nowhere — it’s a plausible filling of a gap. The reviewer checks the code against the ticket and agrees: the discount is there, the tests pass. The third sees that the reviewer agreed. That in this company a regular customer is one with a subscription, not one with a number of orders, none of the three knew: it wasn’t in any of their contexts.
How many distinctions did the second and third agents add? Almost none. A reviewer with the same context and the same statistics sees in the code what the author saw — and likewise fails to see that “regular customer” is defined nowhere. The third approves a review written by a copy of the author. Activity is high: three agents, thousands of tokens, detailed comments. And on the outside — one distinction, issued three times, and behind it two conversations between agents that no human saw.
Diagnosis by this chapter’s law: copies are not a system, and a check from the same position is a repeat. Chapter 13 described a practice that over time starts working for itself: many runs, the same quality. The committee of copies is the same state — only the practice didn’t degrade into it; it was built that way.
The cure isn’t a fourth agent. The reviewer gets a different context: not just the ticket and the code but the specification, the team’s norms, the history of similar bugs, and a separate question — “what does the ticket leave undefined?” To that the reviewer should have answered “what is a regular customer?” — and stopped. The third agent gets a different measure: integration tests, say, which the author didn’t run. If there’s no other measure for it, the third agent isn’t needed: one that merely approves someone else’s approval eats resources and distinguishes nothing.
And the “approved” before anything that can’t be rolled back — a merge into the main branch, a deploy — is given by a human, not an agent. Plus the Test button from chapter 13: deliberately plant a bug in a pull request and see whether at least one of the three agents catches it.
Orchestration scales¶
The same thing happens with a team of people. A team lead who reads every commit of every engineer does what a human reading every agent’s step does: the team exists, but only one person is looking. And the same committee of copies — three reviewers with the same experience approving what none of them understands.
A company is one more level: an executive who receives only “everything’s on plan” sees departments the way you see subagents — as points.
When a practice is genuinely ready for orchestration, and when it’s an attempt to skip a stage — that’s the conversation of chapter 15.
In your craft¶
Seams exist in every craft where work is divided into parts.
Text. Three agents write three chapters of a manual in parallel. Each chapter is good. But the same screen is called “the panel” in one, “the dashboard” in the second, “the home page” in the third. The defect lives at the seam. The common measure here is a glossary written before the start. A separate agent checks only the terms across chapters.
Analytics. Five subagents analyze five data sources; the orchestrator merges the conclusions into a report. Every conclusion is plausible. But “active user” means different things in two of the sources, and the report hides that. What counts as active is decided by whoever asked the question. The stop — before the report goes to the client.
Design. Three agents generate layout variants from the same brief. You get three versions of the same average. Difference appears when each gets its own constraint or its own reference. Only someone with criteria can choose among the variants. That step isn’t handed to those who generated them.
To close — three questions for your practice.
— How many agents work in your system — and how do they differ from one another, apart from the name in the config?
— What did your orchestrator write to the subagents on the last run? If you don’t know — who checked that proxy?
— And deeper: which step in your process is the hidden-works sign-off, after which checking is no longer possible? Who accepts it?