Durable Coordination for Agents That Outlive One Model Call

A proposed coordination layer called the Agent Board lets AI agents post, watch, and block on tasks that outlast a single model call, span multiple agents, or wait on external systems. In the paper’s small simulated pilots, the Board Keeper missed 3.6% of real wake events ¹.

That number matters more than it might look. A durable task record can make unfinished work visible. It can’t, by itself, show whether work will resume after a failure or reach a human when something goes wrong. The reported missed wakes show that wake failures occurred in the pilots; recovery from those failures is a separate question ¹.

The Agent Board is a proposal built inside the Corvic harness. The reported evidence consists of a trace from a live board and three small simulated pilots; it does not establish broad production deployment ¹. The question worth asking isn’t whether it’s ready to adopt. It’s whether a shared AI agent task board gives platform teams a clearer way to track ownership and handoffs than extending a conversational agent harness, and what guarantees they’d need before trusting it with real work.

Why long-running AI agents need durable task coordination

The paper describes agent harnesses as tending toward a single-threaded shape: one agent, one history, one machine, one sitting. It presents the Agent Board as a way to represent work that spans agents, outlasts a model call, or waits on a non-agent system ¹.

Its central object is a shared task table. Each task pairs exact fields the system routes on with a free-form body that language models read ¹. The paper compares the design to a human team’s kanban board and to an operating-system scheduler for agents, while also describing where the scheduler analogy breaks down ¹.

Analysis: The proposal’s bet is to separate task coordination from a single agent turn. That may help when work crosses agents or waits on external systems. The abstract describes a durable board, but does not establish how tasks behave through failures of the board, Board Keeper, or workers. Those are operational properties to test, not assumptions to make. If your concern is how agents carry context rather than tasks, that is a related but different problem; see agent memory and the context engine.

How agent task coordination works on the board

Agents post tasks, watch them, and block on them. Blocking ends an agent’s turn rather than holding a process open while it waits. A matching post later wakes it ¹.

A system agent called the Board Keeper carries events from non-agent parts of the harness onto the board and matches them to waiting tasks by reading their prose. If a task names a kind of agent rather than a specific instance, the Board Keeper allocates an agent to fill it ¹.

So the design mixes fixed routing fields with language-readable descriptions. That may help with matching logic that is difficult to encode as strict rules, but it also raises an operational question: when an intended wake doesn’t happen, how would an operator find and recover the task? In the pilots, the Board Keeper produced no false wakes but missed 3.6% of real wakes ¹.

Board versus conversation: what actually changes

A conversational harness organizes activity around an interaction. The Agent Board organizes it around tasks that can wait, be watched, change hands, or resume on an external trigger ¹. The difference matters when a workflow needs to continue while no model call is running.

A board can surface ownership and pending work as visible records. But a record isn’t an operating contract. The paper describes loadable “policy kernels” that assign meaning to statuses and roles for a given work pattern, and says the board itself does not enforce those policies ¹. The board alone therefore doesn’t determine which statuses are valid, who signs off on a handoff, when to retry, or how a stuck task gets escalated.

Analysis: This isn’t a binary choice between board and conversation. You can add persistent agent state to an existing harness, or use a board as a separate coordination layer. The practical comparison is whether either option makes waiting, ownership, and recovery explicit enough for your workflow — and whether its control logic can enforce the rules that matter. A board may clarify where work stands; it does not by itself demonstrate that the process behind it is safe or complete.

What the evidence shows about the Agent Board

The paper reports a trace from a live board and three small simulated pilots, not a production deployment at scale ¹. That limits what can be concluded from the excerpt about performance, reliability, or operating cost at larger workloads.

In the pilots, board wait cost stayed flat as wait length increased, while naive polling grew about 165-fold. A plain external watcher was cheaper than the board ¹. Treat these as results from the tested setup, not a general cost ranking for other architectures.

The wake numbers deserve the same scrutiny. The Board Keeper produced no false wakes, but missed 3.6% of real wakes in the pilots ¹. The excerpt reports the misses but does not report a mechanism for detecting or recovering from them.

Analysis: This is evidence that the board is worth evaluating, not evidence that it is a ready-made reliability layer. The cost result argues against assuming a shared board beats a simpler external watcher by default. Measure it for your own workload rather than carrying over the paper’s numbers.

