A shared task board for AI agents that need to wait

Coordination beyond a conversation

An AI assistant that starts an hour-long data job needs somewhere to leave its unfinished business. Keeping it repeatedly checking for results can consume model calls; ending the conversation without a registered wait risks leaving the work stranded.

In The Agent Board: Kanban for Machines, Tyler Hunt, Donald Nguyen and Gurbinder Gill describe Corvic’s approach: a shared task table that lets agents stop running and resume when something changes. Their November 3, 2026 arXiv preprint combines a system design, a live deployment case study and three small simulations. It is not a comprehensive production evaluation.

The authors’ central argument is that persistent agents need more than computers that remain available. They also need a durable place to record responsibilities, hand over work and wait for other agents, software systems or people.

A task card becomes a handoff

The Agent Board resembles a human team’s kanban board. Each task has structured fields, including an identifier, topic, status and assignees, alongside a free-form description.

The distinction matters. Ordinary system logic uses exact fields to route notifications. Language models interpret the prose describing the work and its dependencies. The authors call this combination “semi-semantic”: structured routing with flexible, written coordination.

An agent can watch a task, a topic or the entire board, then end its turn. According to the design, a blocked agent holds no running process, open connection or scheduled poll. Its stored history and watch records remain, so waiting still requires storage, but not a continuously active agent.

A matching post starts another turn. Watches expire after firing and must be renewed if needed. The mechanism suppresses notifications about an agent’s own posts and sends only one notification when a single post matches several of its watches.

The Board Keeper interprets events

A system agent called the Board Keeper connects the board to non-agent activity. When a pipeline finishes, it reads waiting tasks and posts the outcome into those it judges relevant. It can also create a worker when a task requests a kind of agent rather than a named instance.

Registering a watch wakes the Keeper to reconsider known events. This addresses a timing problem: an event might finish just before the waiter subscribes. However, reconsidering an event does not guarantee that a language model will interpret the waiting condition correctly.

Coordination rules sit above this machinery as loadable instructions called policy kernels. They describe patterns such as delegation, parallel work, review and human approval. The board does not enforce their role restrictions or workflow transitions.

Waiting costs stayed flat, but simpler won

The waiting-cost pilot used a simulated clock, a trivial remote job and one small commercial language model. Across 400 runs covering several strategies and durations, the simulated board consumed roughly 920 tokens and three model calls per task from 10 minutes to 24 hours.

At 24 hours, naive polling consumed about 152,025 tokens—roughly 165 times the board’s consumption. These are token measurements, not production dollar costs.

Yet a plain external watcher was cheaper than the board throughout. A script that called the agent when the job finished used about 205 tokens and two model calls, with lower reported mean wake latency. The board’s proposed advantage is therefore not the cheapest possible waiting, but prose-based conditions, shared records and worker allocation.

The comparison with holding a tool call open also depended on an assumed 60-minute timeout, not a measured infrastructure limit.

Reliable handoffs require explicit facts

In a separate synthetic matching pilot, the Keeper correctly handled 241 of 250 genuine wake opportunities and produced no false wakes across the tested boards. It missed nine genuine opportunities, or 3.6%. A missed notification can leave an agent waiting indefinitely. The boards contained only four to seven waiting tasks; crowded or ambiguous boards were not tested.

Another pilot examined whether a written task note could replace a long conversation history. Notes explicitly listing four required facts supported successful resumption in all 20 trials at each tested history length. Without that checklist, agent-written notes succeeded in only one of 20 trials at the longest history.

The checklist reduced the resuming prompt, but writing it made total token consumption higher than using history for a single resumption. The benefit was conditional, not automatic compression.

Visible work is not guaranteed success

The live case study exposed a separate failure: all three failed workers among 16 delegations were recorded as done. The authors report this as evidence of a status-reporting defect, not a general failure rate.

Other gaps remain structural. Concurrent replacements can overwrite updates; instructions do not ensure exclusive ownership; dead workers can leave tasks unfinished; and prose dependencies prevent structural deadlock detection. Completed or failed tasks also leave the board after a day, limiting its role as a lasting archive.

The proposed WaitBench benchmark would test more of these properties, but remains a design. Cross-vendor coordination is likewise an ambition, not a demonstrated deployment. The paper’s strongest evidence supports a narrower conclusion: durable waiting is feasible, while dependable interpretation and handoff remain unresolved engineering problems.