编排 Claude Code Agent：幕僚长模式（Chief of Staff Pattern）

长周期（Long-horizon）AI 编程任务之所以失败，往往不是因为 Agent 不会写代码，而是因为它们的上下文是瞬时易失的，且自我汇报不可靠。解决方案是组织层面的，而非技术层面的：一个 Session 负责协调与校验，由独立的其他 Session 负责执行；一个持久化的外部看板用于保存状态；每一个结论在被采信前都必须重新运行验证。这种架构形态其实早有成熟称谓，即“编排者-工作者（orchestrator-worker）”与“协调者-实现者-校验者（coordinator-implementor-verifier）”。幕僚长（Chief of Staff）只是我们对它的称呼。本文将深入探讨这一循环、使其落地的工具链，以及它所要防范的各类失效模式。

TL;DR

• 将编排与执行分离。 负责协调的 Session 编写任务简报（briefs）、校验汇报结论并审查 diff，不亲自执行具体的代码实现工作。
• 将状态保存在持久化存储中，而非放入上下文中。 看板或任何带有 API 的外部任务系统，能够在上下文压缩（compaction）、Session 崩溃和任务交接后依然留存。而对话上下文无法做到这一点。
• 将所有 Agent 汇报视为证据，而非既定事实。 重新运行命令。退出码（exit codes）才是权威依据，汇报摘要只代表主观意图。
• 写入持久化信道。 Session 之间的实时消息可能会发生延迟、阻塞或过期。而提交到版本库的文件或看板上的任务卡片永远能送达。
• 时间盒用于汇报浮动，而非强行截断工作。 固定的时间间隔决定了多久向上汇报一次，但绝不决定工作应在哪里戛然而止。
• 怀疑你自己的检验工具。 Agent 自动化工作中最代价高昂的错误，往往来自那些对根本未完成的工作汇报成功的校验工具。

这解决了什么问题？

单个 AI 编程 Session 通常在前一个小时表现良好，随后便开始退化。主要会出现三个问题：

1. 上下文有限且具有损耗性。 长时间运行的 Session 会被压缩。三个小时前至关重要的细节被浓缩为摘要，而摘要往往会丢失那些让细节发挥作用的具体信息。
2. 自我汇报脱离实际。 当 Agent 声称“测试已通过”时，它汇报的往往是它的意图和模糊记忆，而不是刚刚进行的客观观测。二者之间的偏差会随着 Session 时长增加而不断扩大。
3. 知识无法沉淀复利。 在第二小时经历痛苦教训换来的经验，到下一个 Session 就会荡然无存——除非有人将其记录在下一个 Session 能够读取的地方。

盲目增加更多 Agent 解决不了这个问题，反而会成倍放大缺陷：你只会得到几个不可靠的汇报者，且没有人负责核对调和。

真正能解决问题的是借鉴自人类组织的劳动分工：设立一个职责不是具体干活，而是确保事实真相的角色。

这与将原型与正式发布产品区分开来的规范是一致的。代码生成步骤从来都不是瓶颈，校验审核才是。

什么是幕僚长模式？

“幕僚长（Chief of Staff）”是我们用来指代一种 Agent 编排形态的名称：在这种形态中，一个长期存续的 Session 充当协调者，负责指派工作、校验声明并维护共享状态；而独立的短期 Session 则负责执行具体实现。

如果你想快速建立心智模型，可以将其视为集成管理员（integration manager）。 在 Git 的集成管理员工作流中，贡献者在各自的代码仓库中工作，由一名维护者拉取每一处改动，在本地进行测试，并最终决定将哪些内容合入主干基准仓库。协调者扮演的就是这个角色，只不过服务的对象从人类贡献者换成了 Agent Session。

这个名字是我们认为很贴切的一个比喻。它不是一个既定行业术语，你也不必非去识别它。其底层的架构形态早已广为人知，并有多种正式称谓。

