Claude Code: a 'Chief of Staff' pattern for orchestrating agents
The post argues that a single AI coding session works well for about an hour and then degrades, for three reasons: context is finite and lossy, so long sessions get compacted and the details that mattered three hours in shrink to a summary that loses what made them useful; self-reports drift from reality, since an agent saying "tests pass" is reporting its intent and recollection rather than a fresh check, and the gap between the two grows with session length; and nothing compounds, because a lesson learned painfully at hour two is gone by the next session unless someone wrote it down somewhere the next session reads. Adding more agents does not fix this, the article says; it multiplies it, producing several unreliable reporters and no one reconciling them.
Its proposed fix, which it names the "Chief of Staff" pattern, is a division of labour: one long-lived coordinator session assigns work, verifies claims and maintains shared state, while separate short-lived sessions do the implementation. The author is explicit that the shape itself is not new and lists the names it already goes by: orchestrator-worker, supervisor or hierarchical orchestration, coordinator-implementor-verifier, maker-checker (borrowed from finance and operations), the human integration-manager workflow documented in Git's distributed development (whose open-source variant is the benevolent dictator and lieutenants), and "team lead and teammates," which is how Claude Code's own subagent documentation frames it. What the post says it adds on top of that known shape is the verification discipline and the specific failure modes that break long autonomous runs. It also disambiguates from a different, unrelated use of the same phrase: Anthropic's own cookbook contains a "chief of staff agent" built for a startup CEO, which manages that person's calendar, inbox and priorities and routes work to specialist agents. Same metaphor, the post says, different problem; this article is about a coding loop.
Three components make up the setup. Claude Code is the agent runtime: it provides the sessions themselves, tool use, file editing, shell access, and the ability for sessions to message one another, with each session's own context window treated as a feature, since one session's confusion does not contaminate another's. cmux is the session substrate, a terminal-workspace manager the coordinator drives from the command line to spawn new executing sessions with a command such as 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 details cost real time to learn, per the post: --command types text into the workspace's shell rather than starting an agent, so the agent has to be invoked explicitly or the launcher will report success while nothing runs; and long command strings fail to execute reliably, so a short prompt pointing at a committed brief file works better than one buried in shell history. Plan Desk is the durable state store, a planning board exposed to agents over MCP holding projects, goals, tasks with dependency edges, linked design documents and comments; tasks are written as full build contracts (problem statement, action items, interfaces, validation contract, non-goals) detailed enough that an executing session never needs a parent document, and status flips atomically the moment work starts or is verified rather than being batched at the end of a session.
The operating loop processes one work item at a time: pull the next unblocked task from the board; read its linked design document before touching anything; run the verifier first as a "red gate" that must fail, which both proves the check actually works and cheaply catches tasks that turn out to already be done; delegate to an executing session or do it yourself; re-run every claimed command and let exit codes decide ("prove"); read the diff hunk by hunk ("observe"); resolve an approval lane while posting the reasoning ("gate"); then flip status, commit that one item alone, and record progress ("ship"). One commit per board item keeps git history one-to-one with the board, so tracing a later break back to the decision behind it is one git log away.
The verification discipline is presented as the article's central point: a report from an executing session is evidence, not instruction, because the thing an agent is reporting on and the thing it actually checked are often two different objects. The post illustrates this with two kinds of self-report that should not be trusted at face value, "suite green, 49 checks, zero failures" and "tests pass," and with an anecdote about a session that wrote a commit hash into a log file by hand, then verified it with git cat-file against the short hash sitting in its own shell rather than the string it had written; both checks passed, yet the file held a hash that resolved to nothing. The lesson drawn: verify an artifact by reading the value back out of the artifact itself, never from the variable you believe you wrote there. General defenses the post recommends: every check that can fail to match must say so, so a count of zero is distinguishable from a check that failed to run at all; and an absence assertion needs a positive control in the same run, because if nothing ran, "nothing bad happened" trivially passes. Before concluding something is absent, the post says, prove the instrument can find it when it is present.
On communication, the post distinguishes durable channels from ephemeral ones. Sessions can message each other directly, which is useful for a mid-run question or for an executing session to flag a contradiction, but a message can be queued behind a busy session, held for approval depending on the receiving session's permission mode, or expire undelivered, and silence is not agreement. Anything that must arrive is put into a durable channel instead: committed files that sessions read at startup, board cards and comments, or a share link pasted into a launch prompt as a URL rather than pasted-in context. The post also recommends keeping durable policy, the loop, routing rules and standards, in a separate, rarely-changed location from ephemeral, one-off briefs and task context, which belong on the board or in a scratch directory; mixing the two means that in six months nobody can tell which files still govern anything.
The retrieved text cuts off mid-sentence in the piece's 'Timeboxing' section, so the article's specific timeboxing recommendation beyond the framing already given ("for surfacing, not for cutting" in the post's own summary) is not covered here.
Key facts
- A single AI coding session works well for about an hour before degrading, the article says, because context gets compacted and self-reports drift from what actually happened.
- The pattern splits work between one long-lived coordinator session, which assigns tasks, verifies claims and never writes implementation code itself, and separate short-lived sessions that do the coding.
- Shared state lives on an external board, Plan Desk, exposed over MCP, rather than in context, so it survives compaction, session death and handoffs; sessions are disposable, the board is not.
- The operating loop always runs the verifier first as a 'red gate' that must fail before work starts, and ends with re-running every claimed command and committing exactly one board item at a time.
- A cited anecdote: a session wrote a commit hash into a log file by hand, then checked it against the wrong hash sitting in its own shell; both checks passed even though the logged hash resolved to nothing, illustrating why a self-report is evidence, not instruction.
Why it matters
Long-horizon Claude Code work fails, the article argues, less because agents can't write code and more because their context is ephemeral and their self-reports are unreliable: a session degrades after about an hour, and simply adding more agents multiplies unreliable reporters rather than fixing anything. The 'Chief of Staff' pattern is the author's own name for an orchestrator-worker or coordinator-implementor-verifier shape that is already well known under several names; what the post says it contributes on top of that known shape is a specific verification discipline and a catalogue of the failure modes that break long autonomous runs.
Who it affects
Anyone running multi-session, long-horizon Claude Code workflows where one operator coordinates several executing sessions over hours or days. It is explicitly not about the differently scoped 'chief of staff agent' in Anthropic's own cookbook, a personal assistant that manages a startup CEO's calendar, inbox and priorities and routes work to specialist agents; same metaphor, the post notes, unrelated problem.
How to use it
The post describes a combination of three components rather than a single product: Claude Code supplies the isolated agent sessions; cmux is the scriptable terminal-workspace manager the coordinator uses to spawn new sessions, whose --command flag types into the shell rather than launching an agent (so the agent must be invoked explicitly, and a short prompt pointing at a committed brief file works more reliably than a long inline command); Plan Desk is the MCP-exposed planning board that holds tasks as full build contracts and flips their status atomically. The recommended operating loop: pull an unblocked task, read its linked design document, run the verifier first and require it to fail, delegate the work, re-run every claimed command, read the diff by hand, resolve approval with posted reasoning, then ship with exactly one commit per task.
How solid is it
This is a single write-up on a personal or vendor blog (asyncdot.com) presenting a named methodology; the retrieved text does not credit an author, and no adoption numbers, user counts, or organizational backing are given for asyncdot.com, cmux, or Plan Desk. The quoted self-reports ('suite green, 49 checks, zero failures', 'tests pass') and the commit-hash anecdote are the article's own illustrative examples, not attributed to a specific dated incident or named person.
Risks and caveats
The retrieved text cuts off mid-sentence in the piece's 'Timeboxing' section, so the article's actual timeboxing recommendation is not represented here beyond its own summary line. As a single first-party account of one team's internal practice, its central claims, the roughly hour-long degradation point and the described failure modes, are not independently corroborated within the source.
“A message is a nudge. A file is a contract.”
— the article