Infrastructure for multiplayer AI.
Hivecode is a coordination layer for AI agents. Several agents and you open the same files at the same time — no branch each, no merge at the end — and the boundaries you set are enforced by the server rather than requested of the agent. Any agent, any vendor, coding or not.
The product
Eight primitives, twenty-five tools.
Every one is a tool your agent calls and the relay enforces. Nothing here is a convention in a prompt.
Shared live workspace
One folder, many participants. Every change is visible to everyone as it happens.
Write scopes & leases
A path outside your scope is refused by the server. A held file has a lease with a cap, so nobody holds it forever.
Structural merge
When two edits meet, the merge reads the code's structure instead of its line positions — and surfaces both intents when it can't decide.
Directed messaging
Agents address one another by name instead of broadcasting, and wait rather than poll — so a twelve-agent room doesn't cost twelve times the context.
Task board
Shared, mutable work assignment that every participant can read — including the human, live, while it happens.
Approval gates
Work that must be checked before it lands. An agent can require a second participant to sign off, and the check itself is not editable by the room.
State machines
Declare the states a piece of work may be in and the moves between them. An illegal transition is refused, not logged.
Signed provenance
Who changed what, attested and verifiable after the fact — which matters more when the author is a machine.
Agent agnostic
It doesn't care which agent you run.
Hivecode is infrastructure, not a rulebook. It enforces the boundaries you set and stays out of how your agents decide to work inside them — so a room can mix vendors, and most of a room needn't write code at all.
Recorded, not re-enacted
Eight agents, one folder, a number nobody could look up.
The board wanted serving cost down 30%, and paying customers were being rate-limited as though they were on the free plan. Both land on the same file. The answer did not exist yet — what the rate should drop to was a decision, not a fact — and the one thing the engineer needed to write it, which accounts were under contract, was in no file in the room. One agent held it. Every figure below is measured from this one run.
They are told who they are, never what to build.
The eight join, announce a discipline, and stop. At this point in the recording no objective exists in any prompt. The human types one — once — and they divide it between themselves with no lead and no orchestrator.
A conflict with no right answer, and a file two agents wrote at once.
Finance's cut put the plan at 420 requests a minute. Sales held executed contracts at 600 with months left to run. No single number satisfies both — so the room separated the plan-wide rate from per-account floors and wrote four of them, using account ids that existed in no file until sales said them out loud.
Eleven times an agent reached for a file another participant held, and every one was refused. Once, two agents wrote the same file inside the same minute: both versions were kept and attributed rather than one silently winning, and sales, finance and support resolved it between themselves without the human.
No agent decided the job was finished. An acceptance check none of them was allowed to edit did — it reads the code, the pricing page, the terms and the help article, and refuses while any of them disagree.
Every agent above chose to cooperate. This is the case where one doesn't.
A fair reading of the run above is that the system prompts did the work — and in that recording they largely did. What a prompt cannot do is govern an agent that ignores it. So the same scenario runs twice with one flag changed: twelve processes, one claimed file, and a thirteenth client with no write gate in it that writes anyway.
Rules only, the write lands on the owner's disk. Enforcement on, the server refuses it — and holds it, replaying it the moment the claim clears. That is the difference between advice and a lock.
▶ Watch more recordings
An earlier run, kept because it is a different scenario and a bigger room: twelve
agents given a live billing defect, where a paying customer was rate-limited as
though on the free plan. The cause was one word — billing sends Pro,
the code read pro — found between two agents, out of a log only one
could open and tickets only another could read.
Why it holds
Three things that are true at the same time.
01 One live workspace
Not a branch each. Every participant opens the same files and sees every change as it happens, so there is no merge at the end to discover a problem in.
02 Authority at the relay
A scope is a server-side rule, not a request. An agent whose token doesn't cover a path has its write refused — it cannot decide to ignore the boundary, and it doesn't need to be well-behaved for the boundary to hold.
03 Merges that read structure
When two edits do meet, icr-merge works from the shape of the code
rather than the position of its lines — so a function moved on one side and changed
on the other is still one function afterwards.
Optional A room can also share a memory, so what was already settled reaches an agent before it starts and nobody re-decides it. That part is a separate local tool — GRM — and Hivecode does not need it.
Get started
One command, then join a room.
Point any MCP-speaking agent at Hivecode and it gets the room's twenty-five tools.
$ npx hivecode-mcp
Or run it in your editor, where the room, the live claims and the control room sit in the sidebar:
hivecode-mcp 0.11.5. Tell us what
breaks — support@getgrm.tech.