deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

A Chief of Staff orchestration pattern for reliable long-running Claude Code agents

A post on asyncdot.com details an orchestrator-worker pattern for Claude Code: one verifying coordinator, disposable worker sessions and a durable MCP task board for multi-hour coding runs.

A Chief of Staff orchestration pattern for reliable long-running Claude Code agents

A coordination problem, not a generation problem

A post on asyncdot.com, surfaced on the Hacker News front page, argues that long autonomous coding sessions rarely fail because the model cannot write code. They fail because context is finite: long sessions get compacted, and details that mattered hours ago become lossy summaries. They fail because self-reports drift, since an agent saying its tests pass is recalling intent rather than making a fresh observation. And they fail because nothing compounds: a lesson learned at hour two is gone by the next session unless it was written somewhere the next session reads. Adding more agents multiplies the problem, because you then have several unreliable narrators and nobody reconciling them.

The fix the author proposes is organizational. One long-lived session coordinates: it pulls work from a durable queue, writes briefs clear enough that a weaker model could follow them, verifies claims by re-running the commands workers say they ran, reads diffs rather than transcripts, records lessons before the session ends, and steers drifting sessions without taking the work over. What it never does is implement. The moment the coordinator starts coding, it stops verifying, and the setup collapses into one overloaded session.

An old shape with a new label

The post is candid that "Chief of Staff" is a personal metaphor, not an established term. The underlying shape has several real names: orchestrator-worker (also supervisor), coordinator-implementor-verifier, maker-checker from finance and operations, and Git's integration-manager workflow, in which one maintainer pulls, tests and lands changes from separate contributors. Claude Code's own subagent documentation describes it as a team lead with teammates. One disambiguation the author makes: Anthropic's cookbook has a "chief of staff agent" of a different kind, an assistant managing a startup CEO's calendar, inbox and priorities. Same metaphor, different problem.

Three components, fixed roles

The tools are replaceable, the roles are not.

Claude Code is the agent runtime, providing tool use, file editing, shell access and inter-session messaging, with each session holding its own context window. Isolation is deliberate: one session's confusion does not contaminate another's.

cmux, a terminal workspace manager that can be driven from the command line, is the substrate the coordinator uses to spawn workers. The post flags two hard-won lessons here. The launch command sends text to the workspace's shell rather than starting an agent, so the agent must be invoked explicitly; otherwise the instruction lands in a shell that cannot act on it while the launcher still reports success. And long command strings execute unreliably, so a short prompt pointing at a committed brief file is more robust and makes the brief reviewable and re-runnable.

Plan Desk is the durable state store: a planning board exposed over MCP with projects, goals, dependency-linked tasks, design documents and comments, read and written by every session. According to the author, this is the component people skip, and skipping it is why multi-agent setups do not survive the night. Sessions are disposable; the board is what persists. Tasks are written as what the post calls build contracts, covering problem statement, action items, interfaces, a validation contract and non-goals, detailed enough that a worker never needs to consult a parent document. Status flips the moment work starts and the moment it is verified, never batched at session end, because a board that only reflects reality at standdown is not doing its job.

The operating loop

One work item at a time, one dispatch, one commit. The loop runs: pull the next unblocked task from the board; read its linked design document before touching anything; run the verifier first and require it to fail, as a red gate; delegate to an executing session or build it yourself; re-run every claimed command and let exit codes decide; read the diff hunk by hunk; resolve the approval gate while posting the reasoning; then ship. The source text cuts off during the final step, but it begins with flipping the task's status, consistent with the loop's one-commit rule.

The habits that make it hold

The post's general rules apply beyond these specific tools. Treat every agent report as evidence, not instruction: a summary tells you what an agent intended, an exit code tells you what happened. Prefer durable channels, since messages between sessions can be delayed, held or expire, while a committed file or a board card always arrives. Use fixed time intervals to decide how often progress surfaces, never where 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.

Why it matters

As coding agents take on multi-hour, unattended work, the bottleneck has shifted from generating code to checking it. The pattern is tool-agnostic — cmux and Plan Desk have equivalents, and the prior art predates AI entirely — but the discipline transfers: separate planning from doing, keep shared state outside any single context window, and re-run every claim before believing it. For teams pushing agents past the one-hour mark, the post reads less like a novel architecture and more like a checklist of failure modes worth catching before they catch you.

  • #ai-agents
  • #claude
  • #orchestration
  • #developer-tools
  • #llm

Related posts