Context Engineering: The Techniques That Work, and What They Cannot Fix
What context engineering is, how it differs from prompt engineering, the seven techniques that actually reduce context load, and the failure class none of them addresses.
TL;DRContext engineering is the practice of curating what an agent sees at inference time, rather than just what you ask it. Anthropic defines it as strategies for maintaining the optimal set of tokens during LLM inference, and the goal it names is the smallest possible set of high-signal tokens that still gets the outcome you want. There are seven techniques in common use, they are not equally powerful, and six of them manage the context window while only one changes what goes into it. Sentra, the organizational memory layer, is one option in that last category, and this guide covers all seven neutrally before getting there.
What is context engineering?
Context engineering is the discipline of deciding what information occupies an agent's context window on each request, and what does not. Anthropic's engineering guidance describes it as strategies for curating and maintaining the optimal set of tokens during LLM inference, covering everything the model can see: system instructions, tool definitions, retrieved documents, prior turns, and tool results.
The framing worth internalising is that context is finite and rivalrous. Every token you spend on a tool definition, a retrieved chunk, or a stale conversation turn is a token not available to the actual task, and it is a token you pay for on every request. Anthropic's stated objective is to find the smallest possible set of high-signal tokens that maximise the likelihood of the desired outcome, which is a different instinct from the one most teams start with, namely give the model everything and let it sort it out.
Context engineering vs prompt engineering
The two are often used interchangeably and they are not the same scope. Prompt engineering is about the instructions you write. Context engineering is about the entire payload, most of which you never type.
| Prompt engineering | Context engineering | |
|---|---|---|
| What you control | The wording of instructions and examples | Everything in the window: prompts, tools, retrieved data, history, tool results |
| When it applies | Mostly single-turn or per-request | Across long multi-turn and agentic sessions |
| Main failure it prevents | The model misunderstands the ask | The model has the right ask and the wrong or too much material |
| How you measure it | Output quality on a fixed input | Quality, token count and latency together |
| Where it runs out | When the problem is what the model knows, not what you asked | When the material itself is wrong, stale or contradictory |
Why context has a budget
The reason curation beats accumulation is architectural rather than a matter of taste. A transformer's attention mechanism relates every token to every other token, which is n squared pairwise relationships for n tokens, so attention spreads thinner as the sequence grows. Models also have less training exposure to very long sequences than to short ones. The practical result is what the research calls context rot: measurable degradation in accuracy as the window fills, even when the answer is present in the context.
Two 2026 developments make this easier to get wrong. Long context is no longer rationed by price, since Claude 4.6 and later include the full 1M token window at standard rates, so a 900,000 token request is billed at the same per-token rate as a 9,000 token one. And the newer tokenizer in Claude 4.7 and later produces roughly 30 percent more tokens for the same text, so an unchanged prompt occupies more of the budget than it used to. Nothing stops you filling the window. The cost of doing so shows up in accuracy rather than in a rejected request.
The seven techniques, and what each one actually fixes
Ranked by leverage rather than by popularity. The first six manage a context window you keep refilling. The seventh changes what there is to fill it with.
| Technique | What it fixes | What it costs | Where it stops |
|---|---|---|---|
| System prompt hygiene | Dead instructions billed on every single request, forever | An afternoon of deleting things | It is a one-time win, not a lever you can keep pulling |
| Tool budget discipline | Tool definitions silently eating the window | Fewer tools available per call | You still need the tools you removed |
| Just-in-time retrieval | Pre-loading data the task never needed | Extra round trips, so higher latency | Retrieval payloads still grow with corpus size |
| Compaction | Long sessions hitting the window ceiling | Summarisation loses detail, irreversibly | What the summary dropped is gone for good |
| Structured note-taking | State lost across context resets | The agent must maintain the notes | Notes go stale exactly like documentation does |
| Sub-agent architectures | One window carrying several unrelated tasks | Orchestration complexity, and duplicated work between agents | Sub-agents cannot see what siblings learned |
| Write-time resolved facts | Re-deriving the same context on every request | Real infrastructure, and it is not lightweight | Only covers systems that actually feed it |
Tool definitions are larger than most teams assume
This is the cheapest audit available and almost nobody runs it. Tool schemas are billed as input on every request that carries them, and the published overheads are not small: declaring the browser toolset adds roughly 6,600 input tokens per request, the computer-use toolset about 4,500, and the tool-use system prompt itself costs a few hundred more depending on model and tool choice. A fleet making 30,000 requests a month with a browser toolset it rarely calls is paying for roughly 198 million input tokens of pure schema. Count what your agents actually invoke, then remove the rest.
Caching lowers the price, never the volume
Prompt caching belongs in any serious context strategy and it is worth being precise about what it does. A cache read costs 0.1x the base input rate against a write at 1.25x for a five minute window or 2x for an hour, so a stable prefix becomes about 90 percent cheaper to resend. It does not make the context smaller, and it has one property worth stating plainly: caching is indifferent to whether the cached content is true. A policy that changed last month caches exactly as happily as one that changed this morning. It is a price lever, not a correctness lever.
What context engineering cannot fix
Every technique above assumes the material is sound and the problem is volume. Four failure modes survive perfect context engineering, and they are the ones that produce confidently wrong answers rather than slow ones.
- Staleness. Compaction, caching and retrieval all preserve whatever they were given. None of them knows that a commitment made in March was superseded in April, so a well-engineered context can deliver a stale fact with full confidence and low latency.
- Cross-system contradiction. When the CRM says one thing and the contract says another, retrieval faithfully returns both and leaves the agent to guess. Trimming the payload does not decide which is true.
- Facts that were never written down anywhere a tool can reach. A decision reversed in a meeting, an owner change announced verbally, a promise made on a call. No amount of window management retrieves what was never captured.
- Permission scope. An answer can be correct and still wrong to show a particular person. Context budgets measure size, not authorisation.
This is the boundary where context engineering hands off to a memory layer. The distinction is when meaning gets resolved: query-time approaches assemble an answer from artifacts on every request, while write-time approaches resolve the fact once, as work happens, and serve it with a validity window and provenance. The second is the only one of the seven techniques that makes the payload smaller as your corpus grows rather than larger.
On Terminal-Bench 2.1 we measured what that shift is worth: an agent given a task-scoped memory layer reached 88.31 percent mean reward against an 83.37 percent published baseline across 445 trials, with 41.2 percent fewer tokens and 72.6 percent lower model cost. That is our own evaluation, so read the methodology rather than the number, and note the shape of it. Accuracy up and cost down together is what you expect when the mechanism is less but better context, rather than a smarter model.
Is context engineering just a rebrand of prompt engineering?
What is the single highest-leverage context engineering change?
Does a 1M token context window make context engineering unnecessary?
How does context engineering relate to RAG?
Do I need a memory layer if my context engineering is good?
The decision rule
Do the six window-management techniques first, in the order above, because they are cheap and several are one-time. Then check whether your agents are re-deriving the same context on every request. If they are, that is a knowledge-layer problem wearing a context-engineering costume, and no amount of compaction, caching or sub-agent routing will close it.