Context Engineering: What It Is and 4 Ways It Fails

What Context Engineering Is

Context engineering is the practice of deciding, assembling, and delivering everything an AI model needs to do a task well, before the model runs. It covers the system prompt, the documents you attach, what the model remembers about you, which tools it can call, and what's already in the conversation. Prompt engineering tunes one sentence. Context engineering tunes the whole input stack.

Anthropic's definition is the tightest one in circulation: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference." The guiding principle they give is worth memorizing, because it doubles as the test for whether you're doing it right: find "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome." (Anthropic, 2025)

Think of it like briefing a new consultant. A bad brief is a one-line email. A good brief includes the company background, the relevant history, the files they'll need, who the stakeholders are, what success looks like, and what's out of scope. If you hire a brilliant consultant and give them a bad brief, you get a mediocre deliverable. The same is true of AI.

Notice what's not in the definition: cleverness. There's no magic phrasing, no secret word that gets you a better model. The work is closer to editing than to incantation. You're deciding what belongs in the room before the conversation starts, and just as importantly, what doesn't.

---

The Tweet That Named It

On June 19, 2025, Tobi Lütke, the CEO of Shopify, posted on X that he preferred the term "context engineering" over "prompt engineering." He described it as "the art of providing all the context for the task to be plausibly solvable by the LLM." Six days later, Andrej Karpathy, one of the most respected voices in AI, amplified the term. His definition was sharper: "context engineering is the delicate art and science of filling the context window with just the right information for the next step." (Karpathy, 2025)

The phrase itself wasn't new. Walden Yan at Cognition, the team behind the autonomous coding agent Devin, had published "Don't Build Multi-Agents" a week earlier, on June 12, calling context engineering "effectively the #1 job of engineers building AI agents." But the Lütke and Karpathy posts were when the label went mainstream. The month after, Gartner published a report titled "Lead the Shift to Context Engineering as Prompt Engineering Fades," with the blunt summary line: "Context engineering is in, and prompt engineering is out." Gartner's accompanying forecast: by 2028, context engineering features will be built into 80 percent of the software tools used to build AI applications, improving agentic AI accuracy by at least 30 percent. (Gartner, 2025)

What happened wasn't a rebrand. It was a correction. The AI community quietly admitted that the skill called "prompt engineering" had always been a subset of something bigger, and that the subset was no longer the interesting part. A prompt is one component. Context is the whole room.

This matters because knowledge workers have spent two years learning the wrong thing. They memorized prompt templates. They collected "ultimate prompt" Twitter threads. They treated the prompt like a spell. That effort is not useless, but it is no longer sufficient. The question isn't how you phrase your request. The question is what you put next to your request.

---

Is Prompt Engineering Actually Dead?

Short answer: the job title is dead, the techniques are not.

It's tempting to treat this as a generational shift where everything old is wrong. That's lazy framing. Chain-of-thought, few-shot examples, role assignment, and explicit output formats all still move the needle, and they still show up inside well-engineered contexts.

What changed is the ceiling. In 2023, a well-phrased prompt could double the quality of a response because the underlying models were easily confused by ambiguity. You could turn GPT-3.5 from a bumbling intern into a coherent analyst with the right sentence structure. That gap was real, and prompt engineering exploited it.

Frontier models in 2026 don't need the hand-holding. Claude Opus 5, GPT-5.6, and Gemini 3.1 Pro handle ambiguous requests reasonably well. The marginal return on phrasing has dropped. But the marginal return on supplying relevant source material, scoped memory, and curated examples has gone up sharply. The leverage moved.

Here's the comparison, laid out.

Notice the last row. Prompt engineering didn't die because it was wrong. It died because the bottleneck moved somewhere else.

---

Is Context Engineering Dead Too?

Short answer: the label is fading, the practice isn't.

The backlash is real enough to have its own genre. Joe Reis published "Gartner Declares 2026 The Year of Context™" in March 2026, mocking the Context Engineer as a blend of "data engineer, ontologist, librarian, corporate anthropologist, and therapist" whose actual job is "updating a YAML file." Strip out the jokes and three objections are left standing, and two of them contain something true.

"The models will absorb it." The claim is that agent harnesses now handle compaction, retrieval, and memory automatically, so the human doesn't need to think about context anymore. There's real substance here. Automatic compaction and just-in-time retrieval genuinely removed a category of manual work. But automation moved the work rather than deleting it. Someone still decides what goes in the memory file, which sources the retriever is allowed to touch, and what the agent is told to ignore. The plumbing got automated. The judgment didn't.

