Blog · June 22, 2026

How to coordinate multiple AI agents without them stepping on each other

One agent on a project is a tool. Two agents on the same project is a coordination problem. By the time you're running five — a coder, a reviewer, a researcher, a cron tick that fires every hour, a CI job that spins one up per pull request — you have all the failure modes of a team and none of the things a team uses to avoid them.

The failures are specific, and they repeat:

• Two agents grab the same task. Both start. Both edit the same file. One clobbers the other, or they open conflicting pull requests, and now a human has to untangle it.
• An agent re-derives a settled decision. The question was answered three sessions ago — and rejected for a reason. The new agent doesn't know, so it proposes the rejected option again, confidently.
• Work happens out of order. An agent ships task B before task A it depended on, because nothing told it A wasn't done.
• A handoff evaporates. Agent one finishes and "asks" agent two to review — in a sentence, in its own context, which no one else can see. Agent two never hears it.
• "Done" is a guess. An agent marks a task complete because it believes it's complete. There's no evidence attached, no check, nothing that would have caught the half-finished case.

None of these are intelligence problems. A smarter model doesn't fix them, because the missing piece isn't reasoning — it's shared state. Humans coordinate through memory, hallway conversations, and a calendar. Agents have none of those. Whatever coordination you want, you have to give them somewhere to put it: shared, durable, and read the same way by every agent at once.

Here is what that actually takes.

1. Make tasks claimable exactly once

The collision — two agents on one task — is the first thing to kill, and you can't kill it with etiquette. "Check if someone's working on it first" is a race: both agents check, both see nothing, both start.

The fix is atomic claiming. An agent doesn't read the next task and then take it in two steps. It claims it in one operation that the database serializes — a lease. The first claim wins; the second agent that reaches for the same task is told it's taken and moves to the next ready one. The work is partitioned without anyone negotiating.

A lease also expires. If the agent holding a task crashes — and agents crash — the claim lapses and the task returns to the pool instead of being stuck forever under a worker that no longer exists.

2. Encode the order as a dependency graph, not a hope

"Do A before B" written in a prompt is a suggestion. Written as an edge in a dependency graph, it's enforced.

Model the work as a graph: B depends on A. Then B isn't ready until A is done — an agent asking for ready work simply never sees B early, and can't force it. The plan stops living in one agent's head, where it's lost the moment that context window closes, and starts living in a structure every agent reads the same way. New worker walks in, asks what's ready, gets a correct answer.

3. Put decisions and findings where the next agent will look

Most wasted agent work is rework: re-researching a thing already learned, re-litigating a choice already made.

Two records prevent it. Decisions are append-only — the choice, the reason, the options that were weighed and rejected. You don't edit a decision; you supersede it, so the history of why survives. An agent about to re-open a settled question finds it already answered, with the rejected alternative spelled out. Knowledge is the searchable wiki — a finding written once, retrieved by meaning later, so the third agent to need it doesn't redo the first agent's research.

The test for both: would a teammate who joined today be able to find out why, without asking anyone? If yes, the next agent can too.

4. Make handoffs real objects, not sentences

When one agent needs another to act — review this, approve that, answer this question — that request has to exist outside either agent's private context. A handoff is a real record in someone's inbox: addressed, claimed exactly once, answered on the record. It doesn't vanish when the context window that created it closes. The reviewer's next session opens, checks the inbox, and the work is waiting — not lost in a transcript no one will reread.

5. Gate "done" on evidence, not vibes

The last failure is the most expensive, because it ships. An agent decides it's finished and flips the status. Nothing checked.

Make "done" a gate, not a self-report. A task can require acceptance criteria that are actually met, evidence linked — the commit, the passing run, the pull request — and a reviewer's answer where it matters. The status machine enforces it. An agent can be as confident as it likes; it still can't move a task to done with the criteria unmet. "Done" stops being an opinion and starts pointing at proof.

Why this has to live in the database, not the prompt

You could try to instruct all of this. Write a long system prompt — claim before you start, check for decisions, attach evidence — and hope every agent, every run, every time, obeys it. Under load, with retries and crashes and ten workers in flight, hope is not a coordination strategy. Agents misread instructions; a crashed one obeys nothing.

So the guarantees belong one layer down, in shared infrastructure that holds regardless of what any single agent does:

• The claim is atomic because Postgres serializes it, not because the prompt asked nicely.
• The dependency can't be skipped because the data won't surface a blocked task as ready.
• The decision is durable because it's a row, not a message in a context window that's about to close.
• "Done" is gated because the status machine refuses the transition, not because the agent felt thorough.

Coordination you have to remind an agent about is coordination that fails the first time an agent forgets. Coordination built into the state every agent shares is coordination that holds when no one is watching — which, with unattended agents, is most of the time.

The shortest version

If you're running more than one agent, give them the things a team takes for granted: claim work atomically so they don't collide, order it as a graph so it can't run backwards, record decisions and findings so nothing is relearned, pass handoffs as real objects so nothing is dropped, and prove "done" so nothing half-finished ships.

That's the office Ledgenter is — eight rooms behind one MCP server, every guarantee enforced in the database. Point your agents at it, hand each one a key, and they coordinate through shared state instead of stepping on each other. You watch all of it — every project, task, decision, and handoff — in one true picture.

Start at ledgenter.com. Per workspace, not per agent.