Your AI Workflow Should Be Model-Agnostic from Day One

Last month, Claude was the obvious choice. Move everything to Claude. ChatGPT had fallen behind.

A few weeks later, the recommendation had reversed. ChatGPT was the obvious choice. Move everything again.

The illustration that prompted this article captures the problem well. The person in the middle is not choosing between two bad tools. They are being asked to reorganise their working life every time opinion changes about which tool is ahead.

I have watched that advice swing between models, often with complete confidence in both directions. Rather than follow it, I stopped and asked what “move everything” would actually mean. My instructions, useful examples, source material, decisions and unfinished work had accumulated around a particular tool. Switching was not a model choice any more. It was a small migration project.

That revealed the mistake. The model had become the place where the workflow lived.

Models will keep improving, changing and disappearing. OpenAI says prompting behaviour can change between model snapshots and recommends pinned versions and evaluations where consistency matters. Anthropic maintains a model retirement schedule and tells developers to test replacements on their own tasks before migrating. Google distinguishes stable models from aliases that can be replaced by newer releases. The details differ, but the direction is consistent: OpenAI documents behaviour changes between snapshots, while Anthropic and Google document model lifecycles that require change.

That is not a reason to avoid these tools. It is a reason to organise your work so that change remains a choice.

The model is not the workflow

When I say model-agnostic, I am not talking about building an elaborate routing platform or hiding every provider behind an API. That belongs to Building with AI.

This starts one layer earlier. It is about how you organise the work you do with AI every day.

A useful workflow has at least five parts:

• The outcome you are trying to produce.
• The context and source material the work depends on.
• The instructions, constraints and examples that shape it.
• The intermediate decisions that carry the work forward.
• The checks that tell you whether the result is usable.

The model contributes to that process. It may draft, analyse, challenge, classify or write code. It does not need to own the other parts.

If the brief exists only in a chat, the chat owns it. If the examples exist only in a custom assistant, that product owns them. If the latest decision survives only because the current conversation still fits inside a context window, your working state is more fragile than it looks.

A model should perform work inside your workflow. It should not become the container for the workflow.

Model-agnostic does not mean models are interchangeable

The obvious objection is that Claude, ChatGPT, Gemini and other tools do not behave in the same way. That is true.

They respond differently to structure, examples, long context, tool instructions and requests for verification. Even generations from the same provider can need different treatment. Anthropic's own prompting guidance contains model-specific migration advice, including cases where an instruction useful for one model can add unnecessary work with another.

Pretending those differences do not exist would produce a lowest-common-denominator workflow and probably worse results.

The better distinction is between the portable core and the model-specific edge.

The portable core describes the work: the goal, evidence, constraints, examples, expected output and acceptance criteria. The edge adapts that material to the model: perhaps XML tags for one, a particular tool description for another, or a shorter instruction for a model that follows it more literally.

Keep the work stable. Let the way you present it to a model vary.

Lock-in begins with convenience, not contracts

Vendor lock-in sounds like a procurement problem. In everyday AI use, it is often much quieter.

You begin a conversation about a piece of work. The model learns the terminology during the thread. You correct its assumptions. It sees examples of what good looks like. A dozen messages later, the conversation is genuinely useful.

Then the thread becomes the process.

When a different model becomes attractive, you discover that the value was not in the opening prompt. It was spread across corrections, uploaded files, remembered preferences and decisions that were never recorded anywhere else. Moving means reconstructing all of it, usually from memory.

I think of this as cognitive lock-in. You are not prevented from leaving. You simply cannot explain the working method without pointing at the tool that currently contains it.

This is also why a folder of copied prompts is not enough. As I argued in how to ask AI better questions, prompting is closer to specification than incantation. Portability depends on preserving that specification and the material around it, not saving one clever paragraph.

Build the portable layer before the first conversation

You do not need a platform to do this. A handful of ordinary files is enough for many workflows.

Write the brief outside the chat

State the outcome, audience, constraints, source material and definition of done somewhere you control. For software work, that may live in the repository. For product or delivery work, it may be a document attached to the ticket.

