Orchestrating Claude Code Agents: The Chief of Staff Pattern A new agent orchestration approach called the Chief of Staff pattern separates a long-lived coordinating session from short-lived implementation sessions to address context loss and unreliable agent self-reports in long-horizon AI coding work. The pattern, which the source says is also known as orchestrator-worker, coordinator-implementor-verifier (CIV), and maker-checker, keeps state in a durable external board rather than conversation context and requires re-running every agent claim before believing it. The source states a single AI coding session works well for an hour and degrades after that as context is compacted and self-reports drift from reality. 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. 1. 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. 2. 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. 3. 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 https://asyncdot.com/blog/vibe-coding-is-fine-vibe-shipping-is-not . The generation step was never the bottleneck. The checking step is. What is the Chief of Staff pattern? 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 https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows , 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 https://platform.claude.com/cookbook/claude-agent-sdk-01-the-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 https://docs.claude.com/en/docs/claude-code/overview 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 https://github.com/manaflow-ai/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 https://plandesk.asyncdot.com is a planning board exposed to agents over MCP https://modelcontextprotocol.io : 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. | Shape | What it looks like | How it fools you | |---|---|---| | Vacuous assertion | A test that passes whether or not the feature works | Deleting the thing under test leaves it green | | Silent no-match | A grep, filter, or predicate that matches nothing | Zero findings reads as “clean” | | Errored check | A command that failed to run at all | The error is swallowed, absence reads as evidence | | Wrong reference | A filter keyed on “newer than X” | Anything that happened in between slips through | | Stale premise | A check whose expected value was read off broken code | It passes the bug it was written to catch | | Scope mismatch | A green check over a subset presented as the whole | The denominator is never stated | The general defense: every check that can fail to match must say so. A count of zero and a failure to run must be distinguishable. And an absence assertion needs a positive control in the same run, because if nothing ran, “nothing bad happened” passes. Prove a positive before believing a negative Before concluding something is absent, prove your instrument can find it when it is present. Point the check at a known-good case first. A tool that reports “clean” and a tool that is broken produce identical output. Durable channels beat ephemeral ones Sessions can message each other directly. That channel is genuinely useful. It is how a coordinator answers a question mid-run, and how an executing session flags a contradiction rather than working around it. But it is not reliable enough to depend on. A message can be queued behind a busy session, held for approval depending on the receiving session’s permission mode, or expire undelivered. Silence is not agreement. So anything that must arrive goes in a durable channel. - Committed files. A brief, a handoff document, a constraint. Sessions read the repository at startup. - Board cards and comments, where work-specific context belongs. - Share links. Most boards can render a task or document as agent-ready text at a URL. Put Context: