Context Engineering
The discipline of deliberately curating everything an LLM sees in its context
window at inference time — instructions, retrieved knowledge, tool outputs,
memory, and conversation history — so the model has exactly what it needs to
do the task well, and nothing that pushes it off track.
Prompt engineering optimizes the wording of a single instruction. Context
engineering is the broader discipline: it treats the whole context window as
a budget to be designed, not just filled. The term became common usage
through 2024–2025 as agentic systems moved from single-turn prompts to
multi-turn, tool-using, memory-backed loops where the context is assembled
programmatically rather than typed by hand.
Why it matters more for agents than for chat
A single chat prompt is authored once. An agent’s context is re-assembled
on every step — system instructions, retrieved documents, prior tool
results, running memory, and the user’s goal all compete for the same
limited window. Get the assembly wrong and the model doesn’t fail loudly;
it degrades quietly: it forgets an earlier constraint, over-indexes on the
most recent tool output, or hallucinates a fact that was actually available
but buried too deep in a low-signal block of text.
Core components of an agent’s context
| Component | Purpose | Failure mode when mismanaged |
|---|---|---|
| System / instructions | Durable rules for the whole session | Bloats every turn if not kept tight; conflicting rules confuse the model |
| Retrieved knowledge (RAG) | Task-specific facts pulled on demand | Irrelevant chunks dilute signal; missing chunks cause hallucination |
| Tool outputs | Results of actions the agent took | Raw/verbose outputs crowd out everything else — needs summarization |
| Memory | Facts that persist across sessions | Stale or over-broad memory contradicts current state |
| Conversation history | What’s already been said or decided | Grows unbounded; old turns become noise or must be compacted |
See MCP Resources for the protocol-level mechanism (in the
MCP ecosystem) for exposing retrieval-oriented context to an agent in a
standardized way, and Skills over MCP for progressive
disclosure — loading detailed instructions only when needed, one concrete
technique for keeping the context budget under control.
Core techniques
- Retrieval over inclusion — fetch what’s relevant per-turn instead of
stuffing static reference material into the system prompt. - Compaction / summarization — collapse old conversation turns or verbose
tool output into a shorter running summary once they’re no longer needed
verbatim. - Progressive disclosure — expose a short pointer/description up front
(a tool list, a skill catalog) and load the full detail only when the
agent actually selects that item. - Structured over prose — tables, schemas, and delimited sections are
easier for a model to parse reliably than long unstructured paragraphs,
especially for information it needs to reference precisely later. - Context isolation — give sub-tasks their own scoped context (e.g. a
subagent) rather than growing one shared context indefinitely; this vault’s
ownAgenttool subagents are an example of the pattern. - Ordering and recency bias — models weight information near the end of
the context more heavily; put the actual task/question last, and don’t
bury it under a long preamble.
Relationship to prompt engineering
Prompt engineering is a subset of context engineering: it’s the technique
for wording the instruction block well. Context engineering additionally
covers what else is in the window and how it got there — retrieval
strategy, memory design, tool-output shaping, and the ordering/pruning of
all of it. As agentic systems (loops with tools, memory, and multi-step
plans) have become the norm, context engineering has become the larger and
more consequential problem: a perfectly worded instruction still fails if
the context around it is bloated, stale, or contradictory.