Running a fleet of AI agents on one task board

The moment you run more than one AI agent against the same task list, a new problem shows up that a single agent never hits: two agents can both see the same ready task and both try to claim it. A to-do app built for one user checking things off has no reason to solve that. An AI agent to-do app has to.

The double-claim problem

If "claim a task" is just a status update, two agents polling the same queue at the same moment can both read it as available and both start work on it — wasted effort at best, conflicting results at worst. The fix isn't a convention agents are supposed to follow; it's making the claim itself atomic, so the second agent's attempt simply fails to find anything.

How Done keeps a fleet from tripping over itself

• next_task — an atomic dequeue. It claims the single highest-priority ready task and returns it; a second agent calling it a moment later gets whatever's next, never the same task.
• release_task — hands a claimed task back to the queue if an agent can't finish it right now, instead of leaving it stuck in limbo.
• fleet_status — a live snapshot of every task an agent currently holds a claim on, how long it's held it, and whether the lease has lapsed.
• Run budgets — start_run, check_budget, and end_run bound how much any single session can do, so one agent can't quietly consume the whole queue.

What fleet_status actually shows

Before grabbing a task, an agent — or you — can call fleet_status to see exactly what's already claimed across the fleet: which task, which agent, how long it's been held, and whether the claim has lapsed (meaning whoever held it went quiet and the task is fair game again). It's the same visibility you'd want walking into a room where several people are already working.

Designing a fleet workflow

There's no single right shape. Some setups run one generalist agent in a loop calling next_task until the queue is empty. Others split by project or role — one agent for a specific project's backlog, another for a recurring maintenance queue — using scoped tokens to keep each one's view limited to its lane. Teams pooling several people's agents on one board tend to lean on fleet_status the most, since that's exactly the visibility problem shared boards create.

Auditing what the fleet did

Every agent session runs as a run, logged with its own tool-call and time budget — start_run opens it, end_run closes it with a summary and outcome, and check_budget tells an agent (or you) how much of that session's allowance is left before it's refused outright. list_claude_shipped separately gives you a clean feed of everything an agent has actually marked done, newest first — useful for a standup, a retro, or just answering "how much did the agents get through this week."

When a fleet isn't the right shape

Most people don't need this. A single connected agent working through a queue in priority order covers the common case fine, and fleet_status and next_task's atomicity cost you nothing if you never run a second agent. This machinery earns its place specifically when you're running several agents in parallel, or a team's Teams-plan board has more than one person's agent working the same shared workspace.