这通常被称作什么

• 编排者-工作者（Orchestrator-worker），也称为**监督者（supervisor）**或分层编排（hierarchical orchestration）。
• 协调者-实现者-校验者（Coordinator-implementor-verifier, CIV）。
• 制作者-检查者（Maker-checker），或称验证链（validation chain），借用自金融和运营领域。
• 集成管理员（Integration manager），人类团队版本，早在这一切出现之前就已记录在 Git 的分布式工作流中。其在开源界的变体是“仁慈的独裁者与副手们（benevolent dictator and lieutenants）”。
• 团队主管与团队成员（Team lead and teammates），这也是 Claude Code 官方子代理文档中所使用的表述。

它们表达的内核完全一致：一个 Agent 负责规划与检查，其他 Agent 负责动手干活，共享状态则保存在任何单个上下文窗口之外。如果你想搜索过往相关实践，建议检索上述术语而非本文的比喻。

本文的核心增量并非这一形态本身，而是下文所阐述的校验规范，以及那些会导致长时间自主运行任务崩溃的特定失效模式。

一点概念辨析

“幕僚长代理（Chief of Staff agent）”这一短语常被用来指代另一类事物：负责管理个人日程、收件箱和优先级，并将工作路由分发给专家代理的助手。Anthropic 的 Cookbook 中就包含这样一个幕僚长代理示例，专门为初创公司 CEO 打造。相同的比喻，解决的却是不同问题。本文讨论的是代码编写循环。

协调者的职责

协调 Session 有时也被称为监视者（overwatch）。其职责包括：

• 从持久化队列中按照既定顺序拉取并指派工作。
• 编写简报，使其详细明确到能力较弱的模型无需依赖协调者的裁量权即可执行。
• 通过重新运行执行 Session 声称运行过的命令来校验各项结论声明。
• 阅读 diff，而非查看聊天记录。合并了什么代码才是关键，Agent 说了什么并不重要。
• 在 Session 结束前，将经验教训记录到持久化产物中。
• 对出现偏离的 Session 进行纠偏，同时不越俎代庖抢夺其任务。

协调者明确不做的事就是编写实现代码。协调者一旦开始写代码，就会停止校验，该模式便会退化并崩塌为一个严重过载的单 Session。

三大核心组件

你需要三个组件。具体工具可以替换，但角色缺一不可。

1. Agent 运行时：Claude Code

Claude Code 提供了 Session 基础能力：工具调用、文件编辑、Shell 访问以及 Session 之间互相发送消息的能力。每个 Session 都有自己独立的上下文窗口，而这正是关键所在。隔离性是一大特性优势，因为一个 Session 的混乱不会污染另一个 Session。

2. Session 底座：cmux

cmux 用于管理终端工作区，支持通过命令行驱动，具备良好的脚本可控性。协调者通过如下方式派生出新的执行 Session：

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

该命令中有两个承重关键点，均需要付出真实时间成本才能领悟：

• --command 实际上是将文本发送到工作区的 Shell 中。 它不会自动启动 Agent。你必须显式调用 Agent。直接发送裸指令只会被输入到无法执行它的 Shell 中，而启动器依然会错误地报告执行成功。
• 保持 Prompt 精简，直接指向文件。 长命令字符串往往无法可靠执行。保持简短的 Prompt 指向一个已提交到仓库的任务简报文件更加稳健，而且这使得简报本身可审查、可复现，而埋在 Shell 历史记录中的长字符串做不到这点。

3. 持久化状态存储：Plan Desk

Plan Desk 是一个通过 MCP 暴露给 Agent 的规划看板：包含项目、目标、带有依赖关系边的任务、关联的设计文档以及评论。协调者与各个执行 Session 读写同一个看板。

这是大多数人会忽略的组件，而忽略它正是多 Agent 系统无法熬过通宵运行的根源。看板就是记忆系统。 Session 是用完即弃的，看板则不是。

