Composable agent platforms via open standards: OAMP, MCP, and signed artifacts

A procurement team at a large European bank spent most of Q1 2026 trying to get a written commitment from their agent infrastructure vendor on one question: what happens to all of our agents if we migrate to a different memory backend? The answer, after three weeks of back-and-forth, was essentially: you would need to rebuild most of the integration layer. The vendor was polite about it. The bank was not delighted.

This is the vector-database problem, one layer up. In 2022 and 2023 the industry produced roughly two dozen vector stores, each with its own query API, its own embedding format, its own metadata schema, its own idea of what a “namespace” is. Migrating from Pinecone to Weaviate meant rewriting client code, re-indexing data, and hoping the query semantics were close enough. It was friction that should not have existed, and it persisted because nobody had agreed on an interchange format before the market exploded.

The agent infrastructure market is doing the same thing, but across three dimensions at once: memory backends, tool authorisation, and supply-chain provenance. Each layer is fragmenting independently, and the teams now commissioning year-long agent deployments are about to discover, the hard way, that lock-in at the infrastructure layer is a much larger problem than lock-in at the application layer.

The fragmentation problem, stated plainly

Pick any serious agent deployment running today and trace what happens when a task fails and you need to reconstruct why. The memory the agent used is in a proprietary schema on a hosted service. The tool calls it made went through whatever gateway your orchestration framework provides, with access control that was added as an afterthought. The artifacts it produced, code or documents or decisions, are in a git repository with a bot token attached to a human account. The chain of custody from “what did the agent know” to “what did it produce” requires correlating three separate systems that were never designed to talk to each other.

That is not a governance story anyone can tell to an auditor. It is barely a story you can tell to a senior engineer doing a post-mortem at 2am.

The fragmentation exists because the components are being built in the wrong order. The frameworks (LangChain, LangGraph, AutoGPT, and a hundred successors) arrived first, and they made reasonable choices for their time: use whatever vector store is popular, call tools via HTTP with API keys, trust the orchestrator to handle identity. Those choices are now load-bearing in thousands of production deployments. Retrofitting coherent governance onto them is genuinely hard, because you cannot add “every action signed by a cryptographic identity” or “every memory deletion is a first-class cryptographic event” to a stack that was designed around service tokens and soft-delete.

The answer is not a better orchestration framework. It is three open protocols that define the interfaces between the layers, so that each layer can be built and swapped independently without losing the governance guarantee.

Three protocols, three layers

The analogy to HTTP is apt but worth unpacking. HTTP did not specify what web servers had to do internally. It specified how browsers and servers would talk to each other: request format, status codes, headers, the minimum surface area for interoperability. Once that surface was agreed, the web could have Apache on one side and Netscape on the other and nobody cared what was happening inside either box. The governance contract lived in the protocol, not in the implementation.

Agent infrastructure needs the same idea applied to three distinct interface boundaries.

The first is memory. What does “give the agent access to its history” actually require of the system that stores that history? The Open Agent Memory Protocol defines it: a JSON schema for knowledge entries with mandatory provenance fields, a REST API contract for backends, RFC 2119 privacy clauses including real (not soft) deletion, and a capability-discovery mechanism so orchestrators can ask “can you answer a bitemporal query?” before routing to a backend. You can read the full OAMP specification and its reference implementations at the OAMP announcement post. What matters for this argument is that once the protocol exists, the backend is swappable. Kizuna-mem today, a specialised temporal graph for a particular vertical tomorrow, a federated multi-backend configuration the year after. The orchestrator does not care, because it is talking to the protocol, not the implementation.

The second layer is tool authorisation. The Model Context Protocol (MCP), which Anthropic published in late 2024, defines how a model or agent discovers and calls tools: a standard envelope for tool descriptions, a standard flow for capability negotiation, a standard request-response shape. The key word is “authorisation,” not just “invocation.” A well-formed MCP implementation can express deny-by-default policies, capability declarations (“this tool can only read from these namespaces”), and audit trails of what was invoked with what arguments. The promise of MCP is that an agent runtime does not need to know which specific tool is on the other side of an MCP server. It needs to know whether it is authorised to call it under the declared policy.

Interactive: click any layer to inspect the protocol that governs its interface. Toggle air-gap mode to see which connections are severed in a sovereign deployment and which remain intact. Control flow travels downward; signed provenance travels back up.

The third layer is supply-chain provenance. This is where most discussions stop, and it is also where most production failures happen. An agent that produces code, a document, or a decision has contributed to a supply chain. The question is whether you can prove, later, that this specific agent at this specific version with this specific signed identity produced this specific artifact, and whether you can verify that it was produced under the policies that were in effect at the time. Signed artifacts and Kizuna-style forge policies are what make this provable.

