OAMP as the interoperability layer: composing best-in-class memory without lock-in

An insurance group I spoke to recently had arrived at the following situation. They had built a capable agent swarm over six months. Kizuna-mem was the memory layer, performing well, and their compliance team had signed off on the bitemporal query semantics and the hard-delete story. Then someone senior came back from a conference having heard about a new temporal graph product from a large vendor. They wanted to evaluate it. The evaluation ran for three weeks. At the end, the legal team pointed out that switching would void all the compliance documentation they had spent four months producing, because that documentation was written for Kizuna-mem’s specific deletion and provenance mechanics, not for an abstract concept of “a memory layer.”

They were not wrong to want to evaluate alternatives. They were wrong to be in a position where evaluating an alternative meant potentially invalidating their compliance posture. That is lock-in, and it is the kind that does not show up on a vendor contract. It shows up in your audit team’s spreadsheet at the worst possible moment.

The governed dark factory is built on a different premise. The factory owns the governance contract. Memory implementations are interchangeable components that must satisfy the contract, not the other way around. OAMP, the Open Agent Memory Protocol, is that contract made concrete: a precisely specified interface that any compliant backend must implement, covering bitemporal queries, provenance fields, capability discovery, and cryptographic-shred deletion. Once the factory relies on OAMP as the boundary, you can swap or federate memory backends without touching the governance documentation, because the governance properties are properties of the protocol, not of any single product.

This piece is about OAMP as an interoperability layer, not about the OAMP specification itself. The spec is covered in detail in the OAMP announcement post and the v1.2 governed memory post. What this post covers is what it means for the factory to treat OAMP as the governance contract, why that matters more than which backend you happen to be running today, and what a CRO or head of audit should be asking vendors about it.

The problem with memory lock-in in a governed factory

Memory lock-in in a coding assistant is annoying. You lose your learned preferences and your codebase context. Painful, recoverable.

Memory lock-in in a regulated factory is a liability. When your agent swarm produces an AML evidence pack, and that pack has a compliance trace that references specific provenance fields, specific bitemporal query semantics, and specific deletion audit events, those references are facts your regulator relies on. The day you swap your memory layer is the day that compliance trace either needs rewriting from scratch or stops being accurate.

Most teams do not think about this until they are in it. The memory layer gets selected early, usually by whoever built the prototype, often because it was easy to stand up locally. Over time the governance documentation wraps itself around the implementation specifics. The compliance team writes procedures that reference the actual field names. The audit team approves a deletion workflow based on the specific mechanics. The memory layer is now load-bearing in a way nobody planned.

The governed factory approach inverts the dependency. You specify the governance contract first. Memory backends must satisfy the contract. What any specific backend does internally is its own business, as long as the boundary behaviour is correct. When you want to evaluate a new backend, you run the interoperability test suite against it. The compliance documentation does not change because it was written against the contract, not against the implementation.

This is the same pattern that made relational databases broadly composable: the SQL standard gave buyers a contract they could hold vendors to, which meant a DBA could move from one vendor to another without rewriting the application logic. OAMP is attempting to do the same thing for governed agent memory. The scale of the attempt is smaller, but the structural argument is identical.

What the contract actually requires

OAMP as a governance contract has four properties that any compliant backend must implement correctly for the factory to rely on it.

Bitemporal queries. The factory needs to answer “what did the agent know at this point, under the state of the world as it was then understood?” That requires two independent time axes: valid time (when the fact was true in the world) and transaction time (when the system recorded it). A simple timestamp does not do this. Most vector stores do not do this. Without bitemporal semantics, you cannot reconstruct the exact memory state that informed a particular agent decision, which means your audit trail has a hole in it that a regulator will eventually find.

Provenance fields. Every memory entry must carry a record of where it came from: which agent wrote it, from which session, under which mission. The provenance chain must be traversable, not a flat source field. When a human gate reviewer asks “why did the agent produce this output,” the answer must trace through memory to a set of specific entries, each with a clear provenance record. Without traversable provenance, the audit trace stops at the output and cannot go deeper.

Capability discovery. The factory needs to know, programmatically, what any given memory backend can and cannot do. Does it support bitemporal queries? Does it implement v1.3 governance enforcement? Does it support the deletion semantics the compliance team approved? A capabilities endpoint that returns a structured, machine-readable declaration lets the factory validate a backend before routing memory operations to it. This is not a convenience feature. In a multi-backend or federated deployment, capability discovery is the mechanism that prevents the factory from silently falling back to weaker semantics.