看板上维护的内容包括：

• 作为构建契约的任务。 包含问题陈述、行动项、接口、验证契约与非目标。细节足够详尽，以至于执行 Session 完全不需要阅读上级父文档就能完成工作。
• 与工作状态原子化同步的状态切换。 开始动工的瞬间标记为 in_progress，验证通过的瞬间切换为 done。绝不能等到 Session 结束时才批量处理，因为一个只有在下工收尾时才真实的看板根本称不上是看板。
• 设计文档，与其管辖的任务卡片直接关联。
• 评论区，人类在此留下业务指引，Agent 在此记录推演理由。

运行闭环

一次处理一个工作项。一次调度。一次提交。

text

1. PULL 从看板拉取下一个未被阻塞的任务
2. READ 在动手修改任何东西前，阅读其关联的设计文档
3. RED GATE 首先运行校验器：此时它必须失败
4. DELEGATE 编写简报指派给执行 Session，或者自行构建
5. PROVE 重新运行所有声称执行过的命令；以退出码为准
6. OBSERVE 逐块审查 diff 内容
7. GATE 通过审批泳道，发布决策推导过程
8. SHIP 翻转任务状态，单独提交该项代码，记录进度

为什么红灯门禁（Red Gate）必须置前

如果在开始工作前检查就已经显示绿灯，那么这项工作无法证明任何事情。 你将无法分辨这究竟是一个正确的实现，还是一个根本从未运行的检查、一个匹配不到任何东西的过滤器，亦或是一个断言了原本就为真的测试。

优先运行校验器还能以极低成本发现过时作废的任务。在实践中，队列中相当一部分任务卡片最终被证实早已完成——可能是在另一张卡片下顺带完成的，或者是被后续的某次变更直接变成了无用功。一次仅需数秒就返回绿灯的红灯检查，能直接省下你花一小时阅读代码去实现本已存在之物的时间。

为什么每个任务项单独提交一次

这能保证 Git 提交历史与看板保持一一对应。每一次提交的主题行都会明确标注对应的任务。三天后一旦发生故障，从问题表象追踪到当初决策路径的操作只需一条 git log。

验证规范：模式的核心

这是将该方法论与单纯“同时运行多个 Agent”区别开来的关键部分。

汇报只是证据，不是指令

当执行 Session 报告“测试套件通过，49 项检查，零失败”时，协调者的工作是去查证这是否属实。这并非因为 Agent 会恶意撒谎，而是因为它们所汇报的对象与它们实际检查的对象往往是两个不同的实体。

一个值得铭记的典型案例：某个 Session 手动将一个 Commit Hash 写进日志文件，随后使用 git cat-file 进行校验，但它校验时使用的却是留在 Shell 变量里的短 Hash，而不是刚刚写入文件里的字符串。两项检查都通过了，而文件里实际写入的却是一个指向虚无的无效 Hash。检查的对象和记录的对象是两个不同的实体，被测试的只有其中一个。

由此沉淀出的法则是：必须通过直接重新读取产物中的实际数值来验证该产物，绝不要使用你自以为写入其中的变量来验证。

需要警惕的缺陷类型

在 Agent 工程化中最普遍存在的单点故障是：一个检验工具对根本没有完成的工作汇报成功。 它有多种伪装形态：

缺陷形态	表现形式	它是如何蒙蔽你的
空洞断言 (Vacuous assertion)	无论功能是否有效都能通过的测试	删掉被测试的核心功能，测试依然显示绿灯
静默无匹配 (Silent no-match)	未匹配到任何内容的 grep、过滤器或断言谓词	没有任何异常发现被误读为“状态正常（clean）”
报错检查 (Errored check)	根本未能执行成功的命令	错误被隐蔽吞掉，没有报错被视为了正常的证据
错误引用 (Wrong reference)	依赖“晚于 X”条件的过滤器	发生在此期间的所有变动都会逃脱检验
陈旧前提 (Stale premise)	其预期值是从损坏代码中提取出来的检查	它直接放过了它本被编写来捕获的那个 bug
范围不匹配 (Scope mismatch)	针对子集的绿灯检查被包装为整体检查结果	从未声明断言检查的分母到底有多大

