Discussions about AI in companies almost always start with the question “which model do we use?”. It is the wrong question to start with. Models change every few months, prices change, the rules about where they can run change. If everything you have built depends on one particular model, you are building on sand.
Below is what we saw concretely while working on an AI assistant for a distribution company in September 2026.
We changed the model, the system stayed
Within the same month, the AI assistant went through several configurations: a local model, on the appliance at the client’s premises, then a larger model in a European data centre, then a combination: the local model for Area Sales Managers, the cloud one only for management’s open conversations.
With each change, what did not change was:
- the data: the company CRM, with invoices, payments and the history of each client;
- the tools: the functions that calculate overdue payments, sales per period, product groups in decline;
- the access rules: an Area Sales Manager sees only their own clients, the director sees the whole company, and the model cannot widen those limits;
- the test questions: a fixed set of questions, with the correct answers known in advance;
- the team’s notes: what people have learned about each client.
That is the part that has value for the company. Each time, the model was the piece that could be replaced.
Five things that stay with the company
When we design a system, we start from five layers. Only one of them has anything to do with the model, and not even that one directly.
1. Operational memory. What happens in the company: clients, orders, visits, documents, notes. It has to sit in a place the company controls, with access rights per person, team and company.
2. The decision log. What was decided, by whom, when and why. Example: the decision that Area Sales Managers use only fixed commands, and that open conversations stay with management, was taken after testing, with the reason written down. A year later, when someone asks “why is it like this?”, the answer exists.
3. Your own evaluation standards. The set of questions you check every new model against. Not public benchmarks: your company’s questions, on its data. A configuration goes into production only after it answers every question in the set correctly, each one in a new conversation.
4. The applications and the agents. The commands, the screens, the integrations. This is where a model is used, but through standard interfaces, so that it can be replaced.
5. Accumulation. Every validated process strengthens the memory. The next process starts from it, not from zero.
The contract between the model and the system
Between the model and the rest of the system there is an interface: the names of the tools, the format of the answers, the rule that text with numbers arrives already written by the server. We treat it as a contract.
The reason is practical. Models do not read instructions the same way. Some copy exactly what the text says, others interpret. If the instructions name a tool differently from the way it is registered in the system, one model may work and another may not, with nothing changed in the data or in the code.
That is why the contract has to be yours: written, tested and checked at every change of model. Then the model behind it can be replaced without breaking what people use.
In short
- Do not start by choosing the model. Start with the data, the tools and the test questions.
- Keep the memory and the decisions in the company’s systems, not in a vendor’s conversation history.
- Write your own evaluation set and run it at every change of model or version.
- Decide explicitly where each model runs. It is a management decision, not a technical detail.
Today’s model will be replaced. What the company has learned should not leave with it.
See also: Quiet Trace, company memory, and Field teams do not need open-ended chat.