The model is not the memory — Editorial Intelligence

The model may be the most visible part of an AI system. It is increasingly looking like the least durable part.

For most of the generative AI era, the model has been the centre of attention. Which model is smartest? Which one writes best? Which one reasons longest? Which one should an organisation standardise on?

I think that is becoming the wrong architectural question.

A different pattern is becoming visible across enterprise AI. Organisations are beginning to separate the context that makes AI useful from the model that happens to reason over it. Company knowledge, permissions, semantics, memory, workflows, tools and governance sit in one layer. Models sit in another.

That distinction matters because the second layer changes extraordinarily quickly. The first is accumulated slowly, through years of work.

The interesting question is no longer simply which model an organisation should use. It is what should remain when the model changes?

The market is starting to answer that question

Several apparently different product developments point in the same direction.

In September, Notion introduced workspace controls over which AI models its agents can use. Owners can decide which models are available to Notion Agent and Custom Agents and set defaults independently of the agents themselves. The workspace, its knowledge and the agent configuration remain; the model becomes a selectable component.

Snowflake has gone further with dynamic model routing. Cortex AI Gateway can choose a model according to quality, speed, customer preferences and cost while the governed data remains in Snowflake. Lower-complexity work can go to cheaper models and deeper reasoning to frontier models. The intelligence engine changes according to the task without requiring the organisation to rebuild the information environment around it.

Glean is unusually explicit about the principle. Its LLM choice lets people change models while staying inside the same enterprise environment, and Glean says it already uses different providers for different jobs. Its wider architecture puts permissions, indexing and a knowledge graph underneath agents, while independent agents carry organisational context across applications. Glean now describes itself as flexible across models and says it supports more than 40 LLMs.

Palantir approaches the same problem from a different direction. The Ontology provides an operational representation of the organisation, while models can be developed inside the platform or brought in externally. In July, Palantir added agent templates for the Claude Agent SDK, OpenAI Agents SDK and Google ADK, all able to authenticate against its Ontology and MCP interfaces with scoped permissions. The organisational representation is the stable object; different agent and model systems can work against it.

Then Salesforce made the separation unusually clear. Its new Enterprise AI Harness is organised around six capabilities: context, agency, action, governance, security and models. Models are one layer among several. Salesforce’s argument is effectively that enterprise advantage comes from the proprietary business context and controls surrounding AI, not from permanently owning one particular model choice.

These companies are not building identical systems. Some are data platforms, some knowledge platforms, some application platforms. Their commercial incentives are different too.

But the architectural convergence is difficult to ignore.

The emerging stack looks different

The first wave of enterprise generative AI often looked like this:

company information → prompt → model → answer

That architecture makes the model feel like the system. Change the model and it feels as though you have changed the intelligence environment.

The emerging version looks closer to this:

organisational context → permissions and semantics → tools and workflows → routing and governance → model → action

The model still matters enormously. But it is sitting inside a larger system rather than defining the system.

That is close to the argument I’ve been developing around context as capital. Organisations have spent years accumulating research, decisions, customer evidence, operational knowledge, frameworks, conversations and expertise. AI makes more of that previous work reusable because retrieval, comparison and synthesis become cheaper.

Once that context becomes reusable, tying it permanently to one model starts to look strange.

A company should not have to lose its organisational memory because a better reasoning model appears next quarter.

Open protocols make the separation more plausible

This is where MCP matters, but probably not for the reason it is usually discussed.

The Model Context Protocol is often described as a way for an AI model or agent to connect to tools. That is useful, but the more important consequence may be architectural. A standard interface reduces the need to build a new bespoke connection every time the intelligence layer changes.

Snowflake’s managed MCP server exposes governed Snowflake data and tools through a standards-based interface. Glean operates an MCP server that can expose enterprise context to external AI environments and can also consume other MCP servers. Palantir’s Ontology MCP lets compatible agent frameworks work against resources explicitly exposed from the Ontology.