通用防御策略： 任何可能匹配失败的检查必须显式声明。计数为零与执行失败必须能够明确区分开来。此外，断言某种异常不存在的检查，必须在同一次运行中包含阳性对照（positive control）；因为如果什么都没有运行，“没有发生坏事”自然也会测试通过。

在相信否定结论之前，先验证肯定结论

在得出“某物不存在”的结论前，先证明你的检验工具在它确实存在时能够准确捕获。首先将检查对准已知正常的基准案例（known-good case）。一个报告“系统干净无异常”的工具，和一个彻底损坏未运行的工具，产生的输出可能完全一样。

持久化信道胜过瞬时信道

Session 之间能够直接通信。这种信道确实很有价值：协调者可以借此在运行中途回答疑问，执行 Session 也能够借此指出矛盾，避免自作主张绕行。

但它不够可靠，无法作为强依赖项。 消息可能会积压在繁忙 Session 的排队队列中，可能会根据接收方 Session 的权限模式被挂起等待人工批准，或者甚至超时未送达直接过期。沉默并不代表达成共识。

因此，所有必须准时且确定送达的内容都必须通过持久化信道流转：

• 已提交到版本库的文件。 包含简报、交接文档或硬性约束。Session 启动时都会读取仓库。
• 看板卡片与评论，具体工作的特定上下文应当归属在此处。
• 共享链接。 大多数看板支持将任务或文档在某个 URL 处渲染为适合 Agent 读取的纯文本。在启动 Prompt 中直接填写 Context: <url>，而不要直接把大量上下文硬编码粘贴进去。这样可以保持 Prompt 短小精悍，并确保上下文集中维护在正确的地方。

消息只是一种提醒，文件才是一份契约。

内容存放原则

一项带来高回报的微小规范：将持久的策略规范与临时的具体工作内容严格分开存放。

策略目录存放管辖每个周期的契约文件，包括运行闭环、路由规则与标准准则。它们长期存在、经过严格审查且极少变更。而一次性的简报、任务卡片上下文和特定 Session 的指令，应当归属于看板或草稿临时目录。

将它们混在一起的结果是：六个月后，谁也分不清到底哪些文件仍然对系统具有约束力。

时间盒：浮出水面而不中断执行

长时间自主运行的任务应当按照固定节奏汇报进展，而不是消失数小时后直接抛出一大堆难以理清的庞大 diff。

使时间盒机制奏效的核心准则是：时间间隔决定了多久浮出水面汇报一次，绝不决定工作停在何处。 当计时器在某个子任务进行中途触发时，应当先完成该子项、通过校验、提交代码，然后再进行汇报。在任务中途强行掐断运行，会让工作停留在最难以恢复的状态：即代码半应用、未经验证且几乎无法理清真实进度的残局。

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 fix is organizational rather than technical: one session coordinates and verifies while separate sessions execute, a durable external board holds the 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 what we call it. This covers the loop, the tooling that makes it practical, and the failure modes it exists to catch.

TL;DR

• Separate orchestration from execution. The coordinating session writes briefs, verifies claims, and reads diffs. It does not do the 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. Conversation context does not.
• Treat every agent report as evidence, not instruction. Re-run the commands. Exit codes are authoritative, summaries are intent.
• Write to durable channels. Messages between sessions can be delayed, held, or expire. A committed file or a board card always arrives.
• Timebox for surfacing, not for cutting. A fixed interval decides how often you report, never where the work stops.
• Distrust your own instruments. The most expensive errors in agentic work come from checks that report success for work they did not do.

What problem does this solve?

