What Is Context Engineering? Give AI the Right Information, Not More Words

For a couple of years the standard advice was simple: write a better prompt. Then people started using assistants that read files, search the web and run tools across dozens of steps, and a different problem showed up. The model wasn't failing because the instruction was badly worded. It was failing because it was looking at the wrong information, or too much of it. Context engineering is the name that stuck for fixing that. This guide explains what context engineering is, how it differs from prompt engineering, what actually goes into a model's context, why more isn't better, and how to apply it whether you're chatting with ChatGPT or building an agent.

What context engineering actually means

A language model has no memory between requests and can't see your screen, your files or your company. Every time it answers, it works only from the text (and images) it receives in that request: its context window. Context engineering is the practice of deciding what goes into that window — what to include, what to leave out, in what form and in what order — so the model has what it needs for the next step and very little else.

The term took off in June 2025, when Shopify's CEO Tobi Lütke said he preferred it to "prompt engineering" and Andrej Karpathy agreed, describing it as "the delicate art and science of filling the context window with just the right information for the next step". Anthropic's engineering team later defined it as the set of strategies for curating and maintaining the best possible set of tokens while a model is working. Different words, same idea: the prompt you type is only one part of what the model reads, and often the smallest part.

A useful way to picture it: the model is a very capable contractor who arrives every morning with total amnesia. Whatever is on the desk when they sit down is all they know about the job. Context engineering is preparing that desk.

Context engineering vs prompt engineering

They aren't rivals. Prompt engineering is about how you phrase an instruction: the role, the task, the constraints and the format. Our prompt engineering fundamentals cover that craft. Context engineering sits one layer up and deals with everything around the instruction.

• Scope — prompt engineering shapes one message. Context engineering shapes the whole package the model receives: system prompt, conversation history, documents, examples and tool results.
• Timing — a prompt is usually written once. Context is often dynamic: it changes at every turn of a conversation and every step of an agent's run.
• The failure it fixes — prompt engineering fixes "it misunderstood what I asked". Context engineering fixes "it understood, but it didn't have the facts" and "it had so much material that it got distracted".

A beautifully written prompt with the wrong context still produces a confident, wrong answer. A plain prompt with exactly the right context often works first time. That's why the term caught on with people building AI products, but it applies just as much to anyone using a chat assistant for real work.

What goes into a model's context

Whether you're typing into a chat box or building an app, the context is assembled from the same handful of ingredients:

• Instructions — the system prompt or custom instructions that set the role, rules and tone. Our system prompts guide covers how to write them.
• The task — your current request, ideally with the goal and the audience, not just the action.
• Examples — a few samples of good output. Two or three well-chosen examples often beat a page of rules, and few-shot prompting explains why.
• Knowledge — the documents, data or search results the answer should come from, either pasted in by you or fetched automatically (often called RAG, retrieval-augmented generation).
• History and memory — earlier turns of the conversation and anything the tool has saved about you or the project.
• Tools and their results — descriptions of what the model is allowed to do (search, run code, read a file) and the output that comes back each time it does.
• Output format — the structure you expect back, such as a table, JSON or a word limit.

Every one of these takes up room, and they all compete for the model's attention. Most of context engineering is the job of balancing them: enough of each to do the task, and nothing that pulls in a different direction.

Why more context isn't better

Context windows have grown to hundreds of thousands of tokens, and some models accept a million or more. It's tempting to conclude that you can paste everything in and let the model sort it out. In practice that tends to backfire, for four reasons:

• Attention thins out — the well-known "Lost in the Middle" study found that models use information at the start and end of a long input much better than information buried in the middle. Anthropic describes a related effect as context rot: as the context grows, the model gets worse at recalling and using any single piece of it.
• Distraction — irrelevant material isn't neutral. A half-related document is an invitation to pull in a sentence that doesn't belong in the answer.
• Conflict — two versions of a policy, an old instruction and a new one, a note that contradicts the data. The model may follow either, or blend them, and it won't always tell you it had to choose.
• Cost and speed — every token is processed on every call, so bloated context makes apps slower and more expensive to run.

When a capable model gives a bad answer, the cause is usually one of four context problems: something was missing, something was out of date, two things conflicted, or the useful part was buried under noise. It's worth asking which one before you reword the prompt for the fifth time. Missing context is also a major cause of AI hallucinations: when the facts aren't there, the model fills the gap with something that sounds plausible.

