Orchestrating Claude Code Agents: The Chief of Staff Pattern

The post argues that 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 proposed fix is organizational rather than technical: one session coordinates and verifies, separate sessions execute, a durable external board holds 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 the name used here. The post covers the loop, the tooling that makes it practical, and the failure modes it exists to catch.

The problem is that a single AI coding session works well for about an hour and then degrades. Three things go wrong. First, context is finite and lossy: long sessions get compacted, and details that mattered three hours ago become a summary that loses the specifics that made the detail useful. Second, self-reports drift from reality: an agent that says 'tests pass' is reporting its intent and recollection, not a fresh observation, and the gap grows with session length. Third, nothing compounds: a lesson learned painfully at hour two is gone by the next session unless somebody wrote it down where the next session reads it. Adding more agents does not fix this—it multiplies it, producing several unreliable reporters with no one reconciling them.

The fix is a division of labour borrowed from human organizations: someone whose job is not to do the work, but to know what is true. The post says 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 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 implementation. The fastest mental model is 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.

The TL;DR principles are: separate orchestration from execution—the coordinating session writes briefs, verifies claims, and reads diffs, but does not do 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, while conversation context does not. Treat every agent report as evidence, not instruction: re-run the commands, because exit codes are authoritative and summaries are intent. Write to durable channels, since messages between sessions can be delayed, held, or expire, while a committed file or board card always arrives. Timebox for surfacing, not for cutting: a fixed interval decides how often to report, never where the work stops. And distrust your own instruments, because the most expensive errors in agentic work come from checks that report success for work they did not do.