NOVRA Intelligence

Two teams building the same application on the same model routinely get materially different results, and prompt quality no longer explains most of the gap. What explains it is the machinery around the model: what gets retrieved and when, what persists between steps, which tool descriptions occupy the window, what the system refuses to put in front of the model at all.

This is not a claim that models have stopped improving or that model choice no longer matters — for frontier reasoning tasks it plainly does. The narrower and more defensible observation is that as frontier capability becomes less differentiating for many production workloads, the context system increasingly determines reliability, control and operational performance. Two organisations with access to the same models are now separated mostly by what they do with the tokens around them.

That surrounding machinery has a name now — context engineering — and the name undersells it. It is not a technique. It is the layer that decides what the model can know, what it can do, and what it can be manipulated into doing. In an operating system, that layer is called the kernel, and the analogy is closer than it looks: both arbitrate a scarce resource among competing claimants, and both are the place where privilege boundaries either exist or do not.

The argument here is narrow and specific. Context should be treated as a typed, permissioned, decaying resource with a supply chain — not as a string. Systems built on the string model fail in ways their builders find surprising. Systems built on the resource model fail in ways their builders anticipated.

The window is not the system

A context window is a capacity. A context system is the set of decisions about how that capacity gets filled, by whom, and on what schedule. Conflating them is the most common architectural error in production AI, and larger windows have made it worse rather than better: when the budget was tight, teams were forced to choose deliberately. With a million tokens available, the default became “include it and let the model sort it out.”

The model does not reliably sort it out. Retrieval quality degrades as irrelevant material accumulates, and the effect compounds with context length — the phenomenon usually called context rot. Anthropic’s engineering guidance frames the underlying constraint plainly: everything in the window competes for the same finite resource, so system prompts, tool definitions, examples, message history and retrieved data are in direct competition with each other. Academic work on long-context agents makes the same point empirically, benchmarking agent behaviour specifically under uncontrolled context growth.

The practical consequence is that adding a document to the context is never free, even when it fits. It is a withdrawal from a budget shared with everything the system actually needs the model to attend to.

Five kinds of context, and why the distinction is load-bearing

Treating context as one substance is what makes the failures hard to diagnose. In production systems it separates cleanly into five classes, and they differ on the two dimensions that matter: origin trust and lifetime.

Instruction context — the system prompt, operating rules, role definition. First-party, long-lived, changes on deploy. This is the only class the operator fully controls.

Retrieved context — documents, records, search results pulled at runtime. Variable trust, short lifetime, and the class most likely to be stale in ways nothing in the system detects. A retrieved record is a claim about the world at retrieval time, not a fact.

Tool context — tool names, descriptions, schemas, and returned results. This is chronically underestimated. Tool descriptions occupy the window permanently and are read by the model as instructions; tool results are third-party data arriving mid-reasoning. Both matter, and they have opposite trust profiles.

Memory context — what the system carries between turns, sessions or steps. Long-lived by construction, which makes it the class where errors compound silently. A wrong fact written to memory in step 3 is still wrong in step 40, and by then it has been referenced enough times to look established.

Policy context — what the system is permitted to do. Almost always expressed as text in the window, and this is the mistake the rest of this article turns on.

The two dimensions predict the failure mode. Short-lived, low-trust context produces poisoning. Long-lived, high-volume context produces rot. Long-lived, low-trust context — retrieved material written into memory without validation — produces both, and is where the worst production incidents live.

Policy expressed as text is advisory, not enforceable

Here is the claim most likely to be resisted, and the one with the largest practical consequence.

Anything that exists only as tokens in the context window is a request to the model, not a constraint on the system. “Never issue a refund above $500” in a system prompt is a strong prior, not a control. It shares the window with retrieved content, tool output, and user input — all of which are, from the model’s perspective, more tokens of the same kind. Prompt injection is not an exotic attack; it is the predictable result of putting instructions and untrusted data into a single undifferentiated channel and asking a statistical model to maintain a privilege boundary between them.