Context engineering in everyday chat

You don't need to build anything to benefit. If you use ChatGPT, Claude or Gemini for work, you're already doing context engineering every time you decide what to paste in, whether you do it well or badly. A few habits make a real difference:

• Front-load a brief — before the request, give the background a new colleague would need: who it's for, what's already decided and what good looks like.
• Paste the source, not your summary of it — if the answer has to match a document, include the relevant part of that document.
• Trim before you paste — the three relevant paragraphs of a contract beat the whole 40-page PDF.
• Look after the persistent slots — custom instructions, projects with uploaded files and saved memories are context that loads automatically. Keep them short and current: a stale memory about a job you left last year is still context.
• Start fresh when a thread drifts — a long chat piles up abandoned ideas and corrected mistakes. When answers start mixing in old material, open a new chat with a clean summary.

A reusable brief looks like this:

When the answer has to come from a specific set of documents, a tool built around your own sources does much of this work for you. Our guide on how to use NotebookLM shows how that works in practice.

Context engineering for agents and AI apps

Context engineering matters most when a model works over many steps. An AI agent that searches, reads files and calls tools generates new context with every action. Without management, its window fills up with stale tool output until it loses the thread. The techniques teams use to prevent that are surprisingly down to earth:

• Retrieve just in time — instead of loading every document up front, keep lightweight references (file paths, links, saved queries) and let the agent fetch what it needs at the moment it needs it.
• Compact — when a long session approaches the limit, summarise what matters (decisions, open problems, key facts) and carry on from the summary. Clearing out old tool results is the simplest version.
• Take notes outside the window — have the agent keep a progress file or to-do list it can reread, so important state survives even after the conversation is trimmed.
• Split the work — sub-agents handle a focused task in a clean context and hand back a short summary, so the lead agent isn't carrying every detail of every search.
• Keep tools few and clear — overlapping tools with vague descriptions leave the model guessing which one to use. Every tool description is context too.
• Pitch the system prompt at the right altitude — Anthropic's phrase for the middle ground between brittle if-this-then-that rules and vague encouragement: specific about goals and boundaries, flexible about method.

Compaction is something you can try by hand in any long chat before you move to a new one:

A context checklist you can reuse

Before an important request, or when an assistant keeps getting the same thing wrong, run through this list:

1. Goal — does the context say what the output is for, not just what to do?
2. Sources — is every fact the answer depends on actually in front of the model?
3. Freshness — is anything out of date: an old brief, a superseded version, a memory that no longer applies?
4. Conflicts — do any two pieces disagree? Remove one, or say which one wins.
5. Noise — what could you delete without losing anything the task needs?
6. Labels — are documents and excerpts clearly named and separated, so the model (and you) can tell them apart?
7. Order — is the key instruction at the start or the end, rather than buried in the middle of a long paste?
8. Format — have you shown or described the output you want back?

You can also ask the model to audit its context before it answers anything:

What context engineering can't fix

Context engineering is useful, but it isn't magic, and some of the hype around it promises more than it delivers. Limits worth knowing:

• It can't add ability the model lacks — perfect context won't make a small model reason like a large one, or make any model reliable at a kind of task it handles badly.
• It doesn't guarantee faithfulness — even with the right documents in front of it, a model can misread, overstate or blend sources. Check the claims that matter.
• Your sources set the ceiling — if the documents are wrong, biased or out of date, the answers will be too, delivered with exactly the same confidence.
• Retrieval can fetch the wrong thing — automated search over your documents sometimes returns a near miss, and the model then reasons carefully from the wrong passage.
• Untrusted content is a risk — web pages, emails and files you feed into an AI can contain hidden instructions, known as prompt injection. Treat anything the model reads as data, not commands, and keep a human approving anything irreversible.
• It's ongoing work — context goes stale. Instructions, memories and reference files need maintaining like any other documentation.

The core idea is simple: a model can only work with what it sees, so decide deliberately what that is. Give it the goal, the facts and an example of good output, leave out the clutter and check the result. That habit improves answers more reliably than any clever phrasing.

References

• Anthropic — Effective context engineering for AI agents
• Prompt Engineering Guide (DAIR.AI) — Context Engineering Guide
• Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (arXiv)