The model is the most replaceable thing in your AI stack. I do not mean that as a knock on any lab. The market is simply heading this way. Frontier models are converging on similar capabilities, and they are priced against each other so hard that they get swapped in and out on procurement cycles. If you built your whole approach around one specific model, you built on the part that moves the most.
The durable asset is the harness. That is the thing worth real investment, and it is the thing most teams underbuild.
The model is the swappable part
Something will swap your model for you, and it will not ask permission. The usual culprit is procurement: large companies sign spend commitments, and when the commitment moves to a different provider, your default model moves with it. Price pushes the same way, the cheapest capable model this quarter is often not the cheapest one three months later, and finance always notices. And every so often a new frontier model lands, clears a bar the old one could not, and everyone reruns the choice inside a week.
You do not control any of that. So the real question is not which model to bet on. The question is what you build so the bet does not matter much.
What a harness actually is
The harness is everything you wrap around the model to turn a raw endpoint into something that does real work. I think about it in four parts.
1/ The tools and connectors the model can call. Search, code execution, a ticketing system, a database, whatever the work needs.
2/ The context and data plumbing. What you retrieve, how you shape it, what goes in the window and what stays out.
3/ The permissions and guardrails. What the model is allowed to touch, and where a human has to sign off.
4/ The evals. The test suite that tells you whether the other three actually work, on your tasks, with your data.
Notice that the model is not on that list. The model plugs into the harness. When you swap it, the harness is what stays, and the harness is where the months of work live.
Evals are the portability layer
Evals are what make a model swap boring, and boring is the goal.
Without evals, swapping a model is a leap of faith. You change the endpoint, things feel a little different, and you have no way to say whether they got better or worse. So you do not swap. You stay put out of fear, and you call that fear a platform strategy.
With a real eval suite, a model swap is a Tuesday. You point the harness at the new model and run the suite. You read the numbers. If it wins, you keep it. If it loses, you roll back before lunch. The decision takes hours instead of quarters, because you measured it instead of arguing about it.
This is also why I built my own adoption playbook to be product-agnostic. The three-phase version I published (it is at hagestedt.com/playbook.html) does not assume any single assistant or vendor. That was a design decision, not an accident. A playbook that only works on one product has an expiration date, and I did not want to rewrite mine every time the market moved.
Open tool contracts are the other half
Build your tools to an open standard, and you build them once.
MCP is the visible convergence point right now. It is a shared contract for how a model calls a tool, and the useful consequence is that a tool you build against the standard plugs into whatever assistant wins. You are betting on a contract that several vendors already support, instead of a single product roadmap.
Build the same tool against one vendor's private interface and you have signed up to rebuild it later. Maybe not this year. But the day you want to move, that tool is the thing holding you back, and you will feel it.
The practical portability test
Here is the test I use, and you can run it this week. Could you move to a different frontier model next week, or to an on-prem model, without rewriting the work? Try it on paper first. Trace what would actually have to change.
Whatever breaks first is your real lock-in, and for most folks it is not the model. The evals they never wrote break, because now they cannot tell whether the swap is safe. The tool layer shaped around one vendor breaks, because half of it has to be rebuilt by hand. The model was always the easy part to move. The harness is where they got stuck, and they could not see it until they tried.
Where I would start
Start with the evals, before you fall in love with any model. Write down what good looks like on your real tasks and turn it into a suite you can run on demand. Keep it under version control like any other asset.
Then build your tools to the open standard. If you are standing up connectors, target the shared contract, not the private one, even when the private one is a little easier this week.
Then run the swap on purpose. Pick a second frontier model and route real evals through your harness against it. I do this, and the results contradict my intuition more often than I am comfortable admitting. That is exactly why I run them. The point is to measure it and stop assuming, because the model you would have picked by gut is not always the one the numbers pick.
Do that, and the next time your model gets swapped for you, it is a Tuesday. That is the entire goal.
This is post 4 of 9 in my Thoughtful interfaces series. The rest lives at hagestedt.com/writing.