A single AI coding session works well for an hour and degrades after that. Three things go wrong.

1. Context is finite and lossy. Long sessions get compacted. Details that mattered three hours ago become a summary, and the summary loses the specifics that made the detail useful.
2. Self-reports drift from reality. An agent that says “tests pass” is reporting its intent and its recollection, not a fresh observation. The gap between the two grows with session length.
3. Nothing compounds. A lesson learned painfully at hour two is gone by the next session unless somebody wrote it down in a place the next session reads.

Adding more agents does not fix this. It multiplies it. Now you have several unreliable reporters and no one reconciling them.

What fixes it is a division of labour borrowed from human organizations: someone whose job is not to do the work, but to know what is true.

This is the same discipline that separates a prototype from a shipped product. The generation step was never the bottleneck. The checking step is.

What is the Chief of Staff pattern?

Chief of Staff is our name for 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 the implementation.

If you want the fastest mental model, think of it as 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 repository. The coordinator does that job, for agent sessions instead of contributors.

The name is a metaphor we find useful. It is not an established term, and you should not have to recognize it. The shape underneath it is well known and has several real names.

What this is normally called

• Orchestrator-worker , also supervisor or hierarchical orchestration.
• Coordinator-implementor-verifier (CIV).
• Maker-checker , or a validation chain, borrowed from finance and operations.
• Integration manager , the human version, documented in Git’s distributed workflows long before any of this. Its open-source variant is the benevolent dictator and lieutenants.
• Team lead and teammates , which is how Claude Code’s own subagent documentation frames it.

They all say the same thing: one agent plans and checks, others do the work, and shared state lives outside any single context window. If you are looking for prior art, search those terms rather than this one.

What this article adds is not the shape. It is the verification discipline further down, and the specific failure modes that break long autonomous runs.

One disambiguation

The phrase chief of staff agent is widely used for something else: an assistant that runs a person’s calendar, inbox, and priorities and routes work out to specialist agents. Anthropic’s cookbook has a chief of staff agent of exactly that kind, built for the CEO of a startup. Same metaphor, different problem. This article is about a coding loop.

The coordinator’s job

The coordinating session is sometimes called the overwatch. Its responsibilities:

• Pull and assign work from a durable queue, in a defined order.
• Write briefs that a weaker model could follow without the coordinator’s judgment.
• Verify claims by re-running the commands an executing session says it ran.
• Read diffs , not transcripts. What landed matters, what an agent said about it does not.
• Record lessons in a durable artifact before the session ends.
• Steer a session that is drifting, without taking the work away from it.

What it explicitly does not do is write the implementation. The moment the coordinator starts coding, it stops verifying, and the pattern collapses into a single overloaded session.

The three components

You need three things. The specific tools are replaceable, the roles are not.

1. The agent runtime: Claude Code

Claude Code provides the sessions themselves: tool use, file editing, shell access, and the ability for sessions to message one another. Each session has its own context window, which is the point. Isolation is a feature, because one session’s confusion does not contaminate another’s.

2. The session substrate: cmux

cmux manages terminal workspaces and can be driven from the command line, which makes it scriptable. The coordinator spawns a new executing session like this:

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 things about that command are load-bearing, and both cost real time to learn.

• --command sends text to the workspace’s shell. It does not start an agent. You must invoke the agent explicitly. A bare instruction gets typed at a shell that cannot run it, and the launcher still reports success.
• Keep the prompt short and point at a file. Long command strings fail to execute reliably. A short prompt pointing at a committed brief is more robust, and it makes the brief reviewable and re-runnable, which a string buried in shell history is not.

3. The durable state store: Plan Desk

Plan Desk is a planning board exposed to agents over MCP: projects, goals, tasks with dependency edges, linked design documents, and comments. The coordinator and every executing session read and write the same board.

This is the component people skip, and skipping it is why their multi-agent setups do not survive the night. The board is the memory. Sessions are disposable, the board is not.

