Claude Fable 5.2 Multi-Agent Coordination: A Postgres Task-Claiming Pattern

Claude Fable 5.2 agents coordinated through Git and a shared Postgres database in Anthropic’s November 9 experiment. For developers building smaller agent teams, the useful question is how to claim work without duplicating it, recover a failed worker and verify completion before another agent depends on the result.

Anthropic reports that 1,000 agents reproduced a formal proof of Fermat’s Last Theorem in 28.7 hours. This was a controlled experiment using an early model, prepared mathematical inputs and an external proof checker. It was not a demonstration that an arbitrary business workflow becomes reliable when you add 1,000 workers.

The technical account describes agents using a database for assignments, notes, subtasks and completed work. That is a useful starting point. A production queue also needs an answer to a less impressive question: what happens when a worker claims a task and disappears?

Separate task ownership from agent conversation

Consider three coding agents updating an SDK integration. One handles request construction, another updates response parsing and a third writes migration tests. They need shared context, but they should not all edit the same implementation because each believes it has been assigned the urgent part.

Give every task a stable ID, a status, an owner, a claim version and a completion artifact. Keep discussion in a separate notes stream. A message saying “I’m taking this” is useful context, but it should not be the system’s only record of ownership.

The database should decide who owns the task before the model starts working. This lets the harness reject a second claim even if two agents independently choose the same task. It also makes ownership inspectable without reading a long conversation.

Claim one ready task atomically

PostgreSQL supports row locking with FOR UPDATE SKIP LOCKED. Its SELECT documentation specifically identifies queue-like tables as a use case, while warning that skipping locked rows gives an inconsistent view unsuitable for general-purpose queries.

The following is an illustrative queue design, not Anthropic’s schema or a tested reproduction of its experiment:

CREATE TABLE agent_tasks (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  description text NOT NULL,
  status text NOT NULL DEFAULT 'ready',
  owner text,
  claim_version bigint NOT NULL DEFAULT 0,
  claimed_at timestamptz,
  artifact text
);

A trusted worker service can claim a row with one statement, binding $1 to the authenticated worker identity:

WITH candidate AS (
  SELECT id
  FROM agent_tasks
  WHERE status = 'ready'
  ORDER BY id
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
UPDATE agent_tasks AS task
SET status = 'running',
    owner = $1,
    claim_version = task.claim_version + 1,
    claimed_at = clock_timestamp()
FROM candidate
WHERE task.id = candidate.id
RETURNING task.id, task.description, task.claim_version;

Run this in a short transaction and commit before calling the model. Holding a database transaction open throughout a long agent run creates a different operational problem. When no row is returned, the worker should wait or exit rather than inventing an assignment.

The UPDATE documentation explains that RETURNING reports the rows actually changed. That returned task ID and claim version become the worker’s handle for subsequent updates. Do not let an agent choose another worker’s identity by changing a prompt argument; the service authenticating the worker should supply it.

Treat a timeout as uncertainty, not proof of failure

A missing heartbeat may mean the worker crashed, lost connectivity or is still running a slow tool. Reassigning its task immediately can leave two workers performing the same action.

A recovery service should first determine whether the old worker can still act. Cancel or isolate it where possible, then make the task available for a new claim. Each successful claim increments the version, so an older worker cannot submit a result under a newer ownership record.

For example, require completion writes to match all three values: task ID, owner and claim version. Also require the current status to be running. An update affecting zero rows means the worker no longer owns that task and must stop trying to complete it.

This only protects the queue. If a worker sent an email or created a cloud resource before losing contact, rejecting its database update does not undo that action. Such tools need their own idempotency keys and reconciliation checks. A task lease cannot provide exactly-once execution across unrelated external services.

Mark work verified before releasing dependent tasks

For the SDK example, a worker’s output could be a commit hash plus the test command and its result. A separate verifier should inspect that exact artifact before moving the task to a verified state. A completion note written by the same model is not independent evidence that the integration works.

Keep dependent tasks blocked until their required artifacts pass. If response parsing changes again, the test task should know which revision it is validating. Otherwise, a green test result can refer to code that is no longer being merged.

Start with a small failure drill before adding more agents:

1. Launch two claim requests against one ready task. Only one should return it.
2. Stop the owner after it claims the task. Recover it without silently losing the assignment.
3. Reclaim the task, then submit the old owner’s completion. It should be rejected.
4. Fail the artifact’s verification. Dependent work should remain blocked.
5. Repeat an external tool request after an uncertain response. Confirm the tool’s reconciliation logic prevents a duplicate effect.

These are acceptance tests for your implementation, not results reported here. Run them against your actual database, worker service and tool integrations.

Keep the experiment’s safety controls in context

Anthropic isolated workers in separate sandboxes and used external monitoring. Its write-up distinguishes the experiment from later safeguards: the reported run used an action-based monitor, with a helper block removing that helper; the later setup adds a parallel reasoning monitor and team-wide stopping after a block.

That distinction matters because copying the database layout does not copy the containment system. Your queue service should enforce allowed transitions, tool access and cancellation outside the agents, and your merge process should check the resulting code. A shared table with broad write access is coordination infrastructure, not a security boundary.

The first useful target is a small team whose work can be recovered and audited. Once ownership, dependencies and side effects survive failure, increasing the worker count becomes an engineering decision rather than an expensive hope.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn agent architectures and engineering decisions into clear stories developers can understand and use.

Book a 30-minute call.