The Protocol Cannot Say No

What they are, and the problem they solved

It is worth being concrete about the two protocols, because the case I am making depends on what they do well rather than on any weakness in them.

For most of computing’s history, enterprise capability has been trapped behind applications. The data existed, the service already knew how to perform the operation, the business rules were already encoded, and a person still had to find the application, learn its interface, navigate its workflow, and carry the result by hand into the next system. Integration between those systems was bespoke, expensive, and written by programmers one connection at a time. This was the entire cost of a generation of software projects: not the data, not the logic, but the layer between the capability existing and a person being able to reach it.

MCP, the Model Context Protocol, attacks that layer directly. It gives a reasoning model a uniform way to discover and invoke a capability that lives behind an endpoint: a repository can expose controlled file operations, a graph store can expose queries, a financial platform can expose transactions, a publishing system can expose content operations. The model learns, in a consistent form, what the capability does, what parameters it expects, and what it returns. What used to require a custom integration now requires an endpoint and a way to authenticate into it. That is a real collapse of cost, and it is why the protocol spread as fast as it did.

A2A, agent-to-agent, extends the same idea one level up, from tools to agents. It lets one agent discover another, read its declared capabilities, delegate work to it, pass context, and receive a structured result. This matters for agentic systems specifically, because the moment you decide that a planner should not also implement, review, and approve its own work, you need a mechanism for intelligence to move between specialised roles without collapsing them back into one undifferentiated model. A2A is that mechanism. It is what lets a system preserve the boundaries that accountability depends on, by allowing planners, implementers, reviewers, and domain agents to remain distinct while still working together.

Both protocols, then, are answers to a real and old problem, and they are good answers. Capability that was reachable only through applications and bespoke code is becoming reachable through a uniform, cheap, describable interface. Nothing that follows is an argument against either one. It is an argument about what neither was ever built to do, and about the mistake of assuming that because they carry so much, they must also decide.

Two edges, and they are not the same edge

Because the two get discussed together, it is easy to treat them as one thing with two names. They are not. They couple different things, and the accountability they leave behind is different in kind, not degree.

Take the tools edge first. MCP couples a reasoning process to a capability that has an owner: a database, a render pipeline, a scheduling API, a triple store. There is a caller, a callee, and a principal who is accountable for the callee. Authorisation is at least answerable here, because the question has a subject, an object, and somebody who owns the object and can be asked what should have happened. The chain of responsibility is short and it terminates in a person.

The agent edge is where that cleanliness disappears, and the accountability structure is materially harder. It couples two reasoning processes, each acting for its own principal, neither holding authority over the other, neither able to inspect the other’s policy. When my agent delegates to yours, I am not invoking a capability. I am asking a party with its own objectives, its own memory, and its own governance posture to act in a way I will be answerable for. That is a contract, and it is being transacted at machine speed with no counterparty diligence.

The asymmetry compounds under composition. An MCP call fans out to systems, and systems, whatever else they do, hold still. An A2A delegation fans out to agents, and agents delegate onward. Three hops in, the party performing the write has no relationship with the party who formed the intent, no visibility into the constraints that intent was formed under, and no obligation anyone can hold it to. The coupling transmitted the load faithfully. That is precisely the problem: it transmitted a load nobody sized.

What the protocols do not carry

Three things travel with neither protocol.

The asymmetry that makes this a now problem

Here is the case for treating this as urgent rather than as something that matures on its own. The cost of getting coupling wrong is not distributed evenly across the surface being coupled, and the protocols cannot see the difference.

Consider two MCP calls that are indistinguishable at the wire level. One pushes a formatted draft into a publishing surface. The other posts a ledger entry, or writes a medication order, or commits an irrigation schedule across four thousand acres in a season where the water allocation is already contested. Same auth flow, same method signature, same audit line. One wrong write costs a minute and an apology. The other is not recoverable at any price, and in the agricultural case the feedback arrives months later, by which point the causal chain has gone cold.

The A2A version is worse in a specific way: the delegating party frequently cannot know which of the two it triggered. That is what delegation to an opaque peer means. You issued an intent, and somewhere down the chain that intent was resolved into an irreversible act by a process you did not specify and cannot inspect. If your governance posture depends on the far end behaving well, you do not have a governance posture. You have a hope, held at scale, with your name attached to the outcome.

This is why authorisation and execution have to be separated by something stronger than convention. In the system I am building, the policy decision point and the policy enforcement point are distinct components, Pola deciding and the Governor enforcing, and the Governor holds no write path at all. That separation is enforced at build level, through identity and crate-level dependency rules, rather than asserted in documentation. The reason is simple, and it is not a claim about model quality: a guarantee that depends on the reasoning layer choosing correctly is not a guarantee, it is a prediction. These are working names for theses under active validation, not shipped products. The constraint is the part I am confident about.

Slack and seizure

Couplings fail in exactly two directions, and both are already visible in how organisations are adopting these protocols.

The first is slack. Connect everything, delegate freely, let the agent run the chain, discover the boundaries by hitting them. It produces real and immediate gains, which is exactly why it spreads, and the joints separate later under a load nobody modelled. The gains are legible weekly. The dislocation is legible quarterly, and by then the coupling is load-bearing across the organisation and cannot be pulled out without stopping the work.

The second is seizure, and it arrives after the first serious incident. Every call routed through review, every delegation pre-approved, every edge wrapped in an approval workflow that reintroduces precisely the human bottleneck the architecture existed to remove. The machine is intact and it has stopped turning. Both failures come from one root error, which is treating governance as something applied to the coupling layer rather than something that lives inside the system the coupling holds together.

What follows

The correct posture is neither. Instrument the edges, but put the decision somewhere the edges cannot reach: a policy point that evaluates the specific action against the specific object, an enforcement point that holds no capability to write, a durable work unit carrying intent and constraint and reasoning together across every hop, and a governed event stream that records why rather than merely what. Then let the coupling be as wide and as fast as it can be, because at that point width is a benefit rather than an exposure.

A load path has never been the interesting part of any machine. It is necessary, it is usually invisible, and when it is well made nobody thinks about it at all. It also cannot refuse, and that is not a defect in it, because refusal was never its job. The question worth asking about any system that can apply force is whether anything in the design retains the standing to say no, and whether that thing sits far enough from the work to still mean it.

---

Revised July 20, 2026.