Context engineering is the practice of deciding exactly what information, instructions, tools, retrieved documents, conversation history, an AI agent sees in its context window at each step, and it's rapidly replacing prompt engineering as the core skill for anyone building agents that need to work reliably across long, multi-step tasks.

Prompt engineering answers one question: what's the best way to phrase this instruction? Context engineering answers a harder, ongoing one: out of everything the agent could see right now, what should it actually see, and what should it not see, so it can make the next decision well? That distinction stopped being academic once AI agents moved from answering single questions to running multi-hour, multi-tool tasks, where the wrong information sitting in context for too long degrades performance even when every individual instruction was written perfectly.

What Context Engineering Actually Means

In its own engineering guide, Anthropic defines context engineering as curating and managing "the optimal set of tokens" available to a model during inference, not just the prompt, but the system instructions, the tools it can call, the external data it retrieves, and the history of everything that happened so far in the task. Prompt engineering is a single, discrete task: write good instructions once. Context engineering is continuous: it's a set of decisions an agent, or its designer, makes at every turn about what to keep, what to drop, and what to fetch only when it's actually needed.

Why Prompt Engineering Wasn't Built for This

A good prompt assumes the model sees everything relevant in one shot and nothing else. That assumption holds for a single-turn chatbot answer. It breaks down for an agent that reads files, calls APIs, and accumulates tool outputs over dozens or hundreds of steps, because eventually the context window fills with information that was useful three steps ago and is now just noise crowding out what matters right now.

The Context Budget: Why More Isn't Better

Anthropic's engineering team describes this with the idea of an "attention budget": transformer architectures create pairwise relationships between every pair of tokens in context, so as a conversation grows, models experience what researchers call "context rot," measurably worse recall and reasoning as the token count climbs, even though the context window technically has room left. Treating a bigger context window as a free upgrade misses the point. The goal isn't fitting in more, it's finding, as Anthropic puts it, "the smallest set of high-signal tokens that maximize the likelihood of your desired outcome."

The Four Moves: Write, Select, Compress, Isolate

LangChain's engineering team, building on a framing popularized by former Tesla AI director Andrej Karpathy, breaks context engineering into four repeatable strategies:

• Write: save information outside the context window for later, a scratchpad during a task, or a memory that persists across sessions, so nothing important is lost when older context eventually gets dropped.

• Select: pull only the relevant information back in when it's needed, using retrieval-augmented generation, semantic search over a tool library, or a saved memory, instead of loading everything upfront.

• Compress: summarize or trim what's accumulated so far. Claude Code's "auto-compact" feature does this automatically as a session approaches its context limit.

• Isolate: split work across multiple agents, each with its own clean context window for one focused task, then return a short summary instead of the full trace to the main agent.

Retrieval is where this connects directly to infrastructure most data and AI teams already run. Our explainer on what retrieval-augmented generation is and how it works in modern AI agents covers the "select" half of context engineering in more depth, it's the mechanism that lets an agent fetch just-in-time instead of front-loading everything it might need.

What This Looks Like in Practice

Anthropic's own examples are concrete rather than theoretical. Claude Code keeps a lightweight file like CLAUDE.md loaded upfront but navigates the rest of a codebase just-in-time with tools like grep and glob, rather than pre-indexing everything, which avoids the problem of a stale index going out of sync with the actual files. In an internal experiment where Claude played Pokémon over thousands of game steps, the agent maintained a running, structured log of progress instead of keeping the entire game history in context, letting it track something like "for the last 1,234 steps I've been training my Pokémon in Route 1" without that history crowding out its ability to decide what to do next.

Recommended Coderhouse Courses

To build agents that put these ideas into practice, the AI Engineering Course covers agent design, RAG, and evaluation for production systems, module by module. If you specifically want to go deep on building and orchestrating autonomous agents, the AI Agents Course is the more focused, hands-on option.

Frequently Asked Questions

Is context engineering just a rebrand of prompt engineering?

No. Prompt engineering optimizes the wording of a single instruction. Context engineering manages the entire set of information available to a model across an ongoing task, including tools, retrieved data, and history, and it's a continuous process rather than a one-time write.

What is "context rot"?

It's the term researchers use for the measurable decline in a model's recall and reasoning accuracy as more tokens accumulate in its context window, even when the window technically has capacity left. It's the main reason bigger context windows don't automatically mean better performance.

Do I need a multi-agent system to do context engineering well?

No. Isolating context across sub-agents is one of four strategies, useful for long or parallel tasks, but the other three, writing memory, selecting context just-in-time, and compressing history, apply to single-agent systems too.

How does context engineering relate to RAG?

RAG is one of the main tools used for the "select" strategy in context engineering: instead of loading all potentially relevant documents into context upfront, the agent retrieves only what's relevant to the current step.

Why does this matter more for agents than for simple chatbots?

A single-turn chatbot answer only has to get one prompt right. An agent accumulates tool outputs, retrieved documents, and decisions over many steps, so managing what stays in context and what gets dropped or compressed directly determines whether it stays accurate over a long task.