Context Engineering — the successor to prompt engineering

Prompt engineering is about the message you write. Context engineering is about everything the model sees when it answers — the files, the history, the tool outputs, the rules, the retrieved docs. In 2026 this is the defining skill of a strong AI engineer, because with agents the model's output is only as good as the context you assembled for it.

📥 Prompt engineering: "What do I say?"
📚 Context engineering: "What should be in the model's window — and what should be kept out?"

The context window is a scarce budget

Every model has a finite context window, and it behaves like a budget you spend:

• Everything you include costs tokens (money + latency).
• More importantly, signal competes with noise. Bury the one relevant file among twenty irrelevant ones and the model's attention thins out.
• Models exhibit context rot: as the window fills with marginal or stale content, answer quality degrades — the model latches onto the wrong thing, forgets earlier instructions, or contradicts itself.

So the goal is not "give the AI everything." It's "give the AI exactly what it needs — no more."

What to include / what to exclude

🎯 Curate, don't dump. A tight, relevant context beats a giant one almost every time.

"Context explosion" on large repos

On a big codebase you cannot fit everything, and trying causes context explosion — you blow the budget and dilute signal. This is why you need strategies for pulling in only the relevant slice. Three complementary approaches:

1. Native long context — modern models accept very large windows. Useful, but "it fits" ≠ "it helps": long context still suffers rot, so relevance still matters.
2. Retrieval / RAG — fetch just the relevant chunks (by embedding search or an index) and inject those. The agent pulls what it needs on demand.
3. Packing — bundle a whole codebase (or subset) into one AI-readable file for tools that lack native repo access — see Repomix.
4. MCP servers — let the model fetch external context/tools on demand instead of pre-loading it — see MCP.

These aren't competitors; they're a toolkit. A good agent workflow often uses several: AGENTS.md for standing rules, retrieval for the relevant files, an MCP docs server for current API references.

Persistent memory vs. per-turn context

Two layers, and it helps to keep them straight:

• 🗂️ Persistent / standing context — lives across sessions: your committed AGENTS.md, project docs, saved memories. Set it once, benefit every time.
• 🔄 Per-turn / working context — assembled fresh each request: the files in scope, recent tool output, the conversation so far. This is what you actively manage during an agent loop.

Good context engineering is knowing what belongs in each — durable conventions go in standing memory; the specific task's files go in working context.

Practical habits

• ✂️ Start fresh when a thread goes stale. A long, meandering conversation accumulates context rot — a new session with a crisp restatement often outperforms it.
• 🎯 Scope the agent. Point it at the right directory/files rather than "the whole project."
• 📝 Externalize durable facts into AGENTS.md so they're not retyped and don't clog each prompt.
• 🔍 Watch for drift. If answers get worse mid-session, your context is probably polluted — reset or prune.
• 🧪 Evaluate. Keep a few real tasks (your own eval set — see Choosing Models & Tools) and check whether a context change actually improves outputs, rather than guessing.

Bottom line: as work shifts from single prompts to agent loops, your leverage moves from wording to context curation. The engineer who manages the window well gets dramatically better results from the same model.

Next: now let's look at the interaction patterns agents actually run in → Interaction Patterns.