Context Engineering

A prompt is one component of context; context engineering also controls how information is selected, represented, refreshed and removed. An application may retrieve documents before a call, expose only tools relevant to the current task, summarize an older conversation, or load a file only when needed. These choices change what evidence and constraints the model can use without changing its trained weights. Long contexts are therefore a resource to manage, rather than a reason to send every available document. For an agent, the process repeats as tool results and intermediate decisions accumulate.

The practitioner specifies a context assembly policy and tests it against realistic tasks. Useful artifacts include a message layout, retrieval rules, a history retention policy, compact state records and a trace showing the material sent on each call. Evaluation should separate missing evidence from evidence the model failed to use. A comparison might keep the model and task constant while changing document selection or summary format. Token cost matters, but preserving an unresolved requirement or a critical exception may justify additional context.

Compaction can discard a constraint, retrieval can select obsolete evidence, and tool output can contain instructions that conflict with the user's request. Context assembly needs explicit provenance and boundaries between instructions and source material. A large advertised context window does not establish reliable use of every token. Good checks include whether the same requirement survives repeated summarization, whether conflicting sources are surfaced, and whether the model can identify the evidence behind a decision.