When an AI system does the wrong thing, the instinct is to add a rule. "Do not do X." "Always do Y." "When you see Z, respond with W." This works sometimes. But more often than you would expect, the problem is not that the model ignored an instruction. It is that the model could not see the information it needed to follow the instruction correctly.
This distinction matters because the two problems have opposite solutions. An instruction problem is solved by better prompting. An information problem is solved by better context assembly. If you misdiagnose the cause, you pile up instructions that address symptoms while the root cause persists.
The invisible state
Consider a system that helps users manage email campaigns. The user says "send a test." The AI, instead of sending a test email, rewrites the campaign content. From the outside this looks like the AI misunderstood the instruction. The obvious fix is to add a rule: "When the user says send a test, use the send function, not the edit function."
But the real question is: what could the AI see when it made that decision? If the campaign was in draft state and the AI could not see the current status, it might have reasonably concluded that the campaign needed revision before sending. The instruction was clear. The context was not.
This pattern repeats constantly in production AI systems. The model behaves in ways that seem irrational until you examine what information was available at decision time. Missing status fields. Stale data. Truncated context. Information that exists in the database but was not loaded into the prompt. Once you see the world as the model saw it, the "wrong" decision often looks reasonable.
Diagnosis before prescription
The most expensive mistake in AI product development is treating every output problem as a prompt problem. Prompt changes are cheap to make and feel productive. You add a line, test it, see improvement in that specific case, and ship it. But prompt instructions that compensate for missing information create a fragile system. They work for the exact case you tested and break for adjacent cases where the missing information matters differently.
A better diagnostic process asks three questions in order. First: what information did the model have when it made this decision? Second: was the correct decision determinable from that information alone? Third: if not, what was missing?
If the answer to the second question is yes, the model had everything it needed and still got it wrong, then it is a prompt problem. Add the rule. But if the answer is no, if the correct decision required information the model could not see, then no amount of instruction will fix it reliably. You need to fix the information pipeline.
Context as architecture
In a traditional application, the user interface shows the user what they need to make decisions. In an AI product, the context window is the model's interface. It shows the model what it needs to make decisions. The quality of that interface determines the quality of those decisions.
This means context assembly, the process of deciding what information to load into the prompt for each interaction, is an architectural concern. Not an afterthought. Not a "just include everything" strategy. A deliberate, engineered system that identifies what the model needs for the current task and provides it efficiently.
Over-inclusion is as harmful as under-inclusion. Flooding the context with irrelevant information degrades the model's ability to identify what matters. A lean context with precisely the right information produces better output than a large context with everything.
The compound benefit
Fixing information problems instead of instruction problems has a compound benefit. Each instruction you add competes with every other instruction for the model's attention. A system prompt with three hundred rules is harder to follow than one with thirty, even if every rule is individually clear. But each improvement to context assembly makes every instruction more effective, because the model can now see the state it needs to apply the rules correctly.
Over time, teams that invest in context engineering find they need fewer prompt rules, not more. The rules they keep are genuinely about behaviour: tone, formatting, boundaries. The rules they remove were always compensating for missing information.
The model is not ignoring your instructions. It is making the best decision it can with what it can see. Show it more and it will do better. Tell it more and you are just hoping louder.
- Cleo's Team