Concord MCP makes two coding agents claim files before they collide

Two coding agents that cannot see each other

Concord is a protocol server that lets coding agents running in different tools talk to one another and share the state of the work. Its stated position is deliberately modest: it is not another agent and not an orchestrator, it is the layer around the agents you already run.

The problem it addresses appears as soon as a second agent starts. Each tool holds its own conversation, its own view of the repository and its own idea of what is being worked on, and none of that is visible to the others. Two agents given adjacent tasks will both open the same file, and the collision surfaces when someone reads the diff.

The README's comparison table puts the failure modes precisely: collisions are discovered after editing rather than before, context vanishes when a session ends, ownership is implied by chat history rather than recorded, and a person reconstructs progress from branches. Anyone who has run two agents on one repository will recognise every line.

The audience is narrow and growing: developers who run more than one coding assistant at once and have started relaying context between them by hand.

Five tools, and claiming before editing is the important one

The interface is five operations rather than a large surface, which suits a protocol meant to be called by a model rather than read by a person.

One registers presence, claims or accepts a task, and reports scope overlaps before any editing happens. One reads workspace and task state, an agent's inbox or outbox, or a durable message thread. One records context or sends an immediate prompt or reply to another agent in the workspace. One handles assignment, acceptance, decline, release, reassignment, handoff offers and reopening. One records evidence and marks work review-ready, complete or closed.

Claiming before editing is the part that changes outcomes. Detecting an overlap after two agents have written to a file leaves you reconciling two sets of changes; detecting it at claim time means the second agent picks something else. The README's own demonstration shows exactly that exchange, with one agent claiming a page component, the second being told the file is owned, and the two agreeing a split over an API boundary.

A smaller detail carries real design thought: writes accept an agent identifier, so presence stays current simply as a side effect of working, rather than requiring a heartbeat nobody remembers to send. The read operation surfaces who is present and flags stale claims, meaning a file still owned by an agent that has gone away without handing off. That is the failure this kind of system usually has and rarely detects.

Installing it, and knowing what setup writes

Installation is a global package followed by a single command run inside the repository you want coordinated.

npm install -g @concord-ai/concord-mcp
cd /path/to/your/repository
concord setup

Restarting your agent clients afterwards is required rather than optional, because the registration is read at client startup.

What that setup command touches deserves attention before you run it, and the README documents it rather than leaving you to discover it. It creates a local workspace directory, registers the server across five different client configuration files spanning both the repository and your home directory, and writes its tool instructions into the instruction files those clients read. The stated behaviour is that it merges into existing configuration rather than replacing it, and that re-running is safe.

That is a broad footprint for one command. The merge-rather-than-replace behaviour and the safe re-run are the right guarantees to make, and anyone with hand-tuned agent configuration should still read the list first and commit before running it.

Three flags narrow the scope for people who want less of it: one skips adapter installation, one makes degraded support a hard failure for managed installations, and one writes only the workspace and instructions while leaving registration to you. Offering the strict variant is a thoughtful inclusion, since a setup step that silently degrades is worse than one that stops.

Delivery depends on the receiving tool, and the README says so

The claim is that agents can send each other live, replyable prompts. The qualification, stated plainly, is that live delivery depends on the receiving harness and its session state, with a command provided to report which installed agents are reachable and how messages will reach them.

That distinction matters more than it first appears. Shared state is a file on disk, so it works regardless of what any tool supports. Live delivery requires the receiving client to accept an incoming message into a running session, which is a capability each tool either has or does not. So the guarantees are two-tier: coordination always works, immediate messaging works where the tool cooperates.

Being explicit about that, and shipping a status command to check it, is better engineering than claiming uniform support. The README is equally direct that there is no universal slash command, because commands are client-specific, and that the system works through the protocol tools plus installed instructions on any capable client.

Five clients have their own integration guides, with anything else protocol-capable able to share work state through the same five tools.

Where it will not help

The version is the first thing to weigh. At 0.10.4 this is well before a stable interface, and the tool surface is exactly the kind of thing that changes before 1.0. The most recent releases are small: a performance change reducing redundant overlap and status work, and documentation maintenance. The last push was on 2026-09-11.

The second is that this coordinates agents and does not supervise them. Nothing forces an agent to claim a file before editing it. The claim is a convention the agents follow because their instructions tell them to, so an agent that ignores the instruction edits anyway and the overlap detection never fires. That is inherent to a protocol layer rather than a flaw in this one, and it means the value depends on the instruction text surviving in each client's context.

Third, this is local-first, so the shared workspace is a directory on one machine. Agents on different machines are not covered by what the README describes.

Fourth, the setup footprint discussed above is real. Five configuration files, two instruction files and a home directory entry is a lot of surface for a tool you might be trialling.

Finally, for a single agent it does nothing at all. The value begins with the second concurrent agent and grows from there.

Coordinating through the repository is the alternative

The alternative most teams are using today is the repository itself: a task file that agents read and update, separate branches per agent, or a person relaying messages between two windows.

The difference in approach is when a conflict becomes visible. A shared markdown task list is coordination by convention with no enforcement and no presence, so two agents can both read that a file is unclaimed, both claim it in their own turn, and neither learns of the other until the writes collide. Branch isolation defers the collision to merge time, which is later and more expensive. Human relay works and costs the person's attention, which is the resource the agents were supposed to save.

Concord replaces those with an explicit claim checked at the moment of claiming, plus a message path that does not route through the human. The price is a pre-1.0 dependency and a setup step that writes across your configuration.

For one agent, or two agents on clearly separate parts of a codebase, the repository conventions are enough and adding a protocol server is unnecessary. For two or more agents working the same area concurrently, the difference between detecting an overlap at claim time and at merge time is the whole argument.

MIT terms and what the repository signals

The project is MIT licensed, which for a developer tool that installs into your configuration is the expected and unobtrusive choice.

The repository carries the furniture of a project run deliberately: a changelog, a contributing guide, a code of conduct, a security policy, a releasing document, a documentation directory with per-client guides, an example demonstration, a plugin directory and a protocol server descriptor. Publishing a runnable demonstration of two agents resolving a claim is a better argument than the feature table, because coordination is a behaviour rather than a feature and a behaviour has to be watched.

Upgrade cost should be modest in mechanics, since this is one global package and a re-runnable setup command, and the safe re-run promise means updating configuration after an upgrade is not a manual merge. The real cost sits in the pre-1.0 tool surface, because instructions written into your client configuration reference tools by name, and a renamed operation means regenerating those instructions.

Editorial conclusion

Concord earns its place once you run two or more coding agents against the same repository at the same time and have started relaying context between windows yourself. It does nothing for a single agent, and nothing for agents on separate machines, since the shared workspace is a local directory. Read what the setup command writes before running it, because it touches five client configuration files across the repository and your home directory plus two instruction files, and check reachability with the adapters status command, since the README states live delivery depends on the receiving harness rather than being uniform.

Frequently asked questions

Official sources

1. Get-Concord-AI/concord-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases