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.
A single AI coding session works well for an hour and degrades after that. Three things go wrong.
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.
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.
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 coordinating session is sometimes called the overwatch. Its responsibilities:
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.
You need three things. The specific tools are replaceable, the roles are not.
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.
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.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:
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.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 progressIf 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.
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.
This is the part that distinguishes the methodology from “run several agents at once.”
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 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.
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.
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.
Context: <url> in a launch prompt rather than pasting the context into it. The prompt stays short, and the context stays where it is maintained.A message is a nudge. A file is a contract.
A small discipline that pays off: keep durable policy separate from ephemeral work content.
Policy directories hold the contract that governs every cycle, meaning the loop, the routing rules, and the standards. Long-lived, reviewed, rarely changed. One-off briefs, task context, and session-specific instructions belong on the board or in a scratch directory.
Mixing them means that in six months nobody can tell which files still govern anything.
A long autonomous run should report on a cadence rather than disappearing for hours and returning with a wall of diff.
The rule that makes timeboxing work: the interval decides how often you surface, never where the work stops. When the timer expires mid-item, finish the item, verify it, commit it, then report. Cutting a run mid-task strands work in the state that is hardest to recover, which is half-applied, unverified, and impossible to describe honestly.
A checkpoint is a surfacing moment, not a permission request. The report goes out and the next item starts in the same turn. If you catch yourself writing “shall I continue?”, delete it. A human who is watching will interrupt, and a human who is not has just had their run killed by a question.
Report what is proven, not what was attempted. An item without a verification result is carried, not done.
These are small, and each one has a failure mode that looks like something else.
Verify a spawned session actually started. Launchers report that a workspace was created, which is not the same as an agent running. Check for the process, and check its working directory:
launched_at=$(date +%s)
# ... spawn the session ...
# then accept only a process whose start time is after $launched_atCapture the reference timestamp immediately before the launch. A filter keyed on “newer than the last session” will happily admit an unrelated session that started in between, and if that one has a different working directory, a healthy launch looks broken.
Session names are not addresses you can guess. Whatever name you gave a workspace is often not the name the messaging layer uses. Re-list the live sessions before addressing one, and do not reuse a name you read earlier.
Short identifiers are display prefixes, not keys. Boards commonly show a truncated ID. Padding it out into a full-length identifier produces a well-formed value that does not exist. Resolve it by searching for a distinctive label substring instead.
Search for the label, not your paraphrase. A log entry’s title is usually the writing session’s framing of what it did, which is not the card’s actual label. Searching for the former finds nothing and reads as “no such card.”
In a shared working tree, never use a bare commit. git add <path> followed by git commit commits the entire index, including anything a concurrent session has staged. Use git commit -- <paths> so the commit takes only what you named.
Use it when:
Do not use it when:
The overhead is the point. You are buying the ability to trust the result.
The measure of whether it is working is not how much code gets written. It is whether, at any moment, you can ask “what is the state of this work?” and get an answer that is true.
The instinct when AI coding agents underperform on long work is to reach for a better model or a bigger context window. Both help. Neither addresses the actual constraint, which is that nobody is checking. That is the same gap behind the 70% problem, and behind every agent that operates a live system without a read-back step.
A coordinating session that writes no code but knows what is true is worth more than another executor. That is an old lesson from human organizations, and it turns out to transfer.