Many agent failures begin before the model generates a token.
When an agent fails, the model gets blamed. Often the cause is upstream, in the information environment somebody assembled around it.
Context engineering is the design and runtime management of what an agent is allowed to know, trust, remember, and act on. It is the Q dimension of readiness, and for most teams it is the fastest place to make an agent measurably better, because it can be changed this week without retraining anything.
On any given turn, the model sees a single block of text assembled from very different sources.
Those sources deserve different standing, and naming that standing explicitly is the whole discipline.
To the model, a sentence in your system prompt and a sentence inside a retrieved PDF are both simply text in the window. Whatever difference exists between them has to be created and enforced by the layer that assembles the context.
Once those categories are explicit, useful rules become available: instructions outrank evidence, untrusted content cannot introduce policy, stale memory can be challenged, and high-impact facts require provenance. The injected waiver that later defeats the payment agent in Chapter 16 disappears the moment the attachment is labeled as evidence rather than merged into the instruction channel.
We assess context before the agent is invoked at all, reading the system prompt, the tool schemas, and whether a knowledge corpus was supplied.
| Criterion | What it checks | Typical failure |
|---|---|---|
| Role clarity | Role, scope, goals and success criteria are explicit | Goal drift |
| Guardrail coverage | Refusals, escalation and restricted actions are specified | Unsafe compliance |
| Instruction consistency | Directives are coherent and ordered by precedence | Rule conflict |
| Tool schema quality | Names, arguments, side effects and when-to-call are clear | Tool misuse |
| Grounding sufficiency | There is enough reliable evidence for the claims it must make | Hallucination |
| Injection hardening | Trusted instruction is separated from untrusted content | Prompt injection |
| Token efficiency | The context spends its budget on reliability | Context bloat |
Seven criteria are assessed; five contribute to the score.
Instruction consistency and token efficiency are reported and deliberately excluded, because both improve as the artifact shrinks. An almost-empty prompt has nothing to contradict and no boilerplate to trim. On a deliberately thin 450-character prompt those two criteria scored 90% and 80%, which lifted its overall context score above a substantially better 1,033-character prompt and inverted the ranking. A criterion that rises as the artifact empties cannot serve as evidence of quality, so we demoted it rather than defending it.
Context is scored independently of behavior on purpose. Derived from behavioral results, it could not predict them; kept independent, it becomes a signal you can read before a scenario exposes a weakness.
To isolate the effect, we held the agent model fixed and changed only the information environment around it, across three conditions and three regulated domains. C1 Poor has a vague role, weak tool guidance, limited grounding, and little guardrail coverage. C2 Structured adds a clear role and scope, typed schemas, and domain grounding. C3 Hardened adds explicit refusal conditions, escalation thresholds, injection separation, and confirmation requirements.
The result is practical. Moving from poor to structured context nearly doubled overall behavior and cut critical failures from an average of 4.11 per run to 1.33, with no change to the model. Hardening raised context quality further, from 8.08 to 8.68, while behavioral scores plateaued — by that point the remaining failures were no longer context failures.
The criteria also behave as designed, each predicting the outcome it was built to predict.
Grounding sufficiency predicts hallucination resistance. Guardrail coverage predicts manipulation resistance. Instruction consistency predicts instruction following. Tool schema quality predicts tool use. That correspondence is what makes context assessment a governance instrument rather than a style guide: a weak criterion tells you which behavior to expect to fail, before it fails.
Context changes with every turn. A tool result becomes new evidence. A retrieved page introduces untrusted text. A summary replaces raw history. A sub-agent contributes a conclusion. You can begin a session with a carefully designed prompt and end it with a degraded context, which makes this a runtime discipline rather than a document review.
Memory needs its own rules for the same reason. Decide what may be written, by whom, with what provenance, and for how long, and define how a wrong entry gets corrected. Any constraint that affects safety, a legal obligation, or an entitlement should survive the whole session — and when a safety-relevant constraint is lost, it is worth recording as a safety finding rather than a memory finding, because that is what the consequence will be.
Improving context is also the most available intervention. You probably cannot retrain the model, but you can almost always sharpen role boundaries, ground the sources, type the tool descriptions, separate trust, and specify escalation. Measuring it turns that work into a loop: assess, change, re-evaluate, compare.
A strong model operating in weak context can still produce an unreliable agent.
Score the context before testing the behavior, then use the weak criteria as predictions. This is the fastest improvement available to most teams, because context can be changed this week without retraining anything.