How these protocols relate to the vector-DB lesson

The vector-database fragmentation was not inevitable. The field had perfectly good schema standards from classical information retrieval. What it lacked was anyone willing to ship a constrained, opinionated interchange format before the market created fifty incompatible incumbents who then had no incentive to adopt a standard that would erase their moat.

The agent infrastructure market is at the same inflection point, and it is earlier. The large deployments that will calcify the incumbents are happening now, in 2026, not in 2028. The window to establish common protocols before fragmentation becomes permanent is short. This is the argument for publishing OAMP and for implementing MCP as the tool gateway, and for insisting on signed artifacts from the first line of infrastructure code, rather than waiting until the governance requirement arrives from a regulator and then trying to retrofit it.

The deeper lesson from vector databases is that the fragmentation tax is paid by customers, not vendors. The vendor who got you onto their proprietary schema has no incentive to make migration easy. The customer who wants to switch pays the integration bill. In agent infrastructure, where the equivalent of a vector index is an agent’s entire history of decisions and actions and the tooling it was authorised to use, the migration cost of a proprietary stack is not a sprint of re-indexing. It is potentially months of reconstruction work across memory, identity, and supply chain simultaneously.

Open protocols shift that tax. When the memory backend, the tool gateway, and the artifact store all expose standard interfaces, the migration cost collapses to testing the new implementation against the same fixture suite the old one passed. That is a very different conversation.

OAMP as the memory contract

The OAMP specification covers four things that a regulated buyer should actually need from an agent memory system.

Bitemporal queries. A memory backend that can only answer “what does the agent know now” is not sufficient for regulated work. You need “what did the agent know at the time of this decision, as recorded at the time of this audit.” The valid-time and transaction-time dimensions of a bitemporal model are what make the difference between memory and a replayable, defensible record. OAMP requires that compliant backends expose this via a query interface, not just store it as metadata.

Provenance fields. Every knowledge entry in an OAMP-compliant store must carry the agent identity that created it, the session in which it was created, and a timestamp. No anonymous entries. This is both a privacy requirement and a governance one: you cannot have an audit trail that includes agent memory if the memory does not record who put it there.

Capability discovery. Before an orchestrator routes a memory operation to a backend, it can ask the backend to declare its capabilities. Can you do bitemporal queries? Can you do a hard delete? Can you scope entries to a policy namespace? This is how Ninmu, the mission conductor, knows before the swarm starts whether the memory backend it has been given is adequate for the governance requirements of the current mission. It is cheapest-sufficient routing applied to infrastructure, not just model selection.

Crypto-shred delete. When a data subject exercises their right to erasure, or when a policy change makes certain entries out of scope, the deletion needs to be a cryptographic event: the entry is removed, and the deletion itself is recorded in the audit trail with a signed event. “Soft delete plus vacuum later” is not compliant. OAMP backends that implement soft deletion cannot claim compliance, and orchestrators that route to them should treat the policy guarantee as unverifiable.

Kizuna-mem is Substrate’s primary OAMP-compliant backend. The Cosmictron-memory module also implements the protocol. Having two independent implementations against the same specification is the proof of concept that the protocol is doing real work rather than just describing one system’s behaviour.

MCP as the tool authorisation gateway

The MCP integration point in Kizuna sits in a specific place in the architecture that is worth describing precisely. It is not a proxy that forwards all tool calls. It is a policy enforcement point.

An agent arriving at the MCP gateway declares its identity (the Ed25519 identity issued by Ultra), the capability it is requesting, and the arguments it intends to pass. The gateway checks the declared capabilities of this agent’s trust level against the policy for this tool. If the agent has not been explicitly granted the capability, the call is denied. The denial is logged. If the agent has been granted the capability but the arguments fall outside the declared policy for this tool, the call is denied. That denial is also logged.

This is the difference between “we put MCP in front of our tools” and “MCP is the policy enforcement point for the entire tool surface.” The first reduces friction. The second gives you something you can show an auditor: a complete record of every tool invocation, every denial, and the policy that governed each decision, all linked to the cryptographic agent identity that made the request.

The broader point about MCP is that it only delivers its governance value if every tool call goes through it. A hybrid architecture where some tools are available via MCP and others are reachable via direct API calls with service tokens has the weakest possible governance guarantee: the guarantee is only as strong as the least-controlled path. Regulated buyers should require, in their RFP language, that all tool invocations in a production agent system go through an MCP gateway with signed agent identity and policy enforcement, with no fallback to service tokens.

Signed artifacts as the supply-chain standard

The supply-chain attack surface for agent systems is larger than most people appreciate, and it is growing quickly.