The pattern is not limited to MCP. Agent Skills, agent-to-agent protocols and model gateways are all pushing towards more modular AI systems. Glean, for example, now supports the open Agent Skills standard, allowing expertise and task structure to be packaged separately from the model executing them.

None of these protocols guarantees portability. Vendors can still create proprietary layers around open interfaces, implementations differ and security becomes harder as more systems are allowed to act. But protocols change the cost of substitution. They make it more plausible that an organisation can preserve context and capability while changing the reasoning system connected to them.

That is a much more consequential form of portability than exporting a chat history.

Model-agnostic does not mean model-indifferent

There is an easy version of this argument that I don’t think survives contact with real systems: build a good context layer and every model becomes interchangeable.

They don’t.

Different models reason differently, use tools differently, handle long context differently and fail differently. A workflow tuned around one model may perform worse when another is dropped into exactly the same harness. Cost, latency, security requirements and modality also change what the sensible choice is.

Snowflake’s model routing is revealing precisely because it acknowledges this. If models were genuinely fungible, there would be little need to route between them according to the characteristics of the task. Glean makes a similar argument: different work needs different models.

So I would refine the claim.

The system can be model-agnostic without being model-indifferent.

The durable layer should not depend unnecessarily on a single model provider. The execution layer should still care deeply about which model is being used, what it is good at and how the surrounding system needs to adapt.

That gives a more realistic architecture:

durable context → adaptable harness → selectable models

The model is replaceable. It is not irrelevant.

What actually belongs in the durable layer?

Calling this a knowledge layer is probably now too narrow.

Documents alone are not enough. An organisation needs to know where information came from, whether it is current, who can see it, how concepts relate, what actions are permitted and where human judgement is required. Agents make this more important because the system is no longer only retrieving knowledge. It can increasingly act on it.

The durable layer therefore starts to include several things that used to be treated separately: organisational knowledge and evidence; permissions and identity; semantic relationships; provenance; workflow state; reusable instructions and skills; memory; tools and actions; governance and evaluation.

That looks less like a corporate wiki and more like an organisational context system.

This is also why I remain interested in systems such as Notion, Glean, Palantir and Snowflake despite how different they appear on the surface. The interesting competition may not ultimately be over who has the best chatbot. It may be over who becomes the trusted layer through which models understand and act on an organisation.

That is a much stickier position.

The knowledge layer may outlive the AI product

There is a practical implication for organisations making AI decisions now.

Buying access to a strong model can create immediate capability. Building the context layer is slower. It requires better documentation, usable evidence, permissions, provenance, structured knowledge and decisions about what should persist. That can make the context work look secondary while everyone is excited by model capability.

I think the priority may eventually reverse.

Models are improving quickly enough that today’s advantage at the model layer is unlikely to remain exclusive for long. An organisation’s accumulated context is different. Competitors cannot simply download the history of customer conversations, decisions, failed experiments, domain expertise and internal relationships that made the organisation what it is.

That is why portable intelligence matters to me beyond the personal use case. At an individual level, I want useful context to survive a move from ChatGPT to Claude or whatever comes next. At organisational scale, the same principle becomes much more valuable: preserve the intelligence accumulated through work so that the next model can inherit it.

The AI system should get better when the model improves without requiring the organisation to forget everything it already knows.

The competitive asset may be what the next model inherits

There are plenty of reasons this architecture might not become as clean as the diagram suggests. Model providers want more context because context improves their products. Enterprise platforms want to own the orchestration layer because orchestration increases switching costs. Open protocols can become nominally open while the useful implementation remains proprietary. Security and governance may also push organisations towards fewer providers rather than frictionless switching.

So I would not bet on a future where models become anonymous commodities behind a perfectly standard interface.

I would bet on something more modest and, I think, more useful: organisations will increasingly separate the intelligence they have accumulated from the models they temporarily employ to work with it.

That changes what deserves investment.

The durable asset may not be the model that gives the best answer today.

It may be the context the next model inherits.