"It was always just a buzzword for good input." Partly fair. Curating inputs is not a new idea, and the term did get stretched to cover almost anything by vendors selling context products. But naming a thing changes how seriously people treat it. Nobody audited their AI inputs systematically in 2023. Plenty of teams do now, and they do it because the name gave the practice a shape.

"Context rot means you can't engineer your way out." This one is backwards. The fact that models degrade as input grows is the argument for deliberate context work, not against it. If more context were always better, curation would be pointless and you could dump everything in.

The honest read as of mid-2026: the phrase is past its hype peak, and the standalone "context engineer" title is emergent rather than standard. Adobe posts roles carrying that exact name, but at most companies the work sits inside existing AI, data, or platform engineering jobs. The practice underneath it is more established than ever. Expect the label to fade into the background the way "responsive design" did, absorbed into the default definition of competent work.

---

The Six Layers of Context

To do context engineering deliberately, you have to know what you're engineering. Every modern AI interaction pulls from six layers, whether you think about them or not. The skill is knowing which ones to adjust.

A well-engineered context uses all six deliberately. A poorly engineered context dumps everything into one layer (usually attachments, often the conversation history) and hopes the model sorts it out.

The mistake most knowledge workers make is treating AI as a chat interface when it's actually a context assembler. Almost everything that determines the answer has already happened by the time you start typing.

For a related angle on how personal information architecture shapes AI usefulness, see personal context management.

---

Why Bigger Context Windows Made This Worse, Not Better

In 2023, a 100K-token context window was exotic. By 2026, a million tokens is the ordinary baseline: roughly 1,050,000 for GPT-5.6, 1,048,576 for Gemini 3.6 Flash, and 1,000,000 for Claude Opus 5. Llama 4 Scout advertises 10 million. You can drop the full text of War and Peace into a single prompt several times over. So the natural assumption is that context engineering is getting easier. More room, less triage, right?

Wrong. It got harder.

The foundational paper here is Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts," published in TACL. The researchers tested whether models could find and use specific information depending on where it was placed in a long context. The finding was uncomfortable: performance is U-shaped. Models pay the most attention to information at the very beginning and the very end of the context. Information in the middle gets systematically underweighted, sometimes ignored entirely. (Liu et al., 2024)

Put a critical instruction in the middle of a 50-page document and the model may act as if it never saw it. That's not a bug you can prompt your way out of.

Then, in July 2025, Chroma published "Context Rot: How Increasing Input Tokens Impacts LLM Performance," by Kelly Hong, Anton Troynikov, and Jeff Huber. They tested 18 frontier models, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3. The result was consistent across every model: performance degraded as input grew, well before the context window was anywhere near full. Models do not use their context uniformly. Accuracy slid by tens of percentage points between roughly 10,000 and 100,000 tokens, which on a million-token model is the first tenth of the window.

The crucial detail is that the threshold tracks an absolute token count, not a share of the window. Databricks measured correctness falling off around 32,000 tokens for Llama 3.1 405B, and earlier for smaller models. Buying a bigger window does not move that number. A million-token window does not buy you a million usable tokens, it just buys you more room to make the problem worse. Meta publishes near-perfect needle-in-a-haystack retrieval across Llama 4 Scout's full 10 million tokens, but finding one planted fact is not the same as reasoning over the corpus, and no published benchmark shows reasoning quality holding at that length.

Anthropic frames the underlying cause in a way that makes the fix obvious. Context is "a finite resource with diminishing marginal returns," and models operate on an "attention budget" where "every new token introduced depletes this budget by some amount." The architecture explains why: a transformer has to compute n² pairwise relationships for n tokens, so attention gets thinner as the input grows. (Anthropic, 2025)

This is the hidden cost of the million-token era. The window grew faster than the models' ability to use it, and it turned "what should I leave out?" into the most valuable question in the stack. For the architectural version of this problem, including when to reach for retrieval instead, see Context Rot, RAG, and Long Context.

---

The Four Ways Context Fails

Context pollution is the catch-all term for a context that has been degraded by material which shouldn't be in it. It's a useful phrase and a useless diagnosis, because knowing your context is polluted doesn't tell you what to remove. The most useful breakdown came from Drew Breunig, who published "How Long Contexts Fail" on June 22, 2025. He split context pollution into four distinct failure modes, and the reason the taxonomy stuck is that each one has a different fix.

