The context became a system, not a prompt
The phrase gained currency as LLM applications moved beyond one prompt and one response. Once an application retrieves documents, records tool observations, carries state across turns, and applies permission rules, prompt wording is only one input among several.
Context engineering names the work of assembling that complete input environment.
The problem is selection, not merely capacity. A larger context window can hold more tokens, but irrelevant history, conflicting instructions, stale state, and badly ordered evidence can still make the model less reliable.
Prompt engineering controls instructions; context engineering controls evidence
Prompt engineering focuses on how a task is expressed. Retrieval-augmented generation selects outside documents, while memory decides what persists across interactions.
Context engineering coordinates those pieces and determines what the model sees for this specific step.
The context windows versus memory guide explains why capacity and persistence are separate concerns. The contextual retrieval analysis shows one index-time technique for giving retrieved chunks enough surrounding meaning.
Assembly needs provenance and a deletion rule
Each context item should have a source, a reason for inclusion, and a condition that makes it stale. Tool results may last for one step, account preferences may persist across sessions, and system constraints may apply to every turn.
When inputs conflict, the application should not rely on the model to infer which one is authoritative. It should resolve version and permission conflicts before assembly, then preserve source labels so the answer can be checked.
A support answer fails when two true facts collide
Suppose a customer asks how to cancel a subscription. Retrieval returns the current cancellation policy and an older enterprise contract with different terms.
Good context assembly filters by account plan and effective date, labels the source, and places the applicable policy next to the task.
Context engineering applies when the answer depends on choosing and combining inputs. It does not apply to every formatting preference, and its common misuse is filling the window because space is available.
More context is useful only when each added item has a reason to influence the answer.
Graph-derived context helps when the answer depends on relationships
Microsoft Research developed GraphRAG for questions that require a view across a corpus rather than one locally similar passage. The pipeline extracts entities and relationships, groups parts of the graph, and uses those structures during retrieval and answer construction.
Suppose incident reports name a service, its owning team, a dependency, and a sequence of failures across separate documents. Passage retrieval can return the reports, while a graph-derived context layer can make the cross-document path explicit.
That graph is an input to context assembly, not an independent source of truth. Entity resolution can merge different products, relationship extraction can reverse an edge, and a community summary can hide which document supported a claim.
Graph-derived retrieval belongs here only when the question depends on connections or corpus-wide themes. Direct passage retrieval is simpler for local factual questions, and every extracted node, edge, and summary still needs provenance back to source text.
Continue with these glossary entries: