The Model Context Protocol solved tool calling. It did not solve who is allowed to call what, who settles when two agents dispute a result, or how a third agent discovers the first two are worth trusting. MCP is the transport; AxoneOS is the layer underneath it that makes transport into a governed economy.
What MCP Gave Us, and What It Stop Short Of
Model Context Protocol is a clean contract: a client, a server, a JSON-RPC interface, a tool manifest. Anyone who has integrated an MCP server into Claude or Cursor has felt how much friction disappears once the protocol is in place. Discovery, schema negotiation, and invocation work the way they should. The agentic web finally has a wire format.
The second-order problem is harder. Two MCP-compatible agents can call each other's tools. They cannot answer three questions that any real deployment asks within minutes:
- Authorisation. Which agent is allowed to invoke which tool under which jurisdiction, evidence chain, or service-level agreement?
- Settlement. When an agent pays another agent for a result, which rail carries the value, who arbitrates a disagreement, and what makes the disagreement final?
- Discovery trust. When a third agent encounters the first two, what makes it believe their past acts and standing are real, rather than a self-attested claim?
MCP itself does not answer any of these. It specifies a transport, not a regime. The protocol can carry an attested tool call perfectly well; it cannot, by itself, attest that the call was authorised. That gap is the reason the recent MCP coverage reads as either pure plumbing or hand-waving toward trust layers that do not exist. The plumbing matters. The trust layer is what is missing. Why the gap is structural, not a near-term fix, is laid out in Why MCP Isn't Enough.
AxoneOS as the Governance and Value-Exchange Layer Under MCP
AxoneOS sits underneath MCP, not beside it. An MCP server publishes tools over JSON-RPC exactly as before. What changes is that every act on top of those tools — the request, the response, the settlement, the dispute, the reputation update — becomes an entry in a normative regime. The transport stays portable; the meaning of a tool call becomes opposable.
Three primitives make the layer concrete:
- Zones as Prolog regimes. Every zone is a typed artifact: a Prolog program, versioned by content hash, instantiated from a template, whose rules decide which acts are opposable inside it. Authorisation rules live in the zone, not in the MCP server's middleware. Two agents on opposite sides of a contract find out by querying the regime, not by trusting the other party's README.
- Pactum for settlement. When an MCP-mediated act is paid for, disputed, or canceled, the resulting state transition commits to Layer 1 through the Pactum layer. Settlement is not a webhook callback; it is a chain event that any third agent can audit against the regime that produced it.
- Act logging as portable reputation. Past acts are append-only, indexed by zone, and verifiable by content hash. Reputation travels with the act log, not with a vendor's dashboard. A new agent does not need a private integration to evaluate a stranger; it reads the regime's own log.
MCP servers continue to evolve on their own roadmap. AxoneOS does not fork MCP, replace it, or rebadge it. The wire format stays the wire format. What AxoneOS adds is the legal-system layer underneath it: the contract, the court, and the public-notary roles that any nontrivial agent economy needs.
Régimes: A Deployable Front-End for the Layer
The Régimes page (live at /regimes) is the concrete face of this architecture for operators who do not want to read Prolog before they ship. Régimes are the deployable unit: a typed template, a parameter sheet, a reproducible build, and an audit artifact a zone is allowed to run as. The page exposes the same machinery described abstractly above as a thing you can install.
Why this matters for MCP-compatible deployments: an operator onboarding MCP agents into a real workload cannot stop at "the tool schema is published." They need to ship a regime template, pick parameter values that match their compliance posture, and have the resulting zone record every MCP-mediated act against the version they reviewed. Régimes is the unit that makes that workflow tractable. The deeper the layer goes, the more the on-chain registry matters; the deeper story of the Prolog-evaluation chain behind a regime call is covered in Why Governance Needs Prolog, and the operational story of why hand-rolled regimes per tenant stop working is in Zone Industrialization.
A Prolog Pattern: MCP Bridge Through a Regime Template
The pattern below is the smallest expression of how an MCP-bridge regime compiles. The template declares the typed slots — MCP peer identity, the act class it accepts, and the settlement rail — and a single rule that admits an MCP-mediated call into the zone's act log only when the regime has registered both endpoints and the policy predicate passes.
% ============================================================
% REGIME TEMPLATE — MCP BRIDGE ZONE (AXONEOS)
% ============================================================
% --- DECLARED SLOTS (filled by deployer at instantiation) ---
slot(zone_id, atom).
slot(mcp_caller_policy, atom).
slot(settlement_rail, atom).
% --- MCP PEER REGISTRY (filled by deployer, attested at instantiation) ---
mcp_peer(Zone, Caller, Server) :-
slot(zone_id, Zone),
peer_attested(Caller, Server).
% --- ADMIT AN MCP-MEDIATED CALL INTO THE ZONE'S ACT LOG ---
admits(Zone, mcp_call(Caller, Server, Tool, Args)) :-
slot(zone_id, Zone),
slot(mcp_caller_policy, Policy),
mcp_peer(Zone, Caller, Server),
policy_allows(Policy, Caller, Tool),
tool_schema_ok(Server, Tool, Args).
% --- APPEND THE ACT, COMMITTIBLE TO LAYER 1 ---
opposable(Zone, mcp_call(Caller, Server, Tool, Args)) :-
admits(Zone, mcp_call(Caller, Server, Tool, Args)),
append_act(Zone, mcp_call(Caller, Server, Tool, Args)).
% ?- opposable(zone_mcp_acme, X).
% X = mcp_call(alice, summariser_v2, summarise, [...])Three things are happening at once. First, admits/2 is the governance predicate: an MCP call becomes part of the regime only if the slot-typed policy predicate decides so. Second, opposable/2 writes the call to the zone's append-only act log the moment it is admitted, which is what makes the call auditable later. Third, the ? query shows the runtime contract: a third agent can ask the regime, in Prolog, whether a particular MCP call is opposable, and the answer is derived from the same rule the caller had to satisfy. The MCP server itself does not need to know any of this is happening.
Outliving Transport
The reason AxoneOS has to outlive MCP — or any single transport — is that protocol horizons are short. The wire format changes. JSON-RPC gets replaced. The protocol team forks. The layer underneath it has to be stable across those changes or the governance story resets every few years. Putting the regime as a typed, versioned, content-hashed artifact on Layer 1 is what makes the governance layer outlive the transport it currently rides on.
The architectural claim is straightforward: the agent economy will run on multiple, possibly incompatible transports, and the layer that picks which transport is allowed for which class of act, under which regime, with which settlement story, must not be one of those transports. AxoneOS is that layer. Régimes is the unit a platform team ships today. MCP is the protocol it ships over. The split is what lets the governance story survive the protocol churn the agent web is about to go through.
Closing
MCP is the wire format. AxoneOS is the governance and value-exchange layer underneath it. The wire format will keep moving; the layer that says which wire format, under which rules, with which settlement and reputation, has to be the part that stays. Régimes (live on /regimes) is the deployable shape of that layer. Agents on MCP, governed by zones, settled on Layer 1, discoverable through act logs — that is the architectural shape an MCP-compatible agent economy has to take if it is going to be more than a tool directory.