The examples behind these are concrete. For poisoning, Breunig points to a Gemini 2.5 agent playing Pokémon that hallucinated game states, wrote them into its goals section, and then spent long stretches pursuing objectives that were impossible. For distraction, he cites the same Databricks result that anchors the section above: correctness starts slipping around 32,000 tokens on a model whose window is many times that.

Confusion has the most actionable evidence. On the Berkeley Function-Calling Leaderboard, in Breunig's summary, "every model performs worse when provided with more than one tool," and models occasionally call tools that have nothing to do with the request. In a GeoEngine benchmark test, a quantized Llama 3.1 8B failed the task when given 46 tools and succeeded when given 19. Same model, same task, fewer options.

For clash, Breunig cites Microsoft and Salesforce research on "sharded" prompts, where the same information is spread across several messages instead of delivered at once. Performance dropped an average of 39 percent, and o3 fell from 98.1 to 64.1 on the affected tasks.

Here's the pattern worth internalizing: three of these four get worse when you add context. Only one of them, a genuinely missing fact, gets better. That asymmetry is the whole argument for curation.

---

What the Research Says: The Papers That Matter

Four documents carry most of the weight here, and if you read only these you'll be ahead of nearly everyone arguing about this online. The anchor is "A Survey of Context Engineering for Large Language Models" (arXiv:2507.13334), submitted July 17, 2025. It runs 166 pages and works through 1,411 cited papers, which makes it the closest thing the field has to a map.

The survey's framing is that context engineering "transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs." It splits the field into foundational components (context retrieval and generation, context processing, context management) and then the system implementations built on top of them: RAG, memory systems, tool-integrated reasoning, and multi-agent architectures. If you've ever wondered where RAG sits relative to context engineering, that's the answer: retrieval is one machine inside the larger discipline.

The most interesting finding is a gap the authors flag as "a defining priority for future research." Models augmented with good context engineering "demonstrate remarkable proficiency in understanding complex contexts," but they "exhibit pronounced limitations in generating equally sophisticated, long-form outputs." In plain terms: we've gotten much better at feeding models information than at getting long, high-quality work back out. Anyone who has watched an AI produce a brilliant summary and then a mediocre 3,000-word draft has felt this personally.

The other document worth reading in full is Anthropic's "Effective context engineering for AI agents," published September 29, 2025. It's the one that gave practitioners the working vocabulary most tools now use:

• Just-in-time retrieval: keep lightweight identifiers (file paths, queries, links) in context and load the actual data at runtime, instead of preloading everything.
• Compaction: when a conversation approaches the window limit, summarize it and reinitialize a new window. Anthropic notes the difficulty is entirely in selection, since "overly aggressive compaction" loses subtle context whose importance only shows up later.
• Structured note-taking: have the agent write notes to persistent memory outside the context window, then read them back when needed.
• Sub-agent architectures: give focused tasks to specialized agents with clean context windows, and let a lead agent synthesize the results.

Those four techniques were designed for autonomous agents. All four have a manual equivalent a person can run in a chat window, which is the subject of the next two sections. For how these ideas show up in day-to-day agent tooling, see Skills, Subagents, and Hooks.

---

The Skill Nobody Named: Curation

If context rot is the problem, curation is the solution. And curation happens to be a skill most knowledge workers already practice, without calling it that.

Every time you highlight a passage in an article, you're curating. You're saying: this matters. The rest is background. When you annotate a PDF, bookmark a paper, or save a quote, you're doing the same thing. You're building a signal-to-noise filter over a world full of text.

The problem until recently was that this curation was trapped. Your highlights lived in one app. Your Kindle notes lived in another. Your web research lived in your browser history. When you sat down to brief an AI, you couldn't actually pull any of it into the context window efficiently. You ended up re-reading everything or worse, pasting in raw sources and hoping for the best.

Context engineering as a discipline has a huge gap exactly here. Companies solved it by building internal knowledge bases and RAG pipelines. But individual knowledge workers don't have an engineering team. They have the same problem (too much source material, not enough signal) and none of the infrastructure.

This is why reading tools that capture highlights durably have quietly become AI infrastructure. Glasp's web highlighter exists to solve exactly this: it turns your reading into structured, retrievable context. When you highlight a paragraph in a blog post, that highlight becomes a piece of context you can hand to any AI later, filtered by topic, by source, by date.

The same principle applies to long-form reading. Your Kindle highlights are arguably the highest-quality signal you've ever generated about what matters to you. You paid attention long enough to highlight them. That's a costly filter, and it's wasted if the highlights sit in a closed system.

---

Context Engineering for Individuals (Not Just Engineers)

