2. AI Models: What They Are and How Quickly They Date

The word model gets used in two ways, and the ambiguity causes more trouble than it should.

Sometimes it means a trained system that turns inputs into outputs. A model that summarises documents. A model that classifies defects. Sometimes it means a specific named product that you select from a list. Both usages are correct, and people slide between them mid-sentence without noticing.

In the first sense, a model is the trained result of a learning process. Text, images, audio, or structured data go in. Generated text, classifications, summaries, or actions come out. What sits in between is a very large set of numerical parameters, adjusted during training until the system's outputs on known examples came close enough to the known correct answers.

A useful intuition, and one worth holding onto: a model does not look things up. A database retrieves what was stored in it. A model generates an output based on the patterns it absorbed during training, plus whatever context you hand it at the moment you ask. This is why a model can produce something fluent and entirely wrong, and it is why the retrieval question, which we take up in the next piece, turns out to matter so much.

The vocabulary, briefly

A few terms circulate, and they describe architecture and scope rather than any particular product.

Transformer models are built for sequence data such as text. They process input in parallel and use a mechanism called attention to weigh which parts of the input matter most when producing each part of the output. This architecture is why modern language models handle long documents and long conversations far better than what came before.

Foundation models are large models trained on broad data, capable of being adapted to many tasks through prompting, retrieval, tool use, or fine-tuning. The name captures the idea: they are a base you build on, not a finished application.

Frontier models is an informal label for whichever models are currently the most capable. It is a moving target by definition, and a model that was frontier eighteen months ago is now a cost-optimised option.

That last point is the one that matters commercially, and it deserves its own section.

Why the model is the least durable thing about your vendor

Ask an AI vendor which model they use. The answer will be confident, current, and largely uninformative.

Model capability has been improving quickly and model cost has been falling quickly, and both trends have held long enough that it is reasonable to plan around them. What was frontier last year is commodity this year. A vendor whose advantage rests on their model selection has an advantage with a short half-life, and they are competing on a dimension where they have no influence, since they did not build the model and neither did you.

This has a consequence for how you evaluate. The model question tells you very little. The interesting questions are about what has been built around the model: how the system knows what it is allowed to do, how it behaves when uncertain, what happens to the reasoning behind each decision, how the whole arrangement survives the model underneath it being replaced.

We build model-agnostic systems, and we arrived at that position by following this argument rather than by preferring it. If the model layer is going to keep changing under us, and it is, then binding an architecture to any particular model is a commitment we would eventually regret on a customer's behalf. So we select models per use case and design so that swapping one out is a configuration change rather than a rebuild.

The practical test to put to any vendor: what happens if the model you rely on changes, degrades, or is withdrawn. The answer should describe an architecture. If it describes a relationship with a model provider, you have learned something.

What we are still working out

The commoditisation argument depends on the trend continuing, and trends stop. It is entirely possible that a genuine step-change in capability arrives and re-concentrates advantage in the model layer, in which case model access becomes strategic again and companies like ours would need to think differently. We watch this closely, and we would rather say so than pretend our position is future-proof.

We are also uncertain where fine-tuning settles. Adapting a foundation model on a customer's own data sits between the two positions in this article, and it is neither pure model-agnosticism nor pure model dependence. It has real benefits and it creates real lock-in, both for the customer and for us. We have deliberately stayed light on it so far. We are not certain that will remain the right call.

Mitochondria is an agentic AI product company based in Amsterdam and Pune. ISO 27001:2022 certified. Classified within the limited and minimal risk tiers of the EU AI Act, with controls aligned to the GDPR, UK GDPR and India's DPDP Act.

Previous
Previous

1. What Makes AI Different From Conventional Software

Next
Next

3. Where an AI System Gets Its Answers From