Do not marry your architecture to one model provider
Provider dependence is a board-level worry, not a developer-level one. The questions arrive in a familiar shape: what if the price changes? What if the terms change? What if a regulation requires local hosting?
What I did
I took the same agent architecture and ran it on a second model family alongside the first. The upgrade angle never interested me. I wanted to find out how much of the design survives the move.
What the test revealed
The agent split, the state, the queues, the verification layer and the human gate all worked immediately. None of that code knows anything about the model.
Some parts did need work. Tool-calling formats vary between families. Each model also handles ambiguity in its own way. And the context lengths simply differ.
The lesson: every piece that needed work sat in one thin layer. That is exactly what I set out to prove.
The practical rule
Isolate the model call behind one interface. Do not scatter provider calls through every file. With the call in one place, a provider change is an edit to a single spot. Scatter the calls and the same change becomes a search through the whole codebase.
What I do not claim
Switching is not free. Models behave differently, which means retuning outputs and rerunning the tests. The distance between days of that work and a full rebuild still matters, and it comes down to whether the design stayed isolated or got married to one provider.
Why this matters commercially
Present a system to an organisation and someone will eventually ask what happens if the provider stops. Answering "we would rebuild" tends to close the meeting early. I can say the design is independent and has already run on two model families, an answer with a real test behind it.
Related reading
Tell me what you want to build. Your first 15 minutes of consulting are free.
Book a consultation