Inference, context, evals: AI principles before models

When a team starts building with AI, the conversation quickly moves to model choice. Should we use Fable, GPT, Gemini, Claude, an open source model, or some hybrid routing setup? It is a fair question, but it often arrives too early.

The model matters. Pretending otherwise would be naive. But in many AI products, the difference between an interesting demo and a reliable system does not come only from the model. It comes from how the team handles inference, context, evals, fallback and review.

Those words are less exciting than a model launch, but they decide whether the system stays useful when it leaves the demo.

Inference is not an API call

In everyday language, inference can start to mean “calling the model”. For an AI product, inference is the moment when a request enters a system and produces an answer that someone will use to decide, write, search, correct or act.

Inside that moment there are many choices: which model to use, with what effort level, with what context, with which tools, with what memory, with which output schema, with which safety limits and with what fallback. Two teams can use the same model and get very different results because they designed everything around the call differently.

That is why “which model is best?” is rarely enough. A better question is: best for which task, with which context, at what cost, and with what acceptable margin of error?

Harnessing: the system around the model

I use “AI harnessing” in an operational sense: not as a slogan, but as the layer that holds together model, tools, context, limits and human responsibility. A powerful model without a harness remains an isolated call. It may work well in a demo, then become fragile once it has to operate inside a real process.

For a team, this means designing what enters the request, which tools the model can use, which outputs are acceptable, which steps require review and which conditions should stop the flow. The value is not only in prompting the model better. It is in building the operating context that lets the model be useful without moving control away from the team.

Context is part of the product

Models do not work in a vacuum. They respond to what they receive: instructions, examples, documents, memory, tools, retrieved data, constraints written into the prompt or the surrounding system. If the context is vague, noisy or incomplete, the model can still produce an elegant answer. That is exactly what makes it dangerous.

A reliable AI product does not treat context as an attachment. It treats it as product material: versioned, reviewable, updated, reduced when it is noisy, enriched when something important is missing. For an internal assistant, for example, the question is not only “did we connect the knowledge base?”. The team also needs to know who maintains it, how old sources are handled, and how the system separates what is reliable from what is stale.

The same applies to Claude Code or any coding agent. Context is not only the repository. It is also AGENTS.md, conventions, tests, architectural decisions, security constraints, and all the things the team assumes but the model cannot guess.

Evals are where the product stops being a demo

Hamel Husain has written that many AI products fail because they do not build strong evaluation systems. That matches what often happens in teams: at first, progress comes from prompt engineering and manual trial and error. Then the surface area grows and improvement turns into whack-a-mole. One thing gets fixed and another breaks.

Evals help the team get out of that cycle. They do not need to be sophisticated at the start. They can begin with real cases, good and bad examples, manual checks, conversation logs, and simple rubrics. What matters is that the team stops judging the system only by how it feels in the moment.

A useful eval answers practical questions: does the system retrieve the right source? Does it respect constraints? Does it admit when it does not know? Does it produce something a person can use without rewriting it from scratch? Does it fail in a way the team can understand? Is it better than the previous version?

If those questions are not written down, every model, prompt or retrieval change becomes a bet.

Fallback and review are not defensive details

Many AI systems are designed around the happy path. The user asks, the model understands, the context is correct, and the answer is good. Operational value appears when something does not work.

What happens if retrieval does not find enough context? If the model is blocked by a policy? If the cost of the call is higher than the value of the task? If an answer looks correct but touches sensitive data, critical code or commercial decisions? That is where fallback and review matter.

A fallback is not a failure. It can be a different model, a clarification request, a handoff to a human workflow, a more cautious response, or a ticket. Review is not bureaucracy when it protects the places where mistakes are expensive.

The maturity of an AI system also shows in how it fails.

Why this matters for a PM builder

A PM building with AI does not need to become a model researcher. But they do need to understand these principles well enough not to delegate everything to vendor choice. If the only decision is “use the strongest model”, the product remains fragile. The Fable 5 case shows the same pattern at frontier-model level: access, safeguards, evals and fallback matter beyond raw capability.

The interesting work is designing the system around the model: what context to provide, which tasks to delegate, which errors are acceptable, how quality is measured, when to stop, and when to ask a person. That is product work as much as it is technical work.

A better model can increase the margin. But without context, evals and review, that margin is often spent on errors that are harder to see.