Most writing on context engineering targets developers. It's about building production AI systems: how to shape a system prompt for a coding agent, how to chunk documents for retrieval, how to wire up tool calls. That's useful if you ship software. It's less useful if you're a consultant, researcher, writer, analyst, or student trying to get better AI output.

But the same discipline applies. You just run it by hand.

You design system prompts, informally. Every custom GPT, every Claude Project, every claude.md-style instruction file you set up is a system prompt. When you write "you are my research assistant, I work on renewable energy policy, prefer skeptical summaries," you're doing system prompt design. Do it deliberately.

You manage memory. ChatGPT's memory feature and Claude's projects both let you pin facts that persist across conversations. Most people either ignore this (and lose continuity) or dump everything into it (and create noise). The right move is to curate memory like you'd curate a resume: only the things you want the model to use every time.

You do retrieval, manually. Pasting the right article into a chat is manual RAG. The question is where "the right article" comes from. If it comes from frantically scrolling your browser history, you have no retrieval system. If it comes from a library of passages you've already flagged as interesting, you have one.

You load attachments intentionally. The temptation is to upload the whole book. The better move is to upload the 40 pages you actually highlighted. You're bypassing context rot by doing the filtering upstream.

Then there are the four agent techniques from Anthropic's playbook, each of which has a manual version:

Compaction is the one most people are missing. Long threads get worse over time because old messages dominate the context unhelpfully, and it's exactly the distraction failure mode from the table above. Starting a fresh thread for a new subtask, with a clean brief, usually beats continuing the mega-thread.

None of this requires engineering skill. It requires the same skill good researchers and good journalists already have: knowing what to include, what to cut, and what to pull from where.

---

Your Highlights Are Your Competitive Context

Here's the part that's underrated.

Most people treat their notes and highlights as memory aids. Things to go back to someday. That framing made sense in 2010, when going back to them was the only way to use them. It's obsolete in 2026.

Your highlights are now a feed that can be handed to AI. Every passage you've flagged, every quote you've saved, every annotation you've made is a piece of context. And because you generated it by paying attention, it's higher-signal than anything scraped at random from the web.

Think about what this means competitively. Two knowledge workers use the same AI model. One has three years of structured reading and highlighting. The other has three years of browser tabs they never revisited. When they ask the AI the same question, the first person can feed it their own curated corpus. The second person is stuck with the model's generic training data and whatever they can remember to paste in. The gap is not a prompting gap. It's a context gap.

This is why Glasp has been shifting in how it positions itself. The original pitch was a social web highlighter: highlight things, see what others highlighted, build a reader identity. All still true. But the deeper value now is that every highlight is a context token waiting to be used. Your reading history compounds into a personal RAG corpus, one paragraph at a time.

When you pair this with Glasp's AI chat, the workflow becomes closer to what engineers build for their companies. You highlight as you read. Later, you ask questions and the AI pulls from what you actually cared about, not from a generic web index. That's context engineering, except the context is your own library.

For more on how this flips the reading-AI relationship, see AI reading assistants.

---

A Simple Framework to Engineer Context for Any AI Task

Enough theory. Here's a concrete workflow you can run the next time you open a chat.

Step 1: Define the job before you type. One sentence. What does done look like? "Draft a 500-word memo summarizing the three main arguments against a four-day workweek, written for a skeptical COO." That's a job. "Help me with this article" is not.

Step 2: Gather your sources, then cut them. Pull the materials that actually bear on the task. If you have highlights on the topic, start there, not with the full articles. If you have memory set up, check whether it already contains useful background. Leave out anything that's only tangentially related. Context rot is real.

Step 3: Set the role and rules. Before the task, tell the model who it is and what rules apply. "You're editing for a skeptical COO. No jargon. No hedging. Numbers before adjectives." This is the system prompt layer. It takes ten seconds and changes the tone of everything that follows.

Step 4: Feed the task plus the bundle, in order. Put the most important context first and the task last. Because of the Lost in the Middle effect, you want the instruction and the sharpest material at the beginning and the end. The middle is a swamp.

Step 5: Diagnose before you iterate. If the output is bad, resist the urge to rewrite your prompt twelve ways. Run the four failure modes as a checklist instead. Is there a wrong fact in there that keeps coming back (poisoning)? Is the thread long and repetitive (distraction)? Did you attach three sources when one was relevant (confusion)? Did you give two instructions that disagree (clash)? Each one has a different fix, and none of them is rephrasing.

Do this a few dozen times and it becomes reflexive. You'll stop asking "how do I prompt this?" and start asking "what does the model need to see before it answers?" That shift is the whole discipline.