What to validate in handoffs and recovery

A task could remain visible on a board yet fail to progress. A missed wake could leave it waiting after the triggering event has arrived. Unclear ownership could leave work abandoned, duplicated, or stalled. These are operational risks to investigate; the excerpt does not establish how the board, Board Keeper, or worker processes behave during failures ¹.

Before trusting the pattern, test the failure path, not just the happy path:

• What happens if the board, Board Keeper, or a worker restarts mid-wait?
• Can an external event arrive late, arrive twice, or replay after recovery?
• How would stale ownership be detected and expired?
• What would prevent a retry from duplicating completed work?
• How would you find a missed wake or a task stuck indefinitely?

These are acceptance tests for a team to run, not behaviors established by the paper. Define the task fields, status conventions, and policy-kernel interfaces for your implementation before treating the board as an operational control surface.

Analysis: Consider designing recovery around reconciliation, not just retries. A retry repeats an action; reconciliation checks recorded task state against the external system’s actual state and determines what remains to be done. Whether that is necessary depends on the cost of duplicate or missed work in your workflow. The pilots’ 3.6% missed-wake rate makes the question worth testing, but does not establish which recovery design is right ¹. Telling a current fact from a stale one is a recurring problem in state tracking; StateBench is related reading on that theme.

Who enforces policy, and who’s watching

The policy kernels assign meaning to statuses and roles, but the board itself does not enforce those policies ¹. That distinction matters for approval steps, separation of duties, and escalation. Representing a required human review as a task on a board is not the same as preventing an agent from skipping it.

Before adoption, decide which transitions require human approval, what happens when an approver is unreachable, who receives an escalation, and how operators will surface tasks stuck in limbo. Test both the expected path and cases where an agent or external event might route around a required step.

Analysis: One possible boundary is to keep enforcement in explicit control logic and use the board for coordination and shared context. That is not a universal architecture; it is a way to avoid treating a visible task status as proof that policy was followed. The paper says the board does not enforce its policy kernels, so teams considering the pattern need to decide where enforcement belongs ¹. Permissions are part of that decision; AI agent permissions must follow actions across interfaces covers the broader authorization question.

What to validate before you adopt this

Start with a narrow workflow that includes an agent handoff, a wait on an external system, a human decision point, and a forced restart of a worker or coordinator mid-task. Track task age, time to wake, missed-wake rate, duplicate work, abandonment, and the manual effort required for recovery. These are proposed validation criteria, not measurements reported by the paper.

Compare the board with two alternatives: a conversational harness extended with task state, and a plain external watcher. The paper found the watcher cheaper in its pilots, so don’t assume the board wins on cost — measure it ¹. Test contention too, including concurrent postings, long waits, and large task tables. The reported pilots were small, so they do not answer how performance or cost changes at larger scale ¹.

Write down in advance how events will be replayed, how missed wakes will be discovered, how ownership will expire, how retries will avoid duplicating work, and how a human will be involved. Otherwise, a durable task table could give you a well-organized record of work that never gets done.

FAQ

What is an Agent Board for AI agents? A proposed durable, shared task table and coordination layer for work that spans agents, outlasts a model call, or waits on non-agent systems ¹.

How does an Agent Board wake a waiting agent? A blocked agent ends its turn. The Board Keeper later matches an incoming event to a waiting task, and a matching post wakes the agent ¹.

Is the Agent Board production-ready? The excerpt does not establish production readiness. It reports a live-board trace, three small simulated pilots, and a 3.6% rate of missed real wakes in those pilots ¹.

Is a board always cheaper than polling or a watcher? No. In the reported pilots, board wait cost stayed flat as waits grew, while naive polling cost grew about 165-fold. A plain external watcher was cheaper than the board in those tests ¹.

What are the main risks in agent task coordination? Practical risks to test include missed wakes, failure recovery after a board or worker restart, duplicate or abandoned work, unclear ownership expiry, and policy enforcement gaps around human review. The pilots report missed wakes, and the paper says the board does not enforce policy kernels; the other items are validation questions for a team’s implementation ¹.

Sources

¹ “The Agent Board: Kanban for Machines; Durable Coordination for Agents That Outlive the Conversation,” arXiv, Nov. 4, 2026. https://arxiv.org/abs/2611.04100