What lives on the board:

• Tasks as build contracts. Problem statement, action items, interfaces, validation contract, non-goals. Detailed enough that an executing session never needs to read a parent document to finish the work.
• Status that flips atomically with the work. in_progress the moment you start, done the moment it is verified. Never batched at the end of a session, because a board that is only true at standdown is not a board.
• Design documents linked to the tasks they govern.
• Comments, where a human leaves direction and an agent leaves reasoning.

The operating loop

One work item at a time. One dispatch. One commit.

1. PULL     the next unblocked task from the board
2. READ     its linked design document before touching anything
3. RED GATE run the verifier first: it must fail
4. DELEGATE brief an executing session, or build it yourself
5. PROVE    re-run every claimed command; exit codes decide
6. OBSERVE  read the diff hunk by hunk
7. GATE     resolve the approval lane, posting reasoning
8. SHIP     flip status, commit that item alone, record progress

Why the red gate comes first

If the check is already green before you start, the work proves nothing. You cannot tell a correct implementation from a check that never runs, a filter that matches nothing, or a test asserting something already true.

Running the verifier first also catches stale work cheaply. In practice a meaningful share of queued tasks turn out to be already done, built under a different card or made moot by a later change. A red gate that comes back green in one command costs seconds and saves the hour you would have spent reading code to implement something that already exists.

Why one commit per item

Git history stays one-to-one with the board. Every commit’s subject names its task. When something breaks three days later, the path from symptom to decision is one git log away.

Verification discipline: the heart of the pattern

This is the part that distinguishes the methodology from “run several agents at once.”

A report is evidence, not instruction

When an executing session reports “suite green, 49 checks, zero failures,” the coordinator’s job is to find out whether that is true. Not because agents lie, but because the thing they are reporting on and the thing they checked are often two different objects.

One pattern worth internalizing: a session wrote a commit hash into a log file by hand, then verified it with git cat-file, against the short hash sitting in its shell rather than the string it had written. Both checks passed. The file contained a hash that resolved to nothing. The check and the record were two different objects, and only one was tested.

The rule that falls out: verify the artifact by reading the value back out of the artifact , never from the variable you think you wrote there.

The defect class to watch for

The single most common failure in agentic engineering is an instrument that reports success for work it did not do. It has many shapes.

Shape	What it looks like	How it fools you
Vacuous assertion	A test that passes whether or not the feature works	Deleting the thing under test leaves it green
Silent no-match	A grep, filter, or predicate that matches nothing	Zero findings reads as “clean”
Errored check	A command that failed to run at all	The error is swallowed, absence reads as evidence
Wrong reference	A filter keyed on “newer than X”	Anything that happened in between slips through
Stale premise	A check whose expected value was read off broken code	It passes the bug it was written to catch
Scope mismatch	A green check over a subset presented as the whole	The denominator is never stated

The general defense: every check that can fail to match must say so. A count of zero and a failure to run must be distinguishable. And an absence assertion needs a positive control in the same run, because if nothing ran, “nothing bad happened” passes.

Prove a positive before believing a negative

Before concluding something is absent, prove your instrument can find it when it is present. Point the check at a known-good case first. A tool that reports “clean” and a tool that is broken produce identical output.

Durable channels beat ephemeral ones

Sessions can message each other directly. That channel is genuinely useful. It is how a coordinator answers a question mid-run, and how an executing session flags a contradiction rather than working around it.

But it is not reliable enough to depend on. A message can be queued behind a busy session, held for approval depending on the receiving session’s permission mode, or expire undelivered. Silence is not agreement.

So anything that must arrive goes in a durable channel.

• Committed files. A brief, a handoff document, a constraint. Sessions read the repository at startup.
• Board cards and comments, where work-specific context belongs.
• Share links. Most boards can render a task or document as agent-ready text at a URL. Put Context: <url> in a launch prompt rather than pasting the context into it. The prompt stays short, and the context stays where it is maintained.

