Orchestrating Claude Code Agents: The Chief of Staff Pattern

Asyncdot published a detailed engineering post on September 19, 2026, walking through a structured approach to running multiple Claude Code sessions on long-horizon work without losing ground to context compaction, stale self-reports, or state that vanishes when a session dies. The pattern is called the Chief of Staff, and it reorganizes agentic coding work the same way a mature engineering organization structures human teams: one role plans and audits while others execute, with shared memory that outlives any individual contributor.

This article unpacks what Asyncdot shipped as a methodology, what the pattern improves over raw multi-agent setups, what builders gain by adopting it, how to stand it up today, and what gaps remain worth monitoring. It is aimed at developers who are already running Claude Code for multi-hour tasks and hitting the reliability ceiling that solo sessions eventually reach.

What shipped in Orchestrating Claude Code Agents

Asyncdot shipped a detailed engineering methodology called the Chief of Staff pattern, built on top of Claude Code's native subagent capabilities. The core of the release is an eight-step operating loop: Pull the next unblocked task from the board, read its linked design document, run the verifier first so it must fail (the red gate), delegate to an executing session, re-run every claimed command with exit codes as the authority, read the diff hunk by hunk, resolve the approval lane, then flip status and commit that item alone. The loop is published openly with accompanying tooling choices, shell snippets, and an explicit failure-mode taxonomy.

The methodology ships alongside two specific tool integrations: cmux for programmatic session management and Plan Desk as the durable state store. cmux is a terminal workspace manager from manaflow-ai that can be driven from the command line, allowing the coordinating session to spawn an executing session with a single shell invocation. Plan Desk, built by Asyncdot and exposed to agents over MCP, holds tasks as build contracts with dependency edges, atomically flippable status fields, linked design documents, and comment threads where humans leave direction and agents leave reasoning. Neither tool is mandatory — the roles are, the specific implementations are not.

What improved in Orchestrating Claude Code Agents

The pattern directly addresses three failure modes that degrade single-session runs over multi-hour work. Before the pattern, context compaction reduced hours-old decisions to summaries stripped of the specifics that made them useful; after, the coordinator and the durable board hold those specifics outside any context window. Before, an executing session reporting "suite green, 49 checks, zero failures" was treated as a verified observation; after, that report is treated as evidence of intent, with the coordinator re-running every command independently. Before, lessons learned mid-session were gone by the next one; after, a handoff artifact updated at session close carries them forward.

The post's defect taxonomy identifies six shapes of false-positive check: vacuous assertion, silent no-match, errored check, wrong reference, stale premise, and scope mismatch. For each, the coordinator's defense is the same: any check that can fail to match must say so explicitly, and absence assertions require a positive control in the same run.

What you gain from Orchestrating Claude Code Agents

Teams running overnight Claude Code tasks gain a verifiable answer to the question "what is the state of this work?" at any moment. Because the board holds status that flips atomically with verified commits — in_progress the moment a task starts, done only after the coordinator has re-run its commands — the state on the board is always true rather than a retrospective approximation batched at standdown. One-to-one correspondence between commits and board cards means that when something breaks three days later, the path from symptom to decision is one git log away.

Builders running parallel work streams gain session isolation as a deliberate property: one session's confusion cannot contaminate another's. The coordinator pattern also enables mixed-model verification, where a different model family audits the output, catching failures that the implementing model is systematically blind to in its own output. The operating overhead is explicit and intentional — verification tokens produce no code — and that overhead is the price of trusting the result. Asyncdot recommends the pattern for work that spans more context windows than one session holds, where multiple streams can run in parallel, and where a wrong "done" is expensive to unwind.

How to get Orchestrating Claude Code Agents

The methodology requires no install of its own. Builders need Claude Code, cmux for session management, and a durable board reachable over an API or MCP surface. To install Claude Code or update it:

npm install -g @anthropic-ai/claude-code

To spawn an executing session from the coordinator using cmux:

cmux workspace create \
  --name project-session-12 \
  --cwd /path/to/repo \
  --command 'claude "Read docs/briefs/current.md and do exactly what it says."'

After spawning, verify the session actually started by capturing a reference timestamp before launch and checking that the process start time falls after it:

launched_at=$(date +%s)
# ... spawn the session ...
# then accept only a process whose start time is after $launched_at

Asyncdot's getting-started sequence is: stand up a durable board with projects, goals, and tasks with dependency edges; write the loop contract in a single committed file that every session reads at startup; run one coordinator and one executor before scaling further; add a handoff artifact the coordinator updates at every session close; and keep a lessons log written before each session ends. Plan Desk is available at plandesk.asyncdot.com with MCP integration for agent access.

What to watch after Orchestrating Claude Code Agents

The pattern as published handles the coordination loop and the verification discipline but leaves timebox duration as a judgment call. Asyncdot notes that the interval governs surfacing cadence, not where work stops — finishing mid-item before reporting is required — but gives a reference range of fifteen to thirty minutes in the FAQ without baking that into the loop specification. Builders with tasks that vary widely in duration should watch whether their timebox calibration causes surface reports to cluster around work handoffs rather than natural pause points.

A second area worth watching is the session-name addressing problem. The post notes that the name given to a cmux workspace is often not the identifier the messaging layer uses, and that short board IDs are display prefixes rather than resolvable keys. Both produce failures that look like correct behavior — a session found, a card resolved — when the target is actually wrong. Tooling that makes session identity and board ID resolution deterministic would remove one class of silent error from the loop. Anyone extending this pattern to a different session manager or a different board backend should treat address resolution as a first-class concern rather than an implementation detail.