Consider what a standard glue-stack agent deployment actually looks like from a supply-chain perspective. The orchestration framework has thirty or forty transitive dependencies, each of which is a potential compromise point. The model weights come from a provider whose signing story is, at best, a checksum on a download. The code the agent produces goes into a repository using a bot account with a shared service token, so there is no cryptographic link between “this specific agent run” and “this specific commit.” The artifacts the agent reads, policy documents, reference data, historical decisions, arrived via an ETL pipeline that may or may not have integrity checks.

In 2026, autonomous agent tooling for vulnerability discovery has reduced the cost of probing this attack surface to near zero. An adversary who wants to poison an agent’s behaviour has a large number of injection points, most of which are invisible to the agent and most of which leave no forensic trail. The supply-chain problem is not theoretical.

Kizuna addresses this at the forge level. Every agent has a declared capability set and a trust level (zero through four in the Kizuna model). Every commit and merge to an agent-controlled repository requires a signed artifact from an identity that has been granted the capability to write to that branch, under the policy that governs that repository. Merge gates are enforceable for agent PRs in the same way they are for human PRs, with the agent’s signed identity in the audit trail. CI runs produce signed attestations that link the run to the identity that triggered it.

Interactive: click “simulate tamper” to see what happens when a single artifact in the chain is modified. Every downstream block fails signature verification. Hover any block to inspect the signed fields: agent identity, tool, policy, and the hash that anchors it to the preceding block.

The signed artifact contract is what turns a forge from a collaboration tool into a supply-chain audit point. When a regulator asks “can you prove that the code in production on this date was produced by an agent with this identity, using this policy, and that no unsigned modification was made between the agent run and the deployment,” the answer requires a chain of signed artifacts from the forge through the build to the deployment. Without that chain, the best you can offer is “we checked the logs and we believe nothing was changed,” which is not an answer that satisfies DORA or EU AI Act Article 12 or a financial services internal audit.

How the Substrate factory uses all three

Substrate’s six systems were designed together against the same governance contract, which means the three protocols are not stitched in from the outside. They are load-bearing.

Ninmu, the mission conductor, checks OAMP capability declarations before routing memory operations. It also routes through the MCP gateway when dispatching tool calls, so every tool invocation is policy-gated before it runs, and the cost of the tool call is metered against the mission budget. A tool that is expensive or high-risk gets a higher “cost” in the routing model, which means the budget ceiling influences not just model selection but also which tools the swarm uses and how often.

Ultra provides the identity plane that the other protocols require. OAMP provenance fields reference Ultra-issued agent identities. MCP gateway enforcement checks against Ultra-issued capability grants. Signed artifacts in Kizuna are signed by Ultra keys. The identity is not managed by three separate systems with three separate lifecycle models. There is one authority plane, and the protocols consume it.

Kizuna-mem is the memory backend. Cosmictron provides the secondary OAMP-compliant store for high-throughput mission state. The two implementations against the same protocol are not redundancy for availability. They are the proof that the protocol is real and that the governance contract travels with the interface, not the implementation.

Kizuna is the forge. Every artifact that leaves the factory, code, documentation, regulatory evidence packs, is signed at the forge before it is considered an output. The supply-chain is closed from declaration to delivery.

This is what “governed by construction” means in practice. The governance properties do not depend on any single system being well-behaved. They are enforced at the interface boundaries between systems, by protocols that any conforming implementation must satisfy. A third-party memory backend that passes the OAMP interop fixture suite and plugs into this architecture inherits the governance guarantee automatically, without any special knowledge of how Substrate works internally.

A concrete sector walkthrough: healthcare records processing

Consider a hospital trust deploying an agent swarm to process clinical coding backlogs: reading discharge summaries and assigning ICD-10 codes, with human review for borderline cases. Personal health information. Direct billing and care-pathway consequences.

Under a proprietary-stack approach, the memory backend uses the vendor’s schema. Tool calls go through the vendor’s gateway. Artifacts land in a repository attached to a service account with no chain of custody. If the vendor is acquired, or if the trust wants to replace the memory backend with one validated for NHS data governance, the migration cost is months of reconstruction work.

Under a composable open-standards approach, the contracts are explicit and swappable. The memory backend speaks OAMP: the information governance team can audit provenance fields, verify that hard-delete satisfies right-of-erasure requirements, and swap the backend without touching governance logic. Tool calls go through the MCP gateway, so agents only reach systems they have been explicitly granted. Artifacts are signed at the forge, giving an unbroken chain from “this ICD code was assigned” back to the specific agent, at the specific version, under the specific policy.

The before and after is not primarily about speed. It is about whether the trust can answer “can you prove what the agent knew and what it did?” Under a proprietary stack, the honest answer is “we have logs and we believe they are complete.” Under open standards, the answer is the signed chain itself.

