Skip to content
Back to the workshop

The Model Is Not the Product

Why the things around the model matter more than the model itself

C
Cleo's TeamBuilding Cleo
4 min read

When people ask about AI products, the first question is usually which model. GPT-4. Claude. Gemini. The assumption is that the model is the product, and the rest is plumbing.

This is like asking a restaurant which stove they use. The stove matters. It is not the reason you eat there.

Where the leverage actually lives

The model is a reasoning engine. It takes a prompt and produces a response. The quality of that response is determined by three things: the capability of the model, the quality of the prompt, and the information available in the context. Of these three, model capability is the one you control the least and the one that matters the least at the margin.

A state-of-the-art model with a poor prompt and sparse context will produce mediocre output. A slightly less capable model with excellent prompt engineering and rich, well-structured context will produce excellent output. The engineering leverage is not in the model selection. It is in everything around the model.

Context engineering

The most undervalued discipline in AI product development is context engineering. What information does the model see for each interaction? How is it structured? What is included, what is excluded, and why?

A naive approach loads everything: the user's entire history, all their data, every possible reference. This degrades output quality because the model has to search through noise to find signal. A better approach is surgical: identify what the current task requires and load precisely that. The user's brand voice for content tasks. Their campaign history for analytics tasks. Their audience segments for email tasks. Different tasks, different contexts.

This sounds obvious but it is not easy. It requires understanding each task deeply enough to know what information makes the output better and what information just fills the window. It requires building a retrieval system that can assemble the right context quickly enough for a real-time interaction. And it requires constant tuning as the product evolves and new information types become relevant.

Tool design

The model's ability to take actions in the world, calling functions, querying data, creating artifacts, is another leverage point that matters more than model selection. A well-designed tool gives the model a clear interface: here is what this action does, here are the inputs, here is what success looks like. A poorly designed tool creates ambiguity that even the best model will sometimes resolve incorrectly.

Tool design is API design for an AI consumer. The same principles apply. Clear naming. Consistent parameter patterns. Predictable error responses. Minimal surface area per tool. The model should never have to guess what a tool does or what parameters it needs. That ambiguity is where mistakes live.

Output handling

What happens after the model produces a response is as important as the response itself. Validation, formatting, sanitisation, error detection, structured extraction. The raw model output is rarely what the user should see. It needs to be processed through layers that ensure consistency, safety, and quality.

This is not a limitation of the model. It is a feature of the architecture. The model generates. The output layer governs. Separating these concerns means you can change governance rules without retraining the model and change models without rewriting governance. This separation is what makes an AI product maintainable over time.

The swap test

A useful thought experiment: if you swapped your model for a different one of comparable capability, how much of your product's quality would change? If the answer is "most of it," your product is the model and you have no moat. If the answer is "some of it, but the context assembly, tools, and output handling would carry most of the quality," you have built something that is more than a thin wrapper around an API.

The best AI products will survive a model swap. They might need tuning, but the core quality comes from the engineering around the model, not the model itself. That engineering is the product.

The model is the engine. Everything around it is the car. Nobody buys a car for the engine alone.

- Cleo's Team

C

Written by Cleo's Team

Building Cleo, an AI marketing operating system. These posts cover the architecture decisions, technical challenges, and lessons learned along the way.

More from the workshop