Context Engineering: Supply the Right Evidence for Each Request

Reviewed and updated October 8, 2026.

When an AI answer is wrong, check what information the model actually received. The right fact may be absent, stale, attached to the wrong entity or buried in irrelevant material. Changing the model cannot reliably repair evidence that the application never supplied.

Context engineering decides what instructions, documents, structured facts, tool results and remembered state enter a request. It is a request-time problem. Data preparation establishes the sources and definitions from which that context can be assembled.

Diagnose the failure before adding memory

Preserve a trace of selected source identifiers, versions and tool outcomes under appropriate access controls. Compare the failed request with the evidence required for the task. Ask whether retrieval found the source, selection kept it, the source was applicable and the generated claims followed from it.

Anthropic's context engineering guidance treats context as a finite resource and discusses retrieval, compaction and persistent notes. Those methods have different uses; adding all available material is not a complete strategy.

An illustrative account explanation

Consider a request: “Why did this account's renewal estimate change?” This example is a proposed design, not a client result. A useful answer may need the account identifier, the prior estimate, the current approved estimate and the changes explaining the difference.

Resolve the account from the authenticated user's permitted selection. Query the approved fields using stable identifiers. Include the two estimate versions, the reporting cutoff and relevant change records. Retrieve contract clauses only if the explanation depends on them. A large collection of unrelated account notes can obscure the comparison and increase exposure without improving the evidence.

Require each numerical explanation to refer to the supplied fields. If the reason for a manual adjustment is missing, say which record is absent and route it to the account owner. The model should not turn a plausible business explanation into a reported fact.

Give each context item a role

• Instructions: approved task rules and output requirements, controlled by the application.
• Evidence: authorized facts with source, version and applicability. External content remains untrusted input.
• State: recorded progress and approved decisions. A remembered preference must not become permission to act.
• Tool results: structured outcomes, including denied, unavailable and incomplete states.

For long context, test document order, distraction and conflicting versions. Lost in the Middle found position-sensitive performance in the models and tasks studied. It is a reason to test your configuration, not proof that every current model fails the same way.

Prefer a simpler context path when it works

A stable procedure may fit in direct context. Exact current account values may be better obtained through an authorized API. Retrieval helps select relevant evidence from a larger collection. Memory is useful only when retaining information across requests serves the task and its correction, deletion and permission behavior are defined.

Evaluate missing evidence, superseded records, ambiguous entities and revoked access. Score citation correctness separately from fluency. If context is incomplete, preserve an explicit uncertainty or review path rather than silently broadening the search to unapproved sources.

See enterprise knowledge assistants for a source-backed application. Request a project review with a failed question, the evidence it needed and the sources the user was allowed to access.