The architectural correction is simple to state and unpopular to implement: enforce authority outside the model. The refund limit belongs in the code path that executes refunds, where it is a comparison the model cannot argue with. The model may propose a $5,000 refund; the system declines to execute one. The same logic extends to anything with consequences — which is why irreversible actions are better placed behind deterministic control layers than behind carefully worded instructions.

Stated as a design rule: the context window is where the system explains itself to the model; it is not where the system defends itself from the model. Once that separation is explicit, a large class of prompt-injection concerns stops being a model-behaviour problem and becomes an ordinary authorization problem, which is a category the industry already knows how to solve.

Context has a supply chain

Because context arrives from multiple origins with different trust levels, it has the structure of a supply chain, and it benefits from the same discipline applied to software dependencies: know the provenance of every input, and treat unverified inputs as untrusted by default.

In practice this means three things engineering teams do not do today.

Tag context by origin at assembly time. Not conceptually — structurally. The assembly step should know, for every block it places in the window, whether that block is first-party instruction, verified record, or unverified third-party text. This costs almost nothing and it is the prerequisite for every other control, because you cannot apply a policy to a category you have not marked.

Bound each class independently. A single token budget for “context” allows retrieved material to crowd out operating instructions under load — a failure that appears as inexplicable rule-breaking during exactly the busy periods when it is hardest to diagnose. Per-class budgets make the trade-off explicit.

Give memory an expiry and a writer. Most memory implementations answer “what should be remembered” and never answer “for how long” or “on whose authority.” Both omissions are how a low-confidence inference becomes a durable system belief.

Just-in-time beats just-in-case, with one exception

The prevailing pattern has shifted from preloading everything to retrieving at the moment of need, and the reasoning is sound: relevance is easier to judge when the question is known, and the budget stays available for what is actually being reasoned about. Sub-agent architectures extend the same idea by isolating a noisy task in a separate context and returning only a condensed result, so the coordinator’s window is spent on conclusions rather than raw material.

The exception is worth naming because it is where just-in-time retrieval quietly fails: context the model needs in order to know it should retrieve something. A system that must fetch a policy document before it can determine whether a policy applies has a bootstrap problem, and the usual symptom is a system that behaves correctly on obvious cases and skips the check entirely on unusual ones. Enough context must be resident to make the decision to retrieve reliable, and identifying that minimal resident set is real design work rather than a tuning parameter.

Evaluation is context too, and it is usually wrong

Evaluation context — the examples, rubrics and prior cases a system uses to judge its own output — is the class most likely to be built once and never revisited. It is also the class where staleness is invisible, because a stale evaluator still returns confident scores.

Two disciplines follow. Evaluate the assembled context, not the prompt template: what matters is the window as it existed at the moment of the decision, which means the assembled context has to be captured. And version the evaluation context separately from the system it evaluates, or improvements and regressions become indistinguishable — a scoring change and a behaviour change look identical from the outside.

This connects directly to the reliability budget across a multi-step system: per-step verification is only as good as the context the verifier is given. A cheap deterministic check on a well-specified input is worth more than an expensive model-based judgment on a window nobody captured.

What this changes for a technology organisation

The strategic implication is a reallocation, not a new initiative.

Model selection is a decision with a short half-life — worth making well, worth revisiting often, and rarely worth building an organisation around. Context architecture is the durable asset: the retrieval layer, the memory model, the provenance tagging, the assembled-context logging, and the enforcement points that sit outside the window survive model changes and generally improve with age. Where a workload is not capability-bound, effort spent at the model layer is being spent on the component with the shortest depreciation schedule.

Two consequences follow for how systems are built and governed. Context assembly becomes an auditable step — the assembled window is the artifact that explains a decision, which makes it the thing worth logging and checkpointing as load-bearing state, and which maps directly onto the traceability expectations in frameworks like the NIST AI Risk Management Framework. And authorization moves out of the prompt and into the execution path, where it can be tested, reviewed and evidenced like any other access control.

None of this is exotic. It is the same move systems engineering has made before: when a resource becomes contended and a channel carries mixed trust levels, you type the resource, budget it, and put the privilege boundary somewhere it can actually be enforced. Much of the industry still treats context as a prompt. It behaves like a runtime, and the systems that treat it as one are the ones that survive contact with production.