Context engineering is the practice of deciding exactly what information an AI agent has in front of it at each step — which instructions, which past messages, which tool results, and which facts get included or left out. Where prompt engineering was about wording a single instruction well, context engineering is about managing an entire, changing window of information across a multi-step task.
The shift matters because agents don't run on one prompt. They run on a loop, and at every turn of that loop, something has to decide what stays in the model's context and what gets dropped. Get that wrong, and even a brilliantly worded prompt won't save you — the model simply won't have the information it needs, or it will be buried under noise it doesn't.
By 2026, most practitioners building real agents spend far more time on this than on wordsmithing prompts.
What context engineering actually means
Every large language model call happens inside a context window — a fixed budget of tokens that includes the system instructions, the conversation so far, any retrieved documents, and any tool outputs. Context engineering is the discipline of managing what fills that budget.
For a single chatbot reply, this is fairly simple: the context is mostly just the conversation history. For an agent running many steps — searching, calling tools, reading results, calling more tools — the context has to be actively curated at every turn, or it fills up with stale information, irrelevant tool output, and repeated instructions that crowd out what actually matters right now.
Context engineering covers decisions like:
- What goes in the system prompt versus what gets injected dynamically per step.
- Which past tool results are still relevant, and which can be summarized or dropped.
- How much of the conversation history to keep verbatim versus compress.
- What external information — documents, database rows, API responses — to retrieve and include.
- How to format all of this so the model can actually use it, not just receive it.
Why prompt engineering wasn't enough
Prompt engineering treats the interaction as one well-crafted instruction: get the wording, examples, and constraints right, and the model produces a good answer. That approach works reasonably well for single-turn tasks like "summarize this document" or "write a product description."
It breaks down once an agent has to act across many steps, because the prompt is no longer the only thing the model sees. A perfectly worded system prompt is useless if, five tool calls later, the model's context is dominated by an enormous raw API response that pushed the original instructions out of effective attention, or if critical information from step two never made it into the context by step nine.
The failure mode isn't "the wording was wrong." It's "the model literally didn't have the right information available when it needed it." That's a context problem, not a prompt problem, and no amount of rephrasing the original instruction fixes it.
Prompt engineering vs context engineering
| Prompt engineering | Context engineering | |
|---|---|---|
| Scope | A single instruction or message | The full information state across a multi-step task |
| Main lever | Wording, examples, format instructions | What information is included, excluded, or compressed |
| Applies best to | One-shot tasks, single model calls | Agents, multi-step workflows, long-running tasks |
| Common failure | Ambiguous or poorly specified instructions | Context window overflow, stale or missing information |
| Skill involved | Writing clearly | Filtering, summarizing, retrieving, sequencing information |
Prompt engineering didn't disappear — it became one input into the larger practice. A well-written system prompt is still valuable. It's just no longer sufficient on its own once an agent is running a loop instead of answering one question.
Core techniques in context engineering
Retrieval instead of stuffing
Rather than pasting an entire knowledge base into the context, a well-engineered agent retrieves only the passages relevant to the current step — the core idea behind RAG. This keeps the context focused and leaves room for everything else the model needs to see.
Summarization and compression
Long conversations and large tool outputs get summarized before they're carried forward, rather than kept verbatim. An agent that just read a 10,000-word webpage doesn't need all 10,000 words in context for the next five steps — it needs the two or three facts it extracted.
Structured memory
Instead of relying purely on scrollback, agents increasingly separate context into layers: a small set of durable facts that persist across the whole task, a working set of recent steps, and a discardable pool of raw tool output that gets pruned aggressively. This is closely related to how agent memory is designed — short-term working context versus longer-term storage that gets pulled back in only when relevant.
Just-in-time tool results
Rather than fetching every possibly-relevant piece of data upfront, well-engineered agents fetch information right before it's needed and drop it once it's been used, keeping the context lean at any given step.
Explicit formatting
How information is arranged in the context matters almost as much as what's included. Clear labeling of "this is a tool result," "this is a user instruction," and "this is a prior decision" helps the model weigh sources correctly instead of treating everything as equally important.
Common context engineering failures
Most agent bugs that look like "the model is being dumb" are actually context problems in disguise:
- Context overflow: so much accumulated history and tool output gets crammed in that the model loses track of the original goal.
- Stale context: information that was true three steps ago is still present and contradicts what the agent just learned, and the model doesn't reconcile them.
- Missing context: a fact the agent established earlier never got carried forward, so it re-derives it incorrectly or asks again.
- Buried instructions: the system prompt's constraints get pushed so far back by accumulated content that the model effectively stops following them.
- Irrelevant noise: raw, unfiltered tool output (a full API response, a full file) drowns out the two lines that actually mattered.
Each of these produces the same symptom — a wrong or confused answer — but the fix is different in each case: trimming, summarizing, re-injecting, restructuring, or filtering.
How context engineering connects to agent architecture
Context engineering isn't a separate add-on to agent design — it's baked into most of the architectural decisions agent builders make. How you choose between plan-and-execute and reactive agents shapes how much context accumulates before a decision point. How you design tool calling shapes how much raw data floods into context on every call. And guardrails often work by constraining what enters context in the first place, not just what the model is allowed to output.
This is also why context engineering has become central to how agent frameworks are evaluated: a framework that makes it easy to control what's visible to the model at each step is doing more real work than one that just makes prompts easier to write.
Getting started with context engineering
If you're building your first agent, a few habits go a long way:
- 1.Log the full context sent to the model at each step, at least while developing. You can't fix what you can't see.
- 2.Summarize tool output before adding it to context, rather than passing it through raw.
- 3.Separate durable facts (the goal, key constraints, decisions already made) from disposable working data (the last tool call's raw output).
- 4.Periodically ask: "if I only kept this much context, would the model still have what it needs?" Trim toward that answer.
- 5.Test with longer tasks, not just short ones — context problems mostly show up after several steps, not the first one.
FAQ
Is context engineering just a rebrand of prompt engineering?
Not quite. Prompt engineering focuses on wording a single instruction well; context engineering manages the full, changing set of information an agent sees across many steps — including what to retrieve, summarize, or drop. Prompt writing is still part of the job, but it's now one piece of a larger discipline.
Why does context engineering matter more for agents than for chatbots?
A chatbot typically responds to one message at a time, so its context is mostly just the conversation history. An agent runs a loop across many steps, accumulating tool results, decisions, and retrieved data — someone has to actively manage what stays in context at each step, or the window fills with stale or irrelevant information.
What's the relationship between context engineering and RAG?
Retrieval-augmented generation is one specific context engineering technique: instead of stuffing an entire knowledge base into the prompt, you retrieve only the most relevant passages for the current step. Context engineering is the broader discipline that RAG, summarization, and memory management all fall under.
Do I need special tools to do context engineering well?
Not necessarily — the core skill is a way of thinking about what information the model needs at each step, which you can practice with basic logging and manual review. That said, agent frameworks increasingly provide built-in support for context management, like automatic summarization or structured memory, which makes the practice easier to apply consistently.