Three Years of Notes, One Sentence
Reading back through what we have published, the same finding appears under a dozen different headings. It is not a principle we set out with. It is what was left after each attempt to enforce something the easy way failed in production.
The Same Finding, Repeatedly
A document told our extraction step what to do and it complied, so we removed the tools from that step. A prompt told an agent not to modify the pipeline and it did, so we removed the permission. An instruction told an assistant to say when it did not know and it did not, so we made retrieval decide.
Each was written up separately, months apart, as a specific lesson about a specific system. Put together they are one lesson, and it took considerably longer to see that than it should have.
What the Sentence Actually Says
Anything you want to be true of a system has to be made true by something that cannot decide otherwise. A prompt is a request to a component that is free to ignore it. A document is a request to a person who may not read it. A credential scope, a tool list, a schema and a separate index are none of those.
Besanson published work in 2026 arguing that governance controls are commonly attached to prompts, dashboards and documentation after the fact, and that this creates a structural mismatch with what the controls are supposed to guarantee.
| Wanted property | Where we put it |
|---|---|
| Content cannot issue commands | The reading step has no tools |
| An agent cannot break its own tests | A token without that permission |
| No answer without evidence | Retrieval threshold, before generation |
| One tenant cannot observe another | Separate index, separate cache |
Where We Learned It, Briefly
The supplier footer that gave orders. The agent that edited the workflow running its tests. The assistant that abstained on two percent when it should have on nine. The shared cache that leaked through timing. The index that answered questions about documents a user could not see. The memory a colleague could write to. The self-improving prompt with no nameable version. The review screen that showed everything and helped less.
Eight systems, eight write-ups, one shape. In every case the first fix was textual, it worked in testing, and it failed on contact with a situation nobody had described in the text.
The Two Cases Where It Was Not Available
Answer quality, and expectations. There is no architectural mechanism that makes an answer correct, and none that makes a user understand what a system is for. Both had to be handled with measurement and conversation, which are weaker instruments and the only ones on offer.
That is the honest boundary of the sentence. It applies to what a system may do, not to how well it does it, and treating a measured error rate as if it were an enforced constraint is the mistake in the opposite direction.
Why the Textual Version Is Always Tried First
Because it is fast, it demonstrates well, and it usually works. A prompt instruction handles the ordinary case immediately, and the failure appears weeks later in circumstances that look like bad luck rather than like a design decision.
We still write the instruction. It is worth having and it is not the control, and our reviews now ask, for each stated property, what would enforce it if the model ignored the instruction entirely. Where the answer is nothing, the property is a hope.
What This Costs
More components. Separate indexes, separate credentials, separate servers by scope, a gateway, a validator per step. Every one of those is infrastructure that has to be run and understood, and a system built this way is harder to explain than one held together by a well-written prompt.
That is a real cost and we have paid it wrongly at least once, when a small internal tool got a permission model it did not need. The sentence is a default rather than a law, and the question that scales it is what a failure would cost here.
What We Would Tell Someone Starting
Write the properties down before the system exists, in the customer's words, and next to each one write what enforces it. Where the answer is a prompt, a document or a training session, mark it and decide deliberately whether that is acceptable for this property in this process.
Most of the time it is. The value of the exercise is the small number of rows where it obviously is not, and those are the rows that would otherwise have become an article like the eight above.
What We Do Not Claim
We do not claim architecture guarantees anything. A tool list can be wrong, a credential can be over-scoped, and a separate index can be built from the wrong permission model. What changes is that those are mistakes someone can inspect rather than behaviour someone has to trust.
We also do not claim this generalises past the kind of work we do. Everything here comes from bounded business systems with documents, records and consequences, and a team building something open-ended may reasonably find that the constraints they need cannot be expressed this way at all.