Orchestrating Claude Code Agents with the Chief of Staff Pattern

Summary

The article introduces “Chief of Staff” as Asyncdot’s name for a coding-agent orchestration pattern in which one long-lived Claude Code session coordinates and verifies work while separate short-lived sessions implement it. The coordinator assigns tasks from a durable board, writes implementation briefs, re-runs claimed commands, reads diffs, records lessons, and avoids writing the implementation itself. The article argues that long-running single sessions degrade because context is finite and compacted, self-reports can diverge from fresh observations, and lessons disappear unless stored externally. Its proposed system has three replaceable roles: Claude Code as the agent runtime, cmux as a scriptable session substrate, and Plan Desk as a shared planning store exposed through MCP. Tasks are treated as build contracts with dependencies, validation requirements, atomic status changes, linked design documents, and comments. The operating loop pulls one unblocked task, reads its design, runs a failing “red gate” first, delegates implementation, independently proves the claimed results, inspects the diff, resolves approval, and commits only that item. A red gate helps distinguish real implementation from vacuous tests, no-match filters, stale checks, or work that was already complete. The article emphasizes that reports are evidence rather than instructions: exit codes should be rechecked, and artifacts must be read back rather than verified through the variable that was supposed to create them. It identifies common defective instruments, including vacuous assertions, silent no-match checks, swallowed errors, wrong references, stale premises, and scope mismatches, and recommends positive controls before trusting negative results. Direct messages are useful for questions but may be delayed, approval-gated, or lost, so important handoffs belong in committed files, board cards, comments, or share links. The guide also recommends checking that spawned sessions truly started in the intended directory, resolving live session identifiers rather than guessing them, avoiding bare commits in shared worktrees, and separating durable policy from temporary briefs. Timeboxing should determine reporting cadence, not interrupt unfinished work: an item should be completed, verified, and committed before reporting. The pattern is intended for work exceeding one context window or requiring high confidence, but the article says it is unnecessary for a single scoped change or when coordination overhead cannot be justified. It concludes that better models and larger context windows may help, but independent verification and durable state address the deeper reliability problem.