Crypto-shred delete. When a data subject exercises their right to erasure, or when a policy change requires removal, the memory must be provably gone. Not flagged as deleted. Not shadowed by a soft-delete mechanism that the compliance team has to trust. Gone, with the deletion event itself written into the signed audit trail. This is the “governed by omission” property: the memory was never there for the scope that matters, and there is a cryptographically signed record of when and why it stopped existing.

Any backend that implements these four properties correctly can participate in the factory. Any backend that does not cannot, regardless of how good its recall metrics are. Recall accuracy is a performance number. These four properties are compliance properties. They are not on the same axis.

Interactive: click each layer to see which OAMP contract property it satisfies. Toggle air-gap mode to confirm the contract layer remains intact when external connections are severed.

Verified interop: Kizuna-mem and Cosmictron

The interoperability claim is not theoretical. As of OAMP v1.2, cross-implementation interoperability was verified between Kizuna-mem and Cosmictron, in both directions, using the published interop fixture pack from the OAMP repository. The fixture pack covers the full lifecycle: write an entry with governance metadata on one backend, export it as an OAMP document, import it on the other backend, query it by valid time and transaction time, verify the provenance fields round-trip cleanly, exercise the governance enforcement rules, and confirm the deletion audit event is written correctly.

The v1.2 interop run produced an empty diff on both sides. The entries looked the same, the provenance records were identical, the capability declarations matched expectations. This matters not as a benchmarking claim but as a proof of contract: two independently implemented backends, both following the spec, can exchange governed memory without any custom integration code or translation layer.

What this means in practice is that a factory running Kizuna-mem as its primary memory backend can federate with a Cosmictron-memory module without the governance properties degrading. The audit trace remains continuous. The provenance chain does not break at the federation boundary. A compliance officer reviewing the full trace sees one coherent record, not two separate records with a gap between them where the handoff happened.

It also means that the interop test suite is available for any other memory vendor who wants to claim OAMP compliance. The tests are the contract, made executable. Running them is not optional for a claim of compliance; they are the definition of what compliance means.

Why composability is harder than it looks for governed memory

The interop story above sounds straightforward. In practice, composable governed memory is harder than composable query engines, for a structural reason.

In a relational database, the data model is table-shaped and the semantics are well defined by decades of use. Composability at the SQL layer is hard in practice because of dialect differences, but the concept is clear.

In governed memory, the data model is a temporal graph and the semantics include time-travel queries, provenance traversal, and deletion events that must themselves be auditable. Two backends can both claim to support bitemporal queries while having different edge cases in how they handle overlapping valid-time intervals, or different conventions for what happens to provenance records when a referenced session is deleted, or different behaviours when a query arrives for a time range that spans a governance enforcement version change.

This is why the OAMP specification is written with RFC 2119 language: MUST clauses, not SHOULD clauses. A governance property that a backend is encouraged to implement is not a governance property you can rely on in a regulated context. The spec identifies the behaviours that must be identical across implementations for the governance claims to hold, and it makes those behaviours normative. Everything else is implementation latitude.

The practical implication for factory buyers is that “OAMP-compliant” is a testable claim. You can run the fixture suite. You can verify the deletion audit event. You can check the capability declaration. If a vendor says they are OAMP-compliant, they mean something specific and verifiable, or they do not mean it at all.

How Substrate uses the contract to stay implementation-agnostic

The dark factory’s memory layer is Kizuna-mem by default. Kizuna-mem implements OAMP fully and was a primary development target for the spec. But the factory does not depend on Kizuna-mem being the memory layer. It depends on the OAMP contract being satisfied.

This distinction has real consequences for how the factory is deployed in regulated environments. A government agency running the factory on sovereign infrastructure may have existing data infrastructure that includes a temporal graph database already approved by their information security team. Rather than asking them to replace that infrastructure with Kizuna-mem, the factory requires only that the existing infrastructure implement the OAMP boundary. If it does, the governed properties are preserved. If it does not, the factory will not route governed memory operations to it until it does.

The capability discovery endpoint is the technical mechanism. Before routing a memory operation, the factory checks the backend’s declared capabilities. If the backend declares that it does not support bitemporal queries, or that it does not implement v1.3 governance enforcement, the factory routes those operations to a backend that does. The operator is not guessing at what a backend supports. The backend is telling the factory, in a machine-readable format, and the factory is acting on that declaration.

This is also how federation works in multi-backend deployments. A factory running across multiple jurisdictions, where data residency requirements mean that some memory must stay in one region and other memory in another, uses OAMP capability discovery to determine which operations can be routed where. The governance contract travels with the data. A provenance record written in one region is verifiable in another region without any custom integration, because both backends are speaking the same protocol.

