There's a conversation that repeats in every AI meeting: which model should we use? Benchmarks get compared, prices per million tokens get debated, someone mentions a new one shipped last week.
It's a nearly irrelevant conversation.
Not because models are interchangeable — they aren't — but because the difference between an AI system that works in production and one that doesn't is almost never the model. It's everything around it.
The thought experiment
Picture two teams building the same support assistant.
Team A uses the most capable model on the market, with an eight-hundred-word prompt describing the whole process: how to classify, when to escalate, what tone to use, what never to say.
Team B uses a mid-tier model, but splits the process into five explicit steps. Each step has its own call, its own output validation, and a defined path for when that validation fails.
In the demo, A wins. It feels smoother, handles odd cases better, and took two days instead of two weeks.
Three months in, B wins by a landslide. And the reason isn't subtle.
What happens when it fails
A's system fails as a black box. The user reports "it answered nonsense", and the team has an eight-hundred-word prompt and a log with one input and one output. There's no way to tell whether the model misclassified, failed to find the document, or found it and read it backwards.
The typical response is to edit the prompt. Add a sentence. "IMPORTANT: never invent return policies." And it works, until it breaks something nobody was watching.
B's system fails at a specific step. The log says: step 2, context retrieval, zero documents above the similarity threshold. The problem isn't the model, it's the index. And that's fixable.
The four pieces almost nobody builds
1. Explicit boundaries between steps
Every step needs a contract: what it takes, what it returns, in what shape. If the "classify intent" step can return any string, it isn't a step — it's a hope. It should return one of seven known values, or fail.
This is boring and it's the most important thing in this article.
2. Validation on the output, not just the input
Validating user input is obvious. Validating model output is something far fewer people do, and it's where the real risk lives. If the model must return JSON with three fields, parse it and check all three before passing it anywhere.
When validation fails, you have real options: retry at a lower temperature, fall back to a deterministic path, or escalate to a person. All of them beat propagating garbage.
3. Tracing by default
Every run should record each step with its input, output, latency and cost. Not as an advanced observability feature — from the first commit.
The day a client asks why the system did something, the difference between answering in two minutes or two days is exactly this.
4. An eval set that runs in CI
Twenty or thirty representative cases with expected output, running on every prompt change. It doesn't need to be sophisticated. It needs to exist.
Without it, every modification is a gamble and the team develops a fear of touching anything. I've seen prompts nobody dares change because "it works and we don't know why".
The uncomfortable corollary
If you build these four pieces well, the model becomes a configuration variable. You can try a cheaper one and measure whether quality drops. You can switch providers in an afternoon. You can use a different model per step.
If you don't build them, you're married to one specific model and to a prompt nobody fully understands — including whoever wrote it.
The right question isn't "which model should we use?". It's "how do we know when it got it wrong?".
What to do on Monday
Take whatever AI system you have running and answer three questions:
- If the model returns something unexpected right now, what happens?
- Can you reconstruct why it gave a specific answer a week ago?
- How many test cases run automatically when you change the prompt?
If any answer is uncomfortable, you know what to work on. And it isn't switching models.