Introducing the Coordination Layer for Multiplayer Agentic Coding

Software is no longer written by one mind at a time. The better agents get, the more autonomy we hand them, and the less human intent sits behind each line they write. Multiply that by every person on a team, each running several agents at once, and a growing share of what your codebase does is unintended, and no one, human or machine, can see it in its entirety.

Today we're introducing GLAD, the layer that can. It keeps one live graph of every decision made by every person and every agent, fed by every prompt and every reply, and a classifier running beside your agents places each new decision against all the others the moment it is made.

01More autonomy, less intent

Autonomy compounds. An agent left to run for an hour makes more choices than its person could ever review. Almost every one looks reasonable in isolation, and so each passes review without anyone asking whether it was meant. Nor can the agent be trusted to notice. In a study of 20,574 real coding-agent sessions, agents self-corrected in just 3% of the misalignments with a visible outcome; in the other 97%, a developer had to push back or take over.¹

What goes wrong lives between those choices, in the gap between what a person meant and what their agent did, between one agent's assumption and the next one's, and between two people who never learned they disagreed until their work collided on main. Code review was built for one author and one change at a time, so it has no way to see across a team, and every agent you add widens the part of the codebase it cannot see, at a point where developers already report spending more of their week reviewing AI-written code than writing new code, 11.4 hours against 9.8.²

02Memory is not coordination

The industry has not stood still. Its first answer was to write things down: rules and skill files, composed by hand and lately passed across whole teams, so that every agent starts from identical instructions. Hand an agent those files and it will follow them faithfully, for exactly as long as they stay true. Nothing checks whether the code still honours them, and nobody is told when it stops.

Its second answer was to record everything. Every session, every prompt and every line of an agent's reasoning, preserved and made searchable, so that when something breaks a team can find out why. That is memory, and memory has real value: it tells you what an agent knew, and in what order it came to know it. What it cannot tell you is what anyone meant, and it is consulted only after the merge, once two agents have already built the same thing two different ways.

The two could hardly be built more differently, but they rest on the same assumption: that coordination is a matter of record-keeping. The reduction of coordination to an archive seems to us misplaced.

We take the other side of that assumption. A team stays coordinated only if something is present where each choice is made, while it is being made. Agreement then stops being something a team reconstructs after the merge and becomes a standard every agent is held to as the work unfolds.

03A shared mind for the whole team

GLAD gives a team of humans and agents something it has never had: one shared understanding of what has been settled, by whom and why.

It begins with a person's own words, which GLAD reads independently of the agent they were addressed to, so that what a person decided is kept in a record their agent has no hand in. Each agent, in turn, accounts for itself: the choices it made, and the alternatives it weighed and set aside. Whatever has been settled is then carried ahead of the work, into every agent that might touch it, and every change that lands is measured against it.

Catching a collision turns out to be the easier problem; the harder one is deciding who, if anyone, should hear about it. The relationship between a person and their own agent is already delicate, because the agent is meant to act on the person's behalf without asking about every detail, and it becomes far more delicate once several people and their agents share one codebase, each with authority over their own work and none over anyone else's. GLAD is built for minimum invasiveness: it resolves whatever can be resolved without a person, steers an agent back to what its own person meant instead of interrupting them, and saves a person's attention for the case that truly needs it, two people who disagree, telling both of them the moment it happens, so the disagreement is settled while it is still one line of code instead of a week of work built on both sides of it.

04Trace any line back to its intent

Agents are not the only ones who lose context. The people on a team carry it too, and theirs fades fastest of all. Within days, most can no longer distinguish the decisions they made from those their agent made on their behalf. Where agents made most of the decisions halfway through a run, nobody is left to explain why the code works as it does. In a survey of 340 engineering teams, half named ambiguous or missing acceptance criteria as the biggest cause of their delays and rework.³

GLAD makes intent traceable. Every decision is attributed to the person or agent who made it, in their own words. Nothing is ever overwritten, and a change of mind points at the decision it supersedes, so the record stays complete and auditable.

Open any mechanism and trace it back, through every choice that shaped it, to its originating prompt, and see what depends on it before you change it. A bug leads straight to the decision that caused it, and a new engineer, along with their agent, can learn why the codebase is built as it is without anyone who built it in the room.

05Why did nobody tell me?

We wanted to know how many collisions a team catches before merge, with GLAD and without it.

We set up a small simulated team on cal.com, an open-source scheduling app: a product lead and an engineer, each working with their own Claude Code agent, running Opus 5.5, on their own branch. Together they built a feature cal.com does not have, attendee reconfirmation, through a fixed sequence of prompts, identical in every run. That sequence held 24 collisions, moments where one person's work would conflict with the other's, with what their own agent built, or with code already merged. Twenty-three of them materialised.

We ran it once as 37 short prompts and once as 10 long-running prompts, most of which kept an agent working for 20 to 60 minutes. Each was played out twice, once with GLAD and once without. Without GLAD, the agents could still read each other's branches, as they would on a shared remote. Before merge, an external validator, another Opus 5.5 agent with full access to every branch, pull request and session, audited the work for collisions.

On their own, the agents caught 15 of the 23 collisions, and the external validator raised that to 17. With GLAD, the team caught 22, and 11 of those were stopped before a single line of conflicting code was written. Put simply, GLAD catches collisions as they begin, while the validator finds them only at merge, after a median of 764 to 1,227 lines have been built on top of each one. All of this ran in real time, adding a median of 1.9 seconds to each prompt and 0.2 seconds to each tool call, while GLAD's judge cost between 6 and 28 cents a prompt.

06Get started

GLAD works with Claude Code and Codex CLI today. Sign up for a free week to get an install token, then install the CLI with it:

$ npm config set @abloh:registry https://npm.glad.abloh.dev/
$ npm config set //npm.glad.abloh.dev/:_authToken <your token>
$ npm install -g @abloh/glad

Then run glad login and glad arm once in your repository, and keep working as you do now. Getting started has every step.

For teams, GLAD runs on your own infrastructure, in a private cloud or on-premise. Just get in touch and we will set it up with you.

We're building GLAD to be the coordination layer for multiplayer agentic coding, because once every interaction within a team, between its people and its agents alike, answers to one shared understanding, everything else follows from it: debugging that starts at the cause, onboarding that starts at the why, and conflicts caught before they grow.