What Is Context Engineering? Prompting's Bigger Sibling

Context engineering is the discipline of deciding everything that goes into an AI model's context window before it generates a response. That includes the system instructions, the documents you retrieve, the results tool calls return, the history of the conversation so far, and any examples you show the model.

It sits one level above prompt engineering, which is narrower and more literal. Prompt engineering is about how you phrase the one instruction you're sending right now: the exact words, structure, and framing of a single message. Context engineering is about everything surrounding that message, the whole information environment the model has to work with when it answers.

The two disciplines share a goal: getting a language model to produce the output you want. But they work at different scopes. Prompt engineering optimizes a single turn. Context engineering optimizes an entire session, one that might involve dozens of turns, several tool calls, and multiple retrieved documents. Get the wording right and the context wrong, and the model still fails. Get the context right, and even an average prompt usually still works.

Why Context Engineering Became Its Own Discipline

A couple of years ago, most people interacting with a language model wrote one prompt and read one answer. The context was whatever fit in that single message, plus maybe a short system instruction sitting above it. There wasn't much to engineer beyond the wording itself.

Agents changed that. An agent might search the web, read the results, call a second tool, recall a decision made three turns earlier, and reference a document a user uploaded at the start of the session. Every one of those steps adds material to what the model sees before it responds. A prompt template alone can't manage that much moving material. Someone has to decide what gets pulled in, what gets summarized, what gets dropped, and in what order it gets presented to the model. Doing that deliberately, instead of letting it happen by accident, is context engineering.

The constraint that makes this necessary is the context window, the fixed amount of text a model can consider at once. Everything competes for space inside it: instructions, history, retrieved facts, tool output. Context engineering is largely the practice of managing that scarce space well instead of filling it indiscriminately.

What Actually Counts as Context

Context isn't one thing. It's usually some combination of the following, assembled fresh for every request an agent handles:

• The system prompt, which sets the model's role, tone, and boundaries before any user input arrives. Getting this piece right is its own skill; see how to write a system prompt for a custom AI assistant.

• Retrieved knowledge: documents, database records, or search results pulled in because they're relevant to the current question.

• Tool and function outputs: results returned when the model calls an external system, the kind of structured data that standards like the Model Context Protocol are designed to hand off cleanly.

• Memory of prior turns: a summary or raw transcript of what has already happened in the conversation.

• Few-shot examples: sample input-output pairs shown to steer the model's format or reasoning style.

Each of these is a lever. Change what you retrieve and you change what the model can know. Change what you summarize versus keep verbatim and you change how accurately it recalls earlier turns.

The Core Failure Modes

Context engineering fails in three predictable ways.

Too much irrelevant context. Stuffing everything you have into the context window doesn't make the model smarter, it makes it worse at finding the signal. Models weight recent and prominent text more heavily than buried text, so an important instruction sitting under ten pages of loosely related material often gets ignored.

Too little context, which shows up as hallucination. If a model doesn't have the specific fact it needs, it usually doesn't say "I don't know." It fills the gap with something plausible sounding instead. A large share of hallucination in production systems isn't a model flaw, it's a context gap.

Stale or contradictory context. Long-running agents accumulate history, and if a fact changes mid-session, a price update, a corrected decision, a new instruction, without removing the old version, the model has to guess which one to trust. Contradictions inside the same context window are worse than a missing fact, because the model has no reliable way to resolve them on its own.

A Practical Checklist for Builders

If you're building an agent, or any AI feature that goes beyond a single prompt-and-response, a few habits keep context under control:

• Audit what's actually sitting in the context window at request time, not what you assume is there.

• Trim conversation history instead of appending it forever. Summarize old turns rather than keeping the full transcript.

• Retrieve narrowly. Pull the three most relevant documents, not the twenty that might be relevant.

• Timestamp or version anything that can go stale, so old and new facts never sit side by side unmarked.

• Keep the system prompt stable, and put volatile information, user data, live results, in the parts of context that change per request.

• Be deliberate when feeding a model information about your business rather than pasting in everything you have. A curated summary beats a full document dump.

None of this requires new tooling. It requires treating the context window as a budget instead of a bottomless bag.

Good context engineering is about curating what a model sees, and that curation cuts both ways. See how to prompt AI without leaking sensitive data for the discipline of keeping that curation safe.

FAQ

Is context engineering just a new name for prompt engineering?

No. Prompt engineering is about phrasing a single instruction well. Context engineering is about deciding everything else the model sees alongside that instruction: retrieved data, conversation history, tool results, and examples. Prompt engineering is one input into context engineering, not a replacement for it.

Do I need to think about context engineering if I'm just using a chatbot?

For a single question and answer, not really. It starts to matter once you're building something with memory, retrieval, or tool use: an agent, a support bot backed by a knowledge base, anything where the model's input is more than what a user just typed.

What's the difference between context engineering and RAG?

Retrieval-augmented generation is one technique for supplying context, specifically pulling relevant documents from a knowledge base at query time and inserting them into the prompt. Context engineering is the broader discipline that includes RAG along with system prompts, tool outputs, memory, and examples.

How does context engineering relate to tool standards like MCP?

Standards for connecting models to external tools and data sources solve the plumbing problem: getting outputs from a tool into the model's context reliably and in a predictable format. Context engineering is the higher-level judgment call that comes after that, deciding what to include, how much of it, and how to arrange it once it arrives.

What's the single biggest context engineering mistake?

Treating the context window as infinite. Builders dump every document, every past message, and every tool result into context just in case, then wonder why the model gets confused or slow. Curating context down to what's actually relevant to the current step almost always beats adding more of it.