Outcome: Explain why checkout conversion fell
Inputs: Funnel data, release notes, support themes
Constraints: Separate observation from inference
Output: Decision memo with evidence links
Done when: A reviewer can verify every factual claim

That brief can go to any suitable model. More importantly, a colleague can understand the task without reconstructing your conversation.

Keep durable context in a system of record

Project terminology, architectural decisions, customer constraints and approved examples should live in files, documentation or another shared source. A model can be given the relevant slice when the work begins.

This does not mean pasting the whole organisation into every prompt. It means knowing where the durable truth lives and selecting the context deliberately.

Save decisions, not transcripts

A transcript records everything that was said. A decision record preserves what the next person or model needs to continue.

At the end of a useful session, capture the current decision, unresolved questions, evidence used and next action. The next session can begin from that state whether it runs in the same tool or somewhere else.

Define outputs that can travel

Ask for ordinary formats you can inspect and reuse: Markdown, JSON, source code, tables or a document in the team's existing system. Avoid making a proprietary chat artefact the only finished copy.

This matters for intermediate work too. A test plan, outline or list of assumptions is more reusable when it exists as an artefact rather than a message you have to find again.

Keep the checks independent of the model

The definition of good should not change because the logo above the text box changed. Code still has to pass the same tests. A decision memo still needs traceable evidence. Acceptance criteria still describe the same customer outcome.

This is where model agnosticism becomes more than file management. Your evaluation criteria are the stable interface between the work and the model.

A new model is a candidate, not a command

When a new model arrives, the internet tends to run one large, uncontrolled experiment. People change the model, the prompt, the tool and sometimes the task, then announce that everything is different.

That may be entertaining. It does not tell me whether I should move my work.

I would rather keep a small set of representative tasks from the workflow: a real refactor, a recurring analysis, a document review, or whatever the model is regularly asked to do. Give the current and candidate models the same portable brief, context and definition of done. Adapt the presentation only where each model genuinely needs it.

Then compare what matters:

• Did the output satisfy the acceptance criteria?
• What errors or omissions did review find?
• How much human intervention was needed?
• How long did the complete task take?
• What did it cost?

OpenAI's evaluation guidance formalises the same basic move: use test data that represents the work, define criteria against human-labelled or otherwise grounded expectations, and run the prompt against those criteria. You do not need its API to adopt the principle. A small table and honest review can be enough for a personal workflow.

This also connects to checking AI output before you trust it. The model cannot be the authority on whether its own work is acceptable. Switching models does not change who owns that judgement.

The model earns its place through your work, not somebody else's leaderboard.

Sometimes model-specific lock-in is worth it

Model-agnostic should not become a purity test.

A provider may offer a capability that materially improves the outcome: a stronger coding environment, a particular integration, better handling of a modality, lower latency or an interface your team can actually use. Refusing that advantage merely to preserve theoretical portability would be its own kind of bad decision.

The question is whether the dependency is deliberate.

Keep the brief, source material, decisions and checks outside it. Record which part depends on the provider and what you would lose by moving. Use the specialised feature because it earns its cost, not because the workflow drifted into it unnoticed.

A good abstraction does not remove every dependency. It makes the dependencies visible.

This matters before the first switch

The easiest time to make a workflow portable is before it contains anything valuable. Retrofitting it later means extracting decisions from old chats, finding the latest version of instructions and discovering which behaviours you had started to rely on without naming them.

Starting model-agnostic also improves the work if you never switch. The brief becomes clearer. Context is easier to update. Another person can reproduce the process. Reviews use explicit criteria. Useful practice can travel across a team instead of remaining attached to one person's account.

That last point matters for adoption. In AI Won't Fix Agile Until You Redesign the Handover, I argued that reusable skills can carry specialist practice to the work. Those skills become more useful when their core instructions, references and checks are not inseparable from the model that happened to help create them.

The illustration asks, “Which one now?” My answer is to choose the model that currently performs the task best, but refuse the premise that everything must move with it.

Own the context, the process and the checks. Rent the model.