Two years ago, a founder picked a vendor for the system that answers questions on the website and drafts the first reply to every inbound lead. It worked well enough, and the team stopped thinking about it.
Then a newer model came out from a different lab. It was cheaper to run and noticeably better at the kind of question that made up most of the traffic. The founder asked how long it would take to move to it.
The answer was a quarter. New prompts, written and tested again. New integration work, because the old wiring assumed the old model's quirks. A migration project, with its own budget line and its own place on the roadmap, just to use something better that already existed.
The model answering the website today was never the best one on the market. It was the one that happened to be running the day everything else got built on top of it.
Why we build it this way
The usual advice is to choose carefully the first time: compare the models, read the claims, pick the winner, sign. That advice assumes the winner stays the winner. It does not. A better, cheaper model ships somewhere every few months, and the gap between the one you picked and the one you could be using only grows while everyone waits for a reason big enough to justify a project.
The real problem is not the choice. It is where the model sits. Most systems wire a model directly into the product — into the prompts, the integration code, the places that call it by name. Swapping it then means touching every one of those places, which is exactly the kind of work nobody schedules until something breaks.
We would rather be replaceable than have you stuck with us. A better model next year should be a setting you change, not a project you fund.
So we build the opposite way on purpose. Every agent we build talks to its model, and to the tools around it, through one layer in between — never directly. The agent's job, what it may read, what it may do, where it has to stop and ask, stays written down on its own, separate from which model happens to be answering today. Nothing about that job changes when the model underneath it does.
That has a cost: we are easier to leave than a vendor who wires you in on purpose. We think that is the right trade. A customer who stays because leaving is expensive is not the same as a customer who stays because the arrangement is good, and we would rather compete on the second kind every year than win the first kind once.
How it works, roughly
Underneath each agent sits an adapter — a layer that knows how to talk to whichever model and whichever tools are configured for that agent. The agent's own logic does not need to know which one is currently answering.
- Which model is in use, and which tools it may call, set per agent as a configuration — not written into the agent itself
- The agent's scope, budget and approval rule, unchanged whichever model sits underneath it
- A record of which model answered which request, kept in the same log that already tracks every read and every approval
Moving to a different model is a change to that configuration, tried first against the same cases the agent is already judged on, and signed off by a person before it goes live — the same gate that already governs everything else the agent does. If the new model turns out worse on a case that matters, the change is reversed the same way it was made, in minutes, not months.
A year in, a better model arriving somewhere else is good news instead of a dilemma. Moving to it is a decision a person makes and signs off on, recorded in the log that already lives inside your building — not a rebuild that waits for next year's budget.
See how the agents are built →