Context Engineering for Agents: The 6 Types of Context
The CPU/RAM mental model for context engineering, the 4 fundamental stages (Write, Read, Compress, Isolate), and the 6 types of context every production agent needs (Instructions, Examples, Knowledge, Memory, Tools, Tool Results).
Semantic paragraph chunking
PDF textbooks are parsed and split into chunks with 100-character overlaps to keep semantic continuity.
▶📚 Prerequisites(1)
🎓 Learning objectives
- •Explain why context engineering has replaced prompt engineering as the core bottleneck skill
- •Apply the 'LLM is a CPU, context window is RAM' mental model to agent design
- •Distinguish the 4 fundamental context-engineering stages: Write, Read, Compress, Isolate
- •Name and describe all 6 types of context a production agent needs
What is it?
Context engineering is the systematic orchestration of everything that goes into an LLM's context window — not just clever prompt wording, but the full architecture of instructions, examples, knowledge, memory, tools, and tool results that determine whether an agent succeeds or fails. Most AI agents fail not because the underlying model is bad, but because they lack the right context to succeed — a RAG workflow, for instance, is typically 80% retrieval and 20% generation, meaning good retrieval can work even with a weak LLM, but bad retrieval can never work even with the best LLM.
Why it exists
Prompt engineering primarily focused on 'magic words' with an expectation of getting a better response through clever phrasing. But as AI applications have grown more complex, complete and structured context matters far more than clever phrasing — LLMs aren't mind readers, they can only work with what you give them. Context engineering exists because, as models get better and more capable, context quality — not model capability — becomes the limiting factor on what an agent can actually do.
Problem it solves
It solves the 'my agent has a great model but still fails' problem, which is almost always actually a context problem in disguise: a coding agent that doesn't know the codebase's conventions, a support agent that doesn't remember a user's previous ticket, a research agent that can't access the specific documents it needs. Context engineering reframes these as solvable, systematic problems (what information flow, what tools, what format) rather than 'the model just isn't smart enough.'
Intuition
If an LLM is the CPU, the context window is its RAM — you're programming the RAM with exactly the right instructions and data for the AI to work with. A brilliant CPU with no useful data loaded into RAM can't do anything useful; a modest CPU with perfectly curated RAM can outperform expectations. This is why context engineering is becoming the core skill: as models (CPUs) keep improving, what increasingly determines output quality is what you load into RAM, not the CPU itself.
Analogy
Think of context engineering like preparing a new employee for their first day versus their hundredth day. On day one, you have to explain everything from scratch (equivalent to a poorly-context-engineered agent re-deriving everything each time). By day one hundred, they have institutional knowledge, know exactly which tools to use, remember past decisions, and only need to be told what's new — that's a well-context-engineered agent: it has the right instructions, examples of good work, domain knowledge, memory of past interactions, the right tools, and the ability to learn from what those tools return.
Technical explanation
Context engineering breaks down into 4 fundamental stages. (1) Writing context means saving information outside the context window to help an agent perform a task later — to long-term memory (persists across sessions), short-term memory (persists within a session), or a state object. (2) Reading context means pulling saved information back into the context window when needed — from a tool, from memory, or from a knowledge base (docs, vector DB). (3) Compressing context means keeping only the tokens actually needed for the task at hand — retrieved context or multi-turn tool-call history often contains duplicate or redundant information that inflates token count and cost, which context summarization addresses. (4) Isolating context means splitting context up so different parts of a task get only the context relevant to them — via multiple agents/sub-agents each with their own scoped context, a sandbox environment for code storage and execution, or a state object.
Building a context engineering workflow means engineering this full pipeline so the LLM sees the right information, in the right format, at the right time — across 6 distinct types of context every production agent needs: (1) Instructions — defines who the agent is (PM, researcher, coding assistant), why it's acting (goal, motivation, outcome), and how it should behave (steps, tone, format, constraints). (2) Examples — shows what good and bad output looks like, via behavioral demos, structured examples, or anti-patterns; models learn patterns far better than plain rules. (3) Knowledge — domain knowledge fed to the agent, from business processes and APIs to data models and workflows, bridging the gap between text prediction and actual decision-making. (4) Memory — gives the agent continuity across sessions: short-term memory (current reasoning steps, chat history) and long-term memory (facts, company knowledge, user preferences). (5) Tools — extends the agent's power beyond language into real-world action; each tool has parameters, inputs, and usage examples, and how well-designed this layer is determines how well the agent uses external APIs. (6) Tool Results — feeds a tool's results back to the model, enabling self-correction, adaptation, and dynamic decision-making based on what actually happened when a tool ran.
Architecture
A context-engineered agent has 4 architectural components mapping to the 4 stages: a Write path (persisting to long-term memory, short-term memory, or state objects), a Read path (retrieving from tools, memory, or a knowledge base into the active context window), a Compression layer (summarizing/deduplicating before context enters the window), and an Isolation mechanism (sub-agents, sandboxes, or state objects that scope context to only what's relevant for a given sub-task). Layered on top of this pipeline are the 6 context types (Instructions, Examples, Knowledge, Memory, Tools, Tool Results), each populated via the Write/Read/Compress/Isolate mechanics above.
Workflow
- For any agent you're building, explicitly inventory which of the 6 context types it currently receives, and which are missing or thin (most under-performing agents are missing Examples or have weak Knowledge context, not a weak model).
- Design your Write path: decide what information from each interaction is worth persisting, and to which store (long-term memory, short-term memory, or a state object).
- Design your Read path: decide, for each new turn/task, what needs to be pulled back into context — from tools, from memory, or from a knowledge base — and avoid pulling in more than is relevant.
- Apply Compression before context enters the window: summarize redundant tool-call history, deduplicate retrieved chunks, and strip anything not actually helping the current response.
- Apply Isolation where a single agent's context would otherwise become overloaded: split into sub-agents each with a narrower context, use a sandbox for code execution context, or use a state object to hold shared state outside any single agent's window.
- Validate by auditing token composition per request — if a request's context is dominated by stale history or irrelevant retrieved chunks rather than the 6 useful context types, that's a concrete signal to revisit the Write/Read/Compress/Isolate pipeline.
Example
Illustrative pipeline wiring the 4 stages around an agent's main loop
def write_context(interaction: dict, memory_store, state: dict): # Stage 1: WRITE — persist what's worth remembering if interaction.get('user_preference'): memory_store.write_long_term(interaction['user_preference']) # Memory state['last_action'] = interaction['action'] # state object
def read_context(query: str, memory_store, knowledge_base, tools: list) -> dict: # Stage 2: READ — pull only what's relevant into the window return { 'instructions': SYSTEM_INSTRUCTIONS, # Instructions 'examples': FEW_SHOT_EXAMPLES, # Examples 'knowledge': knowledge_base.search(query, k=3), # Knowledge 'memory': memory_store.recall(query), # Memory 'tools': [t.schema() for t in tools], # Tools }
def compress_context(ctx: dict, max_tokens: int) -> dict: # Stage 3: COMPRESS — dedupe and summarize before it hits the window ctx['knowledge'] = dedupe_and_summarize(ctx['knowledge'], max_tokens) return ctx
def isolate_via_subagent(subtask: str, scoped_context: dict) -> str: # Stage 4: ISOLATE — a sub-agent gets ONLY the context relevant to its slice return run_subagent(subtask, context=scoped_context)
def run_tool_and_feed_back(tool_call, ctx: dict) -> dict: result = execute_tool(tool_call) ctx['tool_results'] = result # Tool Results — enables self-correction return ctx
Real-world usage
Andrej Karpathy has publicly emphasized context engineering as the emerging core skill for building reliable LLM applications, popularizing the CPU/RAM framing this topic uses. Production coding assistants like Cursor and GitHub Copilot Workspace are essentially context-engineering products first and model-wrapper products second — their competitive advantage comes almost entirely from which files, functions, and prior edits they decide to include in context, not from a proprietary model. Enterprise RAG deployments that 'don't work' are, in the vast majority of cases documented by practitioners, actually context/retrieval problems (wrong chunking, missing metadata, no reranking) rather than generation-model problems — reinforcing the point that bad retrieval can never work even with the best LLM.
Trade-offs
Investing in full context engineering (all 4 stages, all 6 types) is more upfront system-design work than 'just write a good prompt,' but pays off dramatically as agent complexity grows — a simple, single-turn Q&A tool may only need Instructions and Knowledge, while a long-running autonomous agent needs all 6 types and the full Write/Read/Compress/Isolate pipeline to remain reliable and cost-controlled. Over-investing in context engineering for a genuinely simple task (e.g., building elaborate memory infrastructure for a stateless one-shot classifier) adds unnecessary complexity with no payoff.
Visual explanation
A CPU/RAM diagram: [LLM = CPU] ↔ [Context Window = RAM], with 6 labeled inputs flowing into the RAM: Instructions (who/why/how), Examples (good/bad demonstrations), Knowledge (domain facts, APIs, workflows), Memory (short-term reasoning + long-term facts/preferences), Tools (parameters, inputs, usage examples), and Tool Results (fed back in for self-correction).
Below this, a separate 4-stage pipeline diagram: [Write Context] (save outside the window: long-term memory, short-term memory, state object) → [Read Context] (pull into the window: from a tool, memory, or knowledge base) → [Compress Context] (keep only needed tokens, summarize redundant tool-call output) → [Isolate Context] (split via sub-agents, sandboxes, or state objects) — feeding back into a well-curated context window for the LLM.
Advantages
- —
Directly targets the actual bottleneck in most failing LLM applications — context quality, not model capability
- —
The 6-type taxonomy gives a concrete checklist for diagnosing what's missing from an underperforming agent
- —
The 4-stage (Write/Read/Compress/Isolate) framework applies uniformly across very different agent architectures
- —
Investing here pays off increasingly as underlying models improve, since context becomes the binding constraint
Disadvantages
- —
Full context engineering (all 4 stages, all 6 types) is meaningfully more system-design work than simple prompting
- —
Over-applying the full framework to simple, low-complexity tasks adds unnecessary infrastructure
- —
Getting compression and isolation wrong can lose genuinely important context, trading cost savings for quality regressions
- —
Requires ongoing token-composition auditing in production to stay effective, rather than being a one-time design exercise
Common mistakes
- —
Diagnosing agent failures as 'the model isn't good enough' when the real issue is one or more of the 6 context types being missing or thin
- —
Treating context engineering as only about a bigger context window or more retrieved chunks, rather than about the right information in the right format
- —
Skipping the Compress stage and letting redundant tool-call history and duplicate retrieved chunks silently inflate cost and dilute relevance
- —
Never isolating context for genuinely separable sub-tasks, letting a single agent's context window become an overloaded, unfocused dumping ground
- —
Confusing prompt engineering (wording a single prompt well) with context engineering (architecting the full information pipeline) — they solve different problems
📂 Subtopics
Context Type 1-2: Instructions and Examples
The book's CPU/RAM mental model for context engineering, then the first 2 of its 6 context types: Instructions (who/why/how) and Examples (behavioral demonstrations).
~12 min
Context Type 3-4: Knowledge and Memory
The next 2 of the book's 6 context types: Knowledge (domain facts and processes) and Memory (continuity across sessions, split into short-term and long-term).
~12 min
Context Type 5-6: Tools and Tool Results
The final 2 of the book's 6 context types: Tools (what the agent can DO beyond language) and Tool Results (feeding outcomes back in for self-correction and adaptation).
~12 min
Combining the 6 Types: The 4 Stages (Write, Read, Compress, Isolate)
The book's 4 operational stages — Writing, Reading, Compressing, Isolating context — are the mechanism for actually assembling the 6 context types into a working agent pipeline.
~13 min