Interactive: toggle the “regulated-finance lens” to see how the axes re-weight for a CRO evaluating memory backends. Click legend entries to isolate specific series. Note the gap between OAMP-compliant and proprietary implementations on the governance axes.

The sector view: where composability breaks compliance and where OAMP fixes it

Finance. A trading desk running an agent swarm for evidence pack generation typically operates across at least two data environments: a primary environment where live trade data is stored, and a secondary environment where compliance records are assembled and reviewed. If the memory layer for the agent swarm is not composable, the provenance chain breaks at the boundary between these environments, and the evidence pack has to include a manual attestation that the records were transferred correctly. That attestation is a human process, which means it is slow, variable, and subject to error.

With OAMP composability, the provenance chain is continuous across both environments because both memory backends speak the same protocol. The evidence pack can include a machine-verified provenance trace rather than a manual attestation. The compliance team gets a stronger artefact, not a weaker one, and the factory does not need a human in the loop for what is essentially a data transfer step.

Healthcare. A clinical coding operation using an agent swarm to process discharge summaries faces a similar pattern. The clinical data environment and the billing environment are typically separate systems with different compliance requirements. Memory that spans both environments needs to preserve provenance across the boundary. With a non-composable memory layer, this usually means writing custom integration code for each new environment pair. With OAMP, the integration code is replaced by a capability check and a protocol boundary. Hospitals changing electronic health record systems do not need to rebuild the memory integration from scratch; they need the new EHR’s memory layer to implement OAMP.

Government. Sovereign deployments are perhaps the clearest case. A government running the factory on air-gapped infrastructure cannot simply update its memory layer every time a new version ships from a cloud vendor. The memory layer has to be auditable, updateable, and replaceable without rebuilding the governance documentation every time. OAMP gives government buyers a way to lock down the contract and let the implementations evolve independently. The sovereign infrastructure team can evaluate and approve memory backends against the OAMP test suite without the compliance team needing to re-review the governance properties each time.

Calling other memory vendors

The interop story benefits from more than two implementations.

Kizuna-mem and Cosmictron are the two verified implementations today. Third-party temporal graph databases, hosted memory services, and enterprise knowledge graph vendors all have the technical foundation to implement OAMP: they have storage, they have query semantics, they have deletion mechanics. What most of them lack is the specific bitemporal query contract, the structured provenance fields, and the capability declaration format.

Adding OAMP compliance to an existing memory backend is not a rewrite. It is an API surface addition. The OAMP v1.2 specification is additive: existing entries stay valid, existing endpoints stay compatible. The new surface area is the capability endpoint, the governance metadata fields on entries, and the enforcement rules on read and delete paths. A backend team with a few weeks of capacity can produce a compliant implementation of v1.2 and run the published fixture suite to verify it.

The value for the vendor is direct: regulated enterprise buyers are asking about OAMP compliance in RFPs, because their compliance teams have started understanding that composability is a governance property, not just a technical convenience. Being listed in the OAMP interoperability matrix is increasingly a procurement qualifier, not an optional feature.

The spec is at github.com/deep-thinking-lab/open-agent-memory-protocol. The interop fixture pack that defines “what compliance means” is in spec/v1.2/fixtures/interop/. The matrix tracking which backends implement which capabilities is in docs/governed-memory-interop-matrix.md.

What connects this to the broader composability story

OAMP is one piece of a broader composability layer for the factory. The composable-agents picture includes OAMP for memory, MCP (Model Context Protocol) for tool authorisation, and signed artefacts via Kizuna for supply-chain integrity. These are the three layers where proprietary implementations create the kind of lock-in that regulated buyers cannot afford to accept. Composable agents via open standards covers how these three layers interact and why open standards across all three, not just memory, are required for the governance properties to hold end to end.

The provenance thread from OAMP connects directly to the identity thread from Ultra. Every provenance field in an OAMP entry references an agent identity, and those identities are issued and revoked by Ultra, the factory’s cryptographic authority plane. When you trace a memory entry back through its provenance chain, you eventually arrive at a signed agent action, and that action is verifiable against Ultra’s tamper-evident log. The chain from “what the agent knew” to “who the agent was” is unbroken. Provenance as the real differentiator goes into this connection in depth.

The delete story also connects to the hard-delete post in this series. OAMP’s crypto-shred delete is the mechanism. Kizuna-mem’s bitemporal graph is what makes the deletion verifiable in the correct sense: not just that the data is gone, but that you can construct a query for any point in time, including times before the deletion, and receive either the correct historical record or the deletion event record, depending on what the query is asking for. Memory that was never there: hard-delete and governance by omission works through the mechanics.