---

Frequently Asked Questions

What is context engineering in simple terms?

It's deciding what an AI model sees before it answers. That includes the instructions you give it, the documents you attach, what it remembers about you, the tools it can use, and the conversation so far. Prompt engineering covers only the wording of your request, which is one input among many.

Is prompt engineering actually dead?

The phrase is retiring. The techniques under the phrase still work. Chain-of-thought, few-shot examples, and clear output formats are all still useful. What's dead is the idea that good phrasing alone gets you great output. In 2026, phrasing is a minor lever. Context assembly is the major one. When people say "prompt engineering is dead," this is what they mean.

Is context engineering dead or just a buzzword?

The term is past its hype peak, and the standalone "context engineer" job title is emergent rather than standard: Adobe posts roles under that exact name, but at most companies the work sits inside existing AI, data, or platform engineering jobs. The practice is more established than ever, and it's being absorbed into normal AI work rather than disappearing. Automatic compaction and retrieval in modern agent tools removed some manual steps, but someone still decides what goes into memory and which sources the model is allowed to see. That decision is the job.

What is context pollution?

It's the general term for context that has been degraded by material that shouldn't be there. Drew Breunig's taxonomy splits context pollution into four modes: poisoning (an error enters and gets repeated), distraction (the context gets so long the model over-relies on it), confusion (irrelevant content drags the answer down), and clash (two pieces of context contradict each other). Diagnosing which one you have matters, because the fixes are different.

What are the best papers on context engineering?

Start with "A Survey of Context Engineering for Large Language Models" (arXiv:2507.13334), a 166-page review of 1,411 papers. For the long-context failure evidence, read Liu et al. (2024) "Lost in the Middle" in TACL and Chroma's 2025 "Context Rot" technical report. For applied practice, Anthropic's "Effective context engineering for AI agents" (September 2025) is the most useful non-academic document.

What's the difference between context engineering and RAG?

RAG (retrieval-augmented generation) is one layer of context engineering, specifically the retrieval layer. It's the machinery that pulls relevant chunks from a knowledge base when needed. Context engineering is the broader discipline that includes RAG, plus system prompts, memory, tool use, attachments, and conversation history.

Won't bigger context windows eventually solve this?

They haven't so far, and the evidence suggests they won't. Liu et al. (2024) showed models ignore the middle of long contexts. Chroma's 2025 study showed all 18 frontier models tested degrade well before the window fills. Windows advertised at 10 million tokens have needle-retrieval results but no published benchmark showing reasoning quality holding at that length. The bottleneck isn't window size. It's attention allocation inside the window.

Do I need to be technical to do context engineering?

No. The engineering metaphor throws some people off, but it just means doing the work deliberately instead of by accident. A consultant preparing a brief, a journalist researching a piece, a student organizing source material for an essay, these are all context engineering in disguise. The core skill is curation and judgment.

How does this relate to AI "memory" features?

Memory (like ChatGPT's persistent memory or Claude's projects) is one layer of context. It's what the model knows about you across sessions. Context engineering includes memory but is broader. Memory is the always-on layer. Retrieval, attachments, and system prompts are the per-task layers. A good context engineer uses all of them together.

Isn't this just fancy note-taking?

Partly. The difference is that traditional note-taking is optimized for you rereading your notes. Context engineering is optimized for a model consuming your notes. The format requirements are different (structure, atomicity, retrievability matter more), but the underlying practice of capturing what's worth remembering is the same. Good note-takers have a head start here.

---

Conclusion: The New Literacy

Every era of computing has had a literacy that separated amateurs from serious users. In the 2000s, it was learning to search Google well. In the 2010s, it was learning to structure information in apps like Notion or Airtable. In 2026, it's learning to engineer context for AI.

The people who figure this out will pull far ahead of the people who don't. Not because they have better access to models (everyone has the same models), but because they show up to every task with better material. They know what to feed in. They know what to leave out. They know where their best source on a topic is, because they bothered to capture it months ago.

This is why curation is quietly becoming the most valuable metaskill of the AI era. Every highlight you save, every passage you annotate, every piece of reading you actually process is a deposit into a personal context engine. The future of AI productivity isn't people with secret prompts. It's people with thoughtful libraries.

You already do the reading. You already have opinions about what matters. The only question is whether any of it sticks around long enough to be useful to your future self, and to the AI working alongside you. The tools exist. The habit is the hard part.

Pick something worth reading today. Highlight the parts that matter. That is context engineering. Everything else is technique.