Orchestrating Claude Code Agents: The Chief of Staff Pattern

Long-horizon AI coding work fails less because agents cannot write code and more because their context is ephemeral and their self-reports are unreliable. The fix is organizational rather than technical: one session coordinates and verifies while separate sessions execute, a durable external board holds the state, and every claim is re-run before it is believed. The shape is already known as orchestrator-worker and coordinator-implementor-verifier. Chief of Staff is just what we call it. This covers the loop, the tooling that makes it practical, and the failure modes it exists to catch. TL;DR Separate orchestration from execution. The coordinating session writes briefs, verifies claims, and reads diffs. It does not do the implementation work. Put state in a durable store, not in context. A board, or any external task system with an API, survives compaction, session death, and handoffs. Conversation context does not. Treat every agent report as evidence, not instruction. Re-run the commands. Exit codes are authoritative, summaries are intent. Write to durable channels. Messages between sessions can be delayed, held, or expire. A committed file or a board card always arrives. Timebox for surfacing, not for cutting. A fixed interval decides how often you report, never where the work stops. Distrust your own instruments. The most expensive errors in agentic work come from checks that report success for work they did not do. What problem does this solve? A single AI coding session works well for an hour and degrades after that. Three things go wrong. Context is finite and lossy. Long sessions get compacted. Details that mattered three hours ago become a summary, and the summary loses the specifics that made the detail useful. Self-reports drift from reality. An agent that says “tests pass” is reporting its intent and its recollection, not a fresh observation. The gap between the two grows with session length. Nothing compounds. A lesson learned painfully at hour two is gone by the next session unless somebody wrote it down in a place the next session reads. Adding more agents does not fix this. It multiplies it. Now you have several unreliable reporters and no one reconciling them. What fixes it is a division of labour borrowed from human organizations: someone whose job is not to do the work, but to know what is true. This is the same discipline that separates a prototype from a shipped product. The generation step was never the bottleneck. The checking step is. Chief of Staff is our name for an agent orchestration shape in which one long-lived session acts as coordinator, assigning work, verifying claims, and maintaining shared state, while separate short-lived sessions perform the implementation. If you want the fastest mental model, think of it as an integration manager. In Git’s integration-manager workflow, contributors work in their own repositories and one maintainer pulls each change, tests it locally, and decides what lands in the reference repository. The coordinator does that job, for agent sessions instead of contributors. The name is a metaphor we find useful. It is not an established term, and you should not have to recognize it. The shape underneath it is well known and has several real names. What this is normally called Orchestrator-worker, also supervisor or hierarchical orchestration. Coordinator-implementor-verifier (CIV). Maker-checker, or a validation chain, borrowed from finance and operations. Integration manager, the human version, documented in Git’s distributed workflows long before any of this. Its open-source variant is the benevolent dictator and lieutenants. Team lead and teammates, which is how Claude Code’s own subagent documentation frames it. They all say the same thing: one agent plans and checks, others do the work, and shared state lives outside any single context window. If you are looking for prior art, search those terms rather than this one. What this article adds is not the shape. It is the verification discipline further down, and the specific failure modes that break long autonomous runs. One disambiguation The phrase chief of staff agent is widely used for something else: an assistant that runs a person’s calendar, inbox, and priorities and routes work out to specialist agents. Anthropic’s cookbook has a chief of staff agent of exactly that kind, built for the CEO of a startup. Same metaphor, different problem. This article is about a coding loop. The coordinator’s job The coordinating session is sometimes called the overwatch. Its responsibilities: Pull and assign work from a durable queue, in a defined order. Write briefs that a weaker model could follow without the coordinator’s judgment. Verify claims by re-running the commands an executing session says it ran. Read diffs, not transcripts. What landed matters, what an agent said about it does not. Record lessons in a durable artifact before the session ends. Steer a session that is drifting, without taking the work away from it. What it explicitly does not do is write the implementation. The moment the coordinator starts coding, it stops verifying, and the pattern collapses into a single overloaded session. The three components You need three things. The specific tools are replaceable, the roles are not. 1. The agent runtime: Claude Code Claude Code provides the sessions themselves: tool use, file editing, shell access, and the ability for sessions to message one another. Each session has its own context window, which is the point. Isolation is a feature, because one session’s confusion does not contaminate another’s. 2. The session substrate: cmux cmux manages terminal workspaces and can be driven from the command line, which makes it scriptable. The coordinator spawns a new executing session like this: cmux workspace create \ --name project-session-12 \ --cwd /path/to/repo \ --command 'claude "Read docs/briefs/current.md and do exactly what it says."' Two things about that command are load-bearing, and both cost real time to learn. --command sends text to the workspace’s shell. It does not start an agent. You must invoke the agent explicitly. A bare instruction gets typed at a shell that cannot run it, and the launcher still reports success. Keep the prompt short and point at a file. Long command strings fail to execute reliably. A short prompt pointing at a committed brief is more robust, and it makes the brief reviewable and re-runnable, which a string buried in shell history is not. 3. The durable state store: Plan Desk Plan Desk is a planning board exposed to agents over MCP: projects, goals, tasks with dependency edges, linked design documents, and comments. The coordinator and every executing session read and write the same board. This is the component people skip, and skipping it is why their multi-agent setups do not survive the night. The board is the memory. Sessions are disposable, the board is not. What lives on the board: Tasks as build contracts. Problem statement, action items, interfaces, validation contract, non-goals. Detailed enough that an executing session never needs to read a parent document to finish the work. Status that flips atomically with the work. in_progress the moment you start, done the moment it is verified. Never batched at the end of a session, because a board that is only true at standdown is not a board. Design documents linked to the tasks they govern. Comments, where a human leaves direction and an agent leaves reasoning. The operating loop One work item at a time. One dispatch. One commit. 1. PULL the next unblocked task from the board 2. READ its linked design document before touching anything 3. RED GATE run the verifier first: it must fail 4. DELEGATE brief an executing session, or build it yourself 5. PROVE re-run every claimed command; exit codes decide 6. OBSERVE read the diff hunk by hunk 7. GATE resolve the approval lane, posting reasoning 8. SHIP flip status, commit that item alone, record progress Why the red gate comes first If the check is already green before you start, the work proves nothing. You cannot tell a correct implementation from a check that never runs, a filter that matches nothing, or a test asserting something already true. Running the verifier first also catches stale work cheaply. In practice a meaningful share of queued tasks turn out to be already done, built under a different card or made moot by a later change. A red gate that comes back green in one command costs seconds and saves the hour you would have spent reading code to implement something that already exists. Why one commit per item Git history stays one-to-one with the board. Every commit’s subject names its task. When something breaks three days later, the path from symptom to decision is one git log away. Verification discipline: the heart of the pattern This is the part that distinguishes the methodology from “run several agents at once.” A report is evidence, not instruction When an executing session reports “suite green, 49 checks, zero failures,” the coordinator’s job is to find out whether that is true. Not because agents lie, but because the thing they are reporting on and the thing they checked are often two different objects. One pattern worth internalizing: a session wrote a commit hash into a log file by hand, then verified it with git cat-file, against the short hash sitting in its shell rather than the string it had written. Both checks passed. The file contained a hash that resolved to nothing. The check and the record were two different objects, and only one was tested. The rule that falls out: verify the artifact by reading the value back out of the artifact, never from the variable you think you wrote there. The defect class to watch for The single most common failure in agentic engineering is an instrument that reports success for work it did not do. It has many shapes.