For regulated buyers in the procurement process, the six systems walkthrough explains how the governance properties emerge from the system as a whole, and the Kizuna deep-dive covers the supply-chain signing model in more detail.

What to demand in an RFP

If you are evaluating an agent platform for regulated deployment, the composability questions separate the serious systems from the demos faster than any benchmark.

Ask whether the memory backend exposes a bitemporal query interface through a documented, publicly available protocol. Specifically: can you replace the memory backend with a third-party implementation that passes an independent interop test suite, without rebuilding any of your governance logic? If the answer is “not without significant rework,” you are buying proprietary lock-in.

Ask how tool authorisation is implemented. Is there a documented gateway through which all tool calls pass? Is deny-by-default enforced at the gateway level, with explicit capability grants per agent identity? Can you see a signed log of every tool invocation, every denial, and the policy that governed each decision? If access control is implemented by putting conditions in prompts, walk away.

Ask about artifact signing. Can you produce a cryptographically verifiable chain from a specific agent run to a specific artifact in production? If the answer involves service tokens and git commit hashes with no signatures, the supply-chain is open.

Ask about migration. If you replace the memory backend or the tool gateway in three years, what is the path? An honest answer: migrate the data to any implementation that passes the fixture suites, update the endpoint configuration, and you are done. An answer involving bespoke export tooling or the phrase “we would need to discuss that with customer success” describes a proprietary integration.

Ask about sovereign deployment. The protocols are not useful if the implementations enforcing them only run in the vendor’s cloud. Confirm the full stack, including the governance enforcement points, runs on hardware you control with models you own. The sovereign deployment post covers this in detail, and the composability thesis intersects directly with the alternative-to-Palantir argument: open standards plus sovereign deployment plus signed supply chain is what makes a regulated buyer genuinely free to choose.

A call to other vendors

The argument above is not an argument for Substrate specifically. It is an argument that the agent infrastructure market needs to agree on interface contracts before fragmentation becomes irreversible.

OAMP is MIT-licensed. The fixture suite is public. Any memory vendor can implement it. There are five reference SDK implementations in the spec repository, and an afternoon of engineering on a mature memory backend is enough to add an OAMP-compliant API surface.

MCP is already published. The question is whether vendors implement it as a genuine policy enforcement point or as a thin compatibility layer. Buyers should test for it by requiring vendors to demonstrate deny-by-default enforcement with signed agent identities, not just “we support MCP.”

Signed artifact and forge-level supply-chain policies are less standardised than OAMP or MCP. The Kizuna model of agent trust levels and capability declarations is one approach. What the industry needs at minimum: a signed, cryptographically verifiable link from agent identity to produced artifact, with the signing policy recorded alongside the signature. SLSA (slsa.dev) provides a useful framework for software artifacts specifically, and its principles transfer to agent-produced content with little adaptation.

The ask is not to adopt a specific implementation. It is to define the governance contract at the interface, not inside the black box, and make the interface open enough that customers can verify it independently. That is the condition that prevents the vector-database fragmentation from repeating at the agent infrastructure layer.

A 90-day pilot design

The fastest way to pressure-test these claims is a constrained pilot on a workflow where governance actually matters.

Pick a workflow with a clear, bounded scope and a known human cost. A quarterly reconciliation that takes two analysts three weeks. An evidence pack for a specific regulation that currently takes a month to assemble. A backlog of classification tasks that costs a known number of person-hours. Declare it as a mission with a hard budget.

Before the pilot starts, write down three verifiable claims. First: at the end of this pilot, I should be able to replace the memory backend with a different OAMP-compliant backend and re-run the mission without rebuilding any governance logic. Second: I should be able to produce, for any agent action in the run, a signed chain from the agent identity through the tool call to the artifact, without correlating three separate systems. Third: I should be able to demonstrate, to a person unfamiliar with the technical stack, that a specific change to a specific artifact would have been detected by the supply-chain checks.

If you cannot verify all three claims at the end of ninety days, you have not been running on composable open standards. You have been running on a platform that talks about open standards while locking you in through proprietary interfaces. The distinction matters, and it is testable.

The three verifiable claims above map to the three protocols described in this piece. They are also the three claims that will come up in an audit, a procurement review, or a board-level risk conversation about whether the agent infrastructure you are running is one that you actually control.

If you want the complete picture of how the factory works as an integrated system, including the financial model and the head-to-head comparison against assembled glue stacks, request the investor brief at the Substrate overview page. And if you are specifically wrestling with the memory side of the composability question, the OAMP interoperability post goes into more depth on the bitemporal contract and the interop test suite than this piece does.

The stack running your agents in 2026 is infrastructure. Infrastructure choices outlast the problems they were chosen to solve. Insist on open interfaces before the integrations are built, not after.