Why the Loop Outlives the Model
A note on why much of what a user experiences in an action-taking system comes from the software around the model, and why that software is what survives a model change.
When an assistant refuses something, retries twice, stops halfway, or answers instantly from a cache, it is tempting to read all of that as the model's character. Usually it is not.
Much of the behaviour a user experiences is decided by the software around the model. Which tools exist at all. What the system is permitted to do. What it remembers between steps. How many times it retries. What counts as finished. None of those live in the parameters, and all of them are visible to the user as behaviour.
This matters for two practical reasons.
Debugging
A model you cannot inspect fails as a mood. A loop you can inspect fails as a specific step with a specific reason.
If you treat a bad outcome as a model problem, the available responses are vague: change the wording, try a bigger model, hope. If the surrounding software is explicit, the same failure has a location. Something was denied, or errored, or timed out, or returned a result nobody checked. You can open that and look.
A model you cannot inspect
- Fails as a mood
- The available responses are vague: change the wording, try a bigger model, hope
A loop you can inspect
- Fails as a specific step with a specific reason
- Something was denied, or errored, or timed out, or returned a result nobody checked
If the surrounding software is explicit, the same failure has a location.
Swapping models to fix a problem that lives in the loop is a common and expensive mistake, and it usually appears to work briefly.
Upgrading
Models get replaced. A better one ships, a cheaper one appears, a provider changes its terms. The sensible move is to change the model without rebuilding the system around it.
That is only possible when the surrounding software holds the contracts: what a step may do, what counts as done, what evidence a decision leaves behind. When those live in the loop, the model becomes a component you can exchange. When they live in prompt prose, every upgrade is a rewrite.
This is not an argument that model quality does not matter. It plainly does, and a weak model inside an excellent loop is still a weak system. The point is narrower: capability and behaviour are not the same property, and only one of them survives a version change.
The name for that surrounding software is the agent harness. For the control path this note refers to, see from agent intent to governed execution.
Where this helps, and where it stops
- What it is
- A short note on where observed behaviour in an action-taking system actually comes from.
- What it does not guarantee
- A description of the control path itself, which has its own page, and not a claim that model quality is unimportant.
- When the distinction matters
- A system behaves unexpectedly and the model is the first thing blamed or replaced.