article 7 min read

The workflow should outlive the model

14 August 2026 · updated 28 August 2026


Models are the fastest-moving part of the system. Building on top of them is the one place the durable layer cannot go.

A lot of discussion about working with AI still starts with the model.

Which one is best?

Claude or ChatGPT?

Codex or Claude Code?

Which subscription should I keep?

Those are reasonable questions to ask once. They are a poor foundation to build on, because models move too quickly to hold still underneath anything.

One improves its coding. Another gets better at design. Another gives you a better way to interrogate a large body of existing context.

Six months later, the hierarchy has changed again.

I’ve written separately about why I stopped trying to pick a side. That piece names specific products and specific preferences, and it will be wrong within months — deliberately, because a hierarchy that moves that fast is not a thing to be loyal to.

This is the more consequential version of the same argument.


Build the valuable part somewhere else

If the model layer is the fastest-moving part of the system, it is the one place the durable value cannot live.

So the work is to build it elsewhere.

The evidence. The accumulated context. The frameworks. The editorial standards. The decisions. The things learned from previous work. The workflow that connects all of them.

Then the model becomes a layer you can change.

Use one for design. Another for coding. Another for synthesis. Move the same problem between them when a second perspective is useful. Replace one entirely when something better arrives.

The important thing is that the underlying intelligence survives the swap.

This is what Portable Intelligence is for. The objective isn’t independence from AI. It’s independence from any single AI.


It is already happening without you

There is a version of this that isn’t a choice.

Enterprise AI tools increasingly route to more than one model underneath. The interface stays the same. What is answering behind it does not — and the vendor changes it as a routine product decision, for cost, for capability, for availability, for reasons that are rarely announced.

So for a great many people using AI at work, the model layer is already abstracted away. Somebody else is doing the swapping, on their own schedule and in their own interest.

That is this argument arriving from the opposite direction. You don’t have to accept in principle that models are an interchangeable layer. In a lot of workplaces they are already being treated as one in practice, by the people selling the software.

Which sharpens the question underneath all of this considerably.

If what is answering your prompts can change without notice, what exactly are you building on?


For organisations, this is the difference between memory and dependency

The stakes are higher than a subscription decision.

If years of customer research, market knowledge, narrative thinking and editorial decisions effectively live inside one AI tool, you haven’t built organisational memory.

You’ve built dependency.

It will feel like memory for as long as nothing changes. The difference only becomes visible at the moment of a contract renegotiation, a vendor’s change of direction, a pricing change, a product being discontinued, or a security review that rules the tool out.

At that point an organisation discovers whether it owns its accumulated understanding or merely had access to it.

That is not a hypothetical risk profile. It is the ordinary lifecycle of enterprise software, applied to something far more valuable than a CRM.


Shared memory changes who holds the advantage

A provider that remembers more becomes more useful. That is real value for the user. It also creates switching cost: every project, correction and unfinished decision that lives only there makes another provider more expensive to try.

OpenAI and Anthropic do not have to resist portable memory explicitly for that incentive to matter. Both can support GitHub, connectors and open protocols because serious work needs external systems, while still having little reason to make cross-provider memory the default.

Tool interoperability lets a model reach your work. Memory portability lets a competing model inherit the same work without making you rebuild its history. Those are not the same proposition.

A shared memory layer changes the balance. When the durable project state belongs to the user or organisation and different models can work from it, the provider has to keep winning on capability, price and experience. It cannot rely as heavily on the accumulated cost of leaving.

I reached this problem in practice when Editorial Intelligence became fragmented across Claude and ChatGPT. The answer was not to avoid either provider. It was to give both access to the same inspectable state, so changing models no longer meant abandoning part of the work.

That makes provider-independent memory more than a neat workflow choice. It keeps the choice of model real.


The order matters

Editorial Intelligence takes the opposite approach to tool-first adoption.

Preserve the knowledge and judgement first.

Structure it so it can be retrieved, challenged and reused.

Then let AI work across it.

That order is the whole argument. Done the other way round, the tool shapes what gets kept, and what gets kept is whatever that tool happened to make easy.

I should be honest that this is more demanding than it sounds. Keeping a durable layer requires deciding what belongs in it, maintaining it as things change, and resisting the pull of whichever interface is currently most convenient. Tool-first adoption is popular because it is genuinely easier, and it works right up until the moment it doesn’t.


Context is capital. Models are infrastructure.

That is the shortest version I have.

Context is capital — work performed once that keeps producing value, provided somebody maintains it.

Models are infrastructure. Powerful, expensive, improving quickly, and replaceable.

Infrastructure changes. It always has.

The workflow should be designed so that when it does, you get the benefit without having to start again.

Topics

aiai-workflowsknowledge-systemseditorial-intelligenceeditorial-systemsevidencethought-leadership

What to explore next

See how the ideas in this Field Note connect to the frameworks, diagnostics and workflows in Editorial Intelligence OS.

Explore the EI OS →

Keep in touch with Editorial Intelligence

Occasional updates on new research, findings and ways to take part.

No spam. Unsubscribe in one click.

Your address is used only to send these updates. Read the privacy policy.