And the interoperability question connects to the broader question of why the factory is built as one integrated system rather than a composable stack. The answer is that composability has to be designed into the governance contract from the start; you cannot retrofit it. The OAMP contract exists because it was specified before the implementations, not derived from them after the fact. Six systems, one factory: why it is a contract, not a stack explains the same principle at the level of the factory as a whole.

What to demand in an RFP

If you are evaluating memory backends for a regulated agent factory, these questions separate the compliant from the merely capable.

Ask for a copy of the backend’s OAMP capability declaration, as returned by the /v1/capabilities endpoint. Review it against the OAMP v1.2 specification. A backend that does not have a capability endpoint cannot make a verifiable compliance claim. A capability declaration that omits bitemporal query support, or governance enforcement support, is telling you directly what the backend cannot do.

Ask the vendor to run the OAMP v1.2 interoperability fixture suite in your presence, or share the test results from a recent run with the fixture version number attached. A claim of OAMP compliance that cannot be backed by a test run against the published fixtures is a marketing claim, not a technical one.

Ask specifically about the deletion audit event. When you exercise GDPR Article 17 on a memory entry, what is written to the audit log? Who can read that log? Is the deletion event included in the bitemporal history of the entry, so that a query for the pre-deletion state returns the correct historical record rather than a gap? A backend that cannot clearly answer all three of these questions has not fully implemented crypto-shred delete.

Ask whether the factory can be configured to federate across multiple OAMP-compliant backends in different jurisdictions, with data residency constraints expressed as routing rules rather than custom integration code. A yes to this question, backed by a working demo, is the difference between a backend that is technically compliant and one that is actually composable in a regulated multi-region deployment.

Ask what happens to the compliance documentation when you switch backends. The answer you want is “nothing changes because the documentation references OAMP contract properties, not implementation specifics.” If the answer involves significant rework of compliance procedures, the vendor is selling you a product with lock-in baked in, even if they advertise OAMP support on their marketing page.

A 90-day pilot design

The fastest way to validate OAMP composability in your environment is not to run a benchmark. It is to run a controlled backend switch on a non-production mission and verify that the compliance properties survive the transition.

Day one to thirty: run a realistic regulated mission (a control test, a document review batch, a claims processing run) with Kizuna-mem as the memory backend. At the end of the run, export the full memory state as an OAMP document. Document the compliance properties: which entries were created, what provenance they carry, which entries were deleted and what deletion events were generated.

Day thirty to sixty: import the exported memory state into the candidate backend. Run the OAMP interop fixture suite. Then replay a subset of the original mission’s memory queries against the new backend and verify that the results are identical. Pay specific attention to bitemporal queries for times before and after the import, and to the deletion events.

Day sixty to ninety: run the same regulated mission against the new backend from a cold start, with the governance documentation written for the OAMP contract, not for either specific backend. At the end of the run, compare the compliance trace against the one from the Kizuna-mem run. If they are structurally identical, the composability claim holds. If they differ in ways the documentation does not account for, you have found a gap in the new backend’s OAMP implementation, and you have found it before it becomes a compliance gap.

Ninety days. One controlled test. Definitive answer. No vendor slides required.

Why this matters now

The EU AI Act Article 12 logging requirements for high-risk systems come into force in August 2026. The relevant question for memory layers is not whether they can log; all of them can. The question is whether the log satisfies the tamper-evident, long-term-retention, reconstructable requirements of the regulation, and whether switching memory backends requires the compliance team to re-evaluate those requirements from scratch.

A factory built on OAMP as the governance contract answers both questions with minimal effort. The tamper-evident, reconstructable properties are properties of the contract, verified by the fixture suite. Switching backends means re-running the fixture suite, not rewriting the compliance assessment. In a regulatory environment where the compliance team’s time is the binding constraint, not the engineering team’s time, this is the difference between a one-day backend evaluation and a three-month re-certification.

The insurance group from the opening of this post eventually evaluated the alternative backend by running the OAMP fixture suite against it. The new backend failed three tests around bitemporal query edge cases and one test around the deletion audit event format. The evaluation took four days. The compliance documentation did not change. They kept Kizuna-mem, confident for the first time that they could revisit the decision in eighteen months without a compliance crisis, because the decision was now grounded in a testable contract rather than in institutional inertia.

That is the point. Not that Kizuna-mem is the right backend forever. That the choice is now yours to make on technical and commercial grounds, and it no longer carries a hidden compliance cost that nobody told you about when you built the prototype.

If you want to see how this connects to the full factory governance story, the investor brief covers it end to end. Request it at the Substrate page. And if you are building a memory backend and want to understand what OAMP compliance requires in concrete terms, the spec repository is the starting point: github.com/deep-thinking-lab/open-agent-memory-protocol.