Coordination Is Not Authorization

A category is forming around agent collaboration. Four of the questions it asks are about coordination. The fifth is not, and it has been quietly folded in with the others as though it were the same kind of problem. It is not.

A category is forming around agent collaboration. The pitch runs like this. Intelligence is abundant now. The bottleneck is coordination. Thousands of autonomous agents are about to work alongside each other, and they need infrastructure to coordinate and safely act on shared reality.

The questions that category asks are good ones. Who is working on what. What is still true. What changed while an agent was reasoning. Can two agents safely modify the same thing. What should an agent be allowed to act on.

Four of those are coordination questions. The last one is not, and it has been quietly folded in with the others as though it were the same kind of problem. It is not the same kind of problem, and putting it in the same product is how the next decade of governance gets built wrong.

The premise that has failed before

Enterprise data governance has been trying to answer "what is still true" for thirty years. The answer was always the same in shape. Appoint a master. Build the canonical record. Reconcile everything against it.

Master data management gave us the golden record. The data warehouse gave us the single source of truth. The lake gave us the same idea with cheaper storage. The catalog gave us an index of the mess and called it governance. Every one of them asked an organization to designate one place where reality lives.

Every one of them failed the same way. The canonical copy was stale the moment it was written. It had to be complete to be correct, and it was never complete. The systems that actually ran the business kept operating on their own state and reconciling later, which is another way of saying the master was a report, not an authority.

The failure was never execution. Some of those programs were run well. The premise was wrong.

Why agents make the premise worse

Software primitives were designed around humans using software. That assumption is doing more work than anyone noticed.

A human sits between the read and the write. They pull up a record, look at it, think, and act. The gap is seconds or minutes, and the tolerance for staleness was built around that gap. Approvals were valid for a day because a day was roughly how long it took a person to act on one.

Agents close that gap to milliseconds and then open a different one. An agent reads state, reasons for ninety seconds, and acts on a world that no longer exists. Run a thousand of them concurrently against the same systems and the staleness window stops being an edge case. It becomes the operating condition.

The coordination category has seen this clearly. Its answer is to hold shared reality on the agents' behalf, so that every agent can ask one place what is true.

That is the master record again. Different subject, same premise. It has to be complete to be correct, it will not be complete, and the moment it disagrees with the system that actually executes the transaction, the system wins.

The principle

Coordination is not authorization.

Coordination asks whether a write is safe. Two agents are touching the same object, so order them, lock the row, resolve the conflict, keep the state consistent. This is a real problem with sixty years of prior art. It is called concurrency control.

Authorization asks whether the write should exist at all. Not whether this action collides with another action. Whether this actor, right now, against this target, under current policy and current standing, should be permitted to do this thing.

The two questions have different owners and different architectures.

Concurrency control gets absorbed. Databases absorbed locking. They did not buy it from a coordination vendor, because the party that owns the write ordering has to own the write. Any agent coordination layer that tries to hold write ordering across systems it does not control is negotiating for authority those systems will never cede.

Authorization does not get absorbed, and the reason is precise. It is cross-system by construction. An agent action that spans four systems of record cannot be decided by any one of them, and none of the four can produce a record of the decision that the other three would trust. That gap does not close as any individual vendor gets better. It is structural.

Which means the correct architecture for "what is still true" is not a store. It is a recomputation. Ask the authorities that already own the answer, at the moment of the action, and treat them as peers rather than as inputs to be averaged. Where they disagree, deny. Nothing is copied, nothing is mastered, and what crosses the boundary is a decision rather than data.

Computed, not stored. Federation over mastery. The same principle that was right for customer records is right for agent actions, and for the same reason.

What this means for people building and buying

For builders in the coordination category: separate the fifth question from the other four. Write ordering and permission are different products with different trust boundaries. A layer that holds both becomes the thing every system of record has to trust completely, which is exactly the position no enterprise will grant to a new vendor.

For buyers: ask where the copy lives. If a vendor's answer to "what is still true" involves a store they maintain, ask what happens when their store and Workday disagree. If the answer is that their store wins, that is master data management with a new customer segment. If the answer is that Workday wins, ask why the store exists.

And the anti-positioning is worth stating plainly, because knowing what you are not is how a category gets defined. An authorization layer is not master data management, since there is no canonical record. It is not integration middleware, since no data moves. It is not a warehouse, since nothing is copied. It is not a system of record, since source systems stay authoritative. It is not a vendor connector, since the whole point is deciding across vendors.

None of this is a complaint about the coordination category. Funded teams arriving independently at "what should an agent be allowed to act on" is the strongest validation the Authorization Gap has had. The question was fringe eighteen months ago. It is now being discovered by people who came at it from the opposite direction, which is usually what happens right before a category becomes obvious.

The correction worth making is only about where that question belongs. It is not a feature of coordination. It is the layer underneath it.

Knowing what every agent is doing tells you nothing about whether any of them should be.

Cross-link: this piece extends the runtime-authorization arc opened in N° 029 (Detection Is Downstream of Authorization), given academic backing in N° 032 (The Authorization Gap Has a Literature Now), and given its placement requirement in N° 033 (A Governor You Can Import Is Not a Boundary). Where those three named the timing, the proof, and the placement of authorization, this piece separates authorization from the adjacent question of coordination and argues that only one of them absorbs into existing infrastructure. Extends the foundational placement argument from N° 020 (The Authorization Gap). The federation-over-mastery lineage is developed most fully in N° 004 (Federation, Not Mastery) and N° 011 (The Control Plane Cannot Be Where the Data Sits). Concurrency control history references standard database systems literature (Bernstein, Hadzilacos, and Goodman, 1987; Gray and Reuter, 1993); no external verification needed for these canonical CS references. Master data management history is drawn from the last three decades of enterprise-governance practice; no specific vendor or project is named in the essay. For the architecture of decisions that cross systems without moving data: A hub and its spokes.