A message is a nudge. A file is a contract.

Where things live

A small discipline that pays off: keep durable policy separate from ephemeral work content.

Policy directories hold the contract that governs every cycle, meaning the loop, the routing rules, and the standards. Long-lived, reviewed, rarely changed. One-off briefs, task context, and session-specific instructions belong on the board or in a scratch directory.

Mixing them means that in six months nobody can tell which files still govern anything.

Timeboxing: surfacing without stopping

A long autonomous run should report on a cadence rather than disappearing for hours and returning with a wall of diff.

The rule that makes timeboxing work: the interval decides how often you surface, never where the work stops. When the timer expires mid-item, finish the item, verify it, commit it, then report. Cutting a run mid-task strands work in the state that is hardest to recover, which is half-applied, unverified, and impossible to describe honestly.

A checkpoint is a surfacing moment, not a permission request. The report goes out and the next item starts in the same turn. If you catch yourself writing “shall I continue?”, delete it. A human who is watching will interrupt, and a human who is not has just had their run killed by a question.

Report what is proven , not what was attempted. An item without a verification result is carried, not done.

Practical mechanics that cost time to learn

These are small, and each one has a failure mode that looks like something else.

Verify a spawned session actually started. Launchers report that a workspace was created , which is not the same as an agent running. Check for the process, and check its working directory:

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

Capture the reference timestamp immediately before the launch. A filter keyed on “newer than the last session” will happily admit an unrelated session that started in between, and if that one has a different working directory, a healthy launch looks broken.

Session names are not addresses you can guess. Whatever name you gave a workspace is often not the name the messaging layer uses. Re-list the live sessions before addressing one, and do not reuse a name you read earlier.

Short identifiers are display prefixes, not keys. Boards commonly show a truncated ID. Padding it out into a full-length identifier produces a well-formed value that does not exist. Resolve it by searching for a distinctive label substring instead.

Search for the label, not your paraphrase. A log entry’s title is usually the writing session’s framing of what it did, which is not the card’s actual label. Searching for the former finds nothing and reads as “no such card.”

In a shared working tree, never use a bare commit. git add <path> followed by git commit commits the entire index , including anything a concurrent session has staged. Use git commit -- <paths> so the commit takes only what you named.

When to use this pattern, and when not to

Use it when:

• The work spans more sessions than one context window holds.
• Multiple work streams can proceed in parallel.
• Correctness matters more than speed, and a wrong “done” is expensive.
• The project will outlive any single session’s memory.

Do not use it when:

• The task is a single well-scoped change. One session, no ceremony.
• You cannot afford the coordination overhead. The pattern spends real tokens on verification that produces no code.
• There is no durable store. Without one you are not running this pattern, you are running several sessions and hoping.

The overhead is the point. You are buying the ability to trust the result.

Getting started

1. Stand up a durable board. One project, a handful of goals, tasks with dependency edges. Make sure your agent can reach it over an API or MCP.
2. Write the contract down. One file that states the loop, what “done” means, and the standards. Commit it. Every session reads it at startup.
3. Run one coordinator and one executor. Do not start with six. Get the verification loop honest with two.
4. Add a handoff artifact. A single file the coordinator updates at the end of every session with the current state and anything learned. This is what makes sessions compound.
5. Keep a lessons log. When something surprises you, write it where the next session will read it, before that session ends.

The measure of whether it is working is not how much code gets written. It is whether, at any moment, you can ask “what is the state of this work?” and get an answer that is true.

Closing thought

The instinct when AI coding agents underperform on long work is to reach for a better model or a bigger context window. Both help. Neither addresses the actual constraint, which is that nobody is checking. That is the same gap behind the 70% problem, and behind every agent that operates a live system without a read-back step.

A coordinating session that writes no code but knows what is true is worth more than another executor. That is an old lesson from human organizations, and it turns out to transfer.