How it works Vs vendor memory Writing Register
Theme

Writing 8 July 2026

Availability was the loud story. Sovereignty was the quiet one.

In June a frontier model was altered, withdrawn, then restored a few weeks later. The lesson everyone reached for was about models. For an Australian regulated buyer, the one that matters is about substrate.

In June, one of the most capable frontier models on the market was quietly altered, then withdrawn from access entirely, then restored a few weeks later. If you were building on it, your workloads went dark and came back on a timeline you didn’t set and couldn’t see coming.

The lesson most people reached for was about models: own the weights, self-host, don’t build on something a vendor can change under you. Fair enough as far as it goes. But it’s worth noticing what actually happened. The model came back. And even while it was gone, you could have failed over to another vendor in an afternoon, because a model is the most swappable thing in the stack; there are several of comparable capability, and switching one for another is close to a config change.

The thing you can’t fail over in an afternoon is your data, and the accumulated memory your team and your agents have built up inside it. That doesn’t come back on anyone’s timeline. If it’s sitting somewhere you don’t control, in a format you don’t own, no amount of model choice helps you.

We build Memoria on Claude ourselves; that’s a deliberate bet on a lab we rate. It’s also exactly why the substrate underneath has to be ours regardless of which lab we trust, or what happens to any single model. The availability scare was the story that trended. Where your knowledge lives was the story underneath it, and that one doesn’t resolve in three weeks.

This isn’t only an offshore story

The Australian version of the same question is already in the numbers. APAPT data, reported through Interactive Australia, puts around 25% of organisations repatriating workloads off public cloud. Worth naming the source: Interactive sells private cloud, so read the figure with that in mind; the direction of travel holds even if you discount the number. The drivers are the familiar three: cost, compliance, control.

For most organisations, the substrate of record is now the chat history: the memory their agents and humans share. Most of an organisation’s actual institutional knowledge already lives there. That makes the substrate holding it personally identifiable, business-confidential, and, for a regulated buyer, procurement-relevant in exactly the way a search index or an analytics warehouse already is. Whose stack it sits on stops being a preference and becomes a procurement question.

The gates you already answer to

If you’re the CIO, the GRC lead, or the privacy officer, you know the gates. An APRA-supervised institution moving a substrate like this offshore is in CPS 231 and CPS 234 territory; you need the outsourcing consultation, and substantive evidence of information-security control over where it sits. Government information under the PSPF carries hosting constraints once you’re at OFFICIAL: Sensitive or PROTECTED. Personal information that crosses the border runs into APP 8. Commonwealth workloads meet the Hosting Certification Framework, and the vendor’s host status is part of the answer, not a footnote.

None of that is new to you. The point isn’t the regimes; it’s that a memory substrate holding your team’s institutional knowledge now sits inside all of them, whether or not it was procured as though it did.

”Why not just self-host an open one?”

It’s the reasonable question, and it’s the one the model-ownership argument tends to stop at. Running an open, self-hostable memory store gives you possession: the bits are on your infrastructure. Possession is cheap; it’s a repo you run yourself.

Possession isn’t governance. What a regulated buyer has to evidence is the harder set: auditable retention, defensible deletion, access control that maps to your obligations, and someone accountable when a regulator asks. A store you’ve stood up yourself gives you the first mile and leaves you to build the rest. That gap, between holding the data and being able to prove how it’s governed, is the whole procurement conversation; it’s also where the vendor-memory question actually lives, underneath the deployment-mode noise.

Ownership is a substrate decision, not a deployment mode

This is why hosted-versus-self-hosted isn’t a checkbox at the end of a build; it’s the substrate decision itself. Substrate-ownership means the team that owns the memory also owns where it sits. Memoria runs hosted, as MemoriaCloud, for teams that want to start fast, and in the customer’s own stack for deployments where sovereignty is the load-bearing requirement. Same substrate, different surface.

Two things follow that matter for a cautious buyer. The substrate is useful without an LLM in the loop; humans can walk and search it directly, so if you want to defer your AI strategy, you don’t have to defer your knowledge-substrate strategy. And none of this is an argument against public cloud. Public cloud is the right call for most workloads. A memory substrate holding your institutional knowledge is simply one of the workloads where where-it-sits is the concern that decides it.

The architectural case for all of this, why the shape of the memory isn’t the moat but the ownership of it is, we made in the Pinecone Nexus piece. This post is what that argument looks like once the reader isn’t an engineer weighing hybrid memory, but someone who has to justify the substrate to a regulator.

The June episode will fade, and the models will keep changing under everyone. The question it surfaced won’t, because it was never really about the model. It’s whose stack your memory is sitting on, and whether you can answer for it.

Keep reading

Should you use vendor memory?

The decision framework, with the failure modes drawn out.

Read the framework