The model is not the system

An architecture review opens on a slide with one rectangle carrying a vendor's name, with arrows running out to a calendar API, a vector store, and a checkout service. Someone asks where allergy enforcement lives, and after a pause a senior engineer says the model handles it. The answer is accepted, because on the evidence available that morning it was true.

Six months later the vendor ships a weight update. Tuesday's suggestions shift, refusals soften into polite maybes, and purchase proposals grow bolder, while nothing in the team's repository has moved. Nobody can say which behaviour was supposed to hold, because the commitments were never written anywhere a person could read them back.

The failure is easy to describe after the fact and worth stating as a rule before it happens. The model is the one component in the system whose implementation you do not own and whose behaviour can change on somebody else's schedule, which is why every commitment stored inside it is a commitment held on loan. Treating the model as an engine inside bounded calls follows from who controls the thing, rather than from any preference about how architecture diagrams ought to look.

Helpful context: What is Thoughtware places models inside a category rather than at the centre of one. Fluency is not evidence covers why a better-sounding answer is not a better-grounded one. This page works out what has to sit outside the call before the deeper cognitive unit architecture becomes useful.

The one component you do not own

Most of what a working engineer knows about calling functions transfers to calling a model. The call is awaited, it can fail while you wait, it composes with other calls, it parallelises, and it costs money every time. What does not transfer is ownership of the body.

When you call a function in your own codebase, the code that runs is in your repository, under your version control, changing when somebody on your team changes it. When you call a model, the template is yours and the thing that interprets the template is not. It belongs to a vendor, changes on their schedule, and can behave differently while your repository sits untouched. The right mental model is a remote procedure call to a third party, since nobody assumes a remote service is unchanged since last quarter.

That single fact is where the rest of the argument comes from. Anything you place inside the call inherits the vendor's release cadence, and anything you place outside it inherits yours.

What the model cannot decide about itself

Ownership of the implementation is the practical problem. Underneath it sits a second one that would remain even if you trained the model yourself: several of the things teams put inside the call are not the kind of thing a producer of answers can settle.

A model does not decide its own legitimate authority, does not determine which knowledge the organisation has approved, does not set the quality standard its output will be measured against, and does not carry institutional responsibility for what follows from an action. Each of those is a question about standing rather than about capability, and standing is conferred from outside by whoever bears the consequence. An engine that granted itself permission to complete a grocery purchase would be asserting something about a context it has no way to see.

The same limit shows up at the level of one call, and it is the version that bites soonest. The model produces a candidate answer to an open judgment, which is work where several answers could be defensible and somebody has to own the one that ships, as what judgment is sets out. Producing a candidate is not owning the result, and the gap between the two is visible in how the thing fails: a broken function throws, while a broken call returns something fluent, correctly shaped, plausible, and wrong. Whatever detects that failure has to be outside the call, because the thing being checked cannot be the thing doing the checking.

Where the commitments have to live instead

Once you accept that the engine is rented and cannot vouch for itself, the design question becomes concrete: which commitments must survive a change of engine, and where do they go. In the Weekly Meal Companion the answer is short, and each row is somewhere a person can point.

Commitment	Where it lives
Leena's confirmed cashew allergy is never violated	Deterministic validation over endorsed knowledge
Groceries are proposed, never bought	Approval gate in the permission layer
Whether a meal fits a busy evening is a named judgment	AssessMealPracticality, with a contract and a suite
That judgment is reusable by other planners	Placement in the meal-planning domain library
The current plan version is unambiguous	Ordinary code in the deterministic shell

AssessMealPracticality may call one vendor today and a different one next quarter, and the responsibility it owns does not move when that happens. The allergy check never passes through the call at all, since it was closed the moment the household confirmed it, and closed work belongs in deterministic code rather than in a paragraph of instructions asking a model to be careful. Any row on that list that would move when the engine changed was never architecture, only a side effect of prompt wording.

The loop that ties those rows together is ordinary code for the same reason. Flow is execution, and replacing it with "let the model decide what to do next" surrenders decision locality, explicit stopping, and surgical repair in one pass, which is why the agent is mostly ordinary code in mature systems.

What moves when you swap the engine

The diagram test people usually reach for, whether your architecture is more than one box, is a proxy for something sharper. The real test is a swap: change the engine and count what else has to change with it. In the structure above the answer is one thing, the implementation inside a single cognitive unit, and everything else holds by construction.

That is not the same as saying a swap is free, and the difference matters more than it first appears. Evidence about a cognitive unit belongs to its template and its model together rather than to the template alone, so a suite measured on one engine says nothing reliable about another. Larger models sometimes reason past the obvious on simple inputs, improving the average while quietly getting worse on the easy class you specifically cared about. A well-structured system converts that risk into a bounded, priceable act rather than removing it, since the remedy is to rerun the suite for that one responsibility and compare.

Evidence belongs to a template and model pair, not to a template.

The cognitive unit · Ch. 2

That is what makes a provider upgrading a model beneath you an event rather than a footnote. Your implementation changed and your version number did not, and that is the definition of a silent dependency update, as silent model upgrades develops. The team with contracts and suites at named boundaries finds out from a failing suite, but the team whose commitments lived in prose finds out from a household.

Why a better model does not shrink the problem

The obvious objection is that all of this is scaffolding for weak engines and will be obsolete once the engines are strong enough. The objection has a real observation inside it: greater capability can reduce visible orchestration, and work that once needed four steps can collapse into one call.

What that collapse does not touch is any of the questions this page has been about. A stronger engine still does not name the judgment it is performing, define its boundary, produce evidence about its own behaviour, or acquire the authority to act. It makes each of those easier to build and leaves all of them necessary, which is why capability improvements tend to raise the stakes of missing structure rather than lower them: the same architecture now runs faster, further, and with more confidence behind a wrong result.

The version of this that costs teams money is subtler than a wholesale upgrade. Moving to a more eloquent model improves phrasing and leaves every enforcement gap exactly where it was, and a beautifully worded apology for a three-course plan on a busy Tuesday is still a failure of locality and evaluation. Fluency is the property that improves most visibly with each release, which is precisely why it is the worst available proxy for whether the system got better.

What to do next

Redraw your own architecture without a central model box and see what is left holding a name. Put the outcome, the named judgments, the deterministic shell, the memory forms, and the evidence at the perimeter, then ask which of them would move if you changed vendors tomorrow. Whatever moves is a commitment you are currently renting.

The exercise usually produces one uncomfortable row and one useful question, which is how a judgment gets packaged so that it can be improved, versioned, and substituted without the rest of the product noticing.

Read next: Cognition as material for why packaged judgment survives an engine swap in the first place.