Context Engineering: Pin, Summarize, Prune, and Compact

June 23, 2026 · updated June 25, 2026 · How Claude Actually Works (part 22)

▶ Watch on YouTube & subscribe to The Stack Underflow

Prompt engineering is one message. Context engineering is the whole conversation — and it is the skill that separates a reliable production agent from a demo that drifts after ten turns.

Long agentic sessions have a predictable failure mode: the things the model needs most — the customer ID, the active incident ticket, the environment flag — gradually drift into the middle of the context window. Modern Claude models (claude-sonnet-4-6 and claude-opus-4-6, both with 200k-token standard windows, with 1M-token windows GA on the API as of 2026) can technically hold everything. But “technically holds it” and “reliably uses it” are different claims. A fact buried in the middle of a 150k-token conversation is weak signal. The model reads it; it just weighs it less. The result is a model that has the information and still fumbles it. Four deliberate moves fix this simultaneously — and they cut your token bill at the same time.

The one-sentence version: Actively shape your context window — keep stable facts pinned at the top, collapse resolved turns into summaries, strip bloated tool output before it enters the window, and compact the middle only when the window is genuinely full — and you get better answers at lower cost simultaneously.

Why the middle of the window is dangerous

Transformer attention is not uniformly strong from position 0 to position N. Empirically, models exhibit a U-shaped attention curve: tokens near the beginning of the context and tokens near the end receive disproportionately strong attention. Tokens in the middle receive measurably less. This is the “lost in the middle” effect, documented in peer-reviewed research (Liu et al., 2023; replicated and extended by Du et al., 2025 showing context length alone degrades performance independent of retrieval quality).

In a live session, that weak middle zone fills up fast:

Session turn count   →   Where facts live
───────────────────────────────────────────────────
Turn 1-5             :   Setup / system prompt      [STRONG — top of window]
Turn 6-30            :   Intermediate reasoning,
                         resolved sub-problems,
                         8KB tool outputs you used
                         once and never referenced  [WEAK — middle drift]
Turn 31+             :   Active thread              [STRONG — bottom of window]

Key fact you need    :   Turn 7 — now buried in the sag

The longer the session, the more the genuinely important facts drift from the edges into the sag. The four techniques below are a direct engineering response to this architecture property.

Move 1 — Pin: lock stable facts at the top

Anything that does not change during a session belongs at the very top of the context — above whatever the user and model are actively working through. Call this the pin zone: the region where the model always has strong primacy-effect attention.

What belongs pinned:

In an agentic loop, the pin block should be re-injected at the top of every turn rather than left to drift. This is not redundant — it is insurance against positional decay.

[PINNED CONTEXT — do not summarize or prune]
Customer: Acme Corp (ID: 8821)
Product: Billing API v3
Environment: production
Active incident: INV-4492 — duplicate charge on 2026-06-20
Constraint: never modify the `payments` table directly

A secondary benefit: pinned context is perfectly suited for prompt caching. Because the pin block is stable across turns, you can mark it with cache_control and the API serves it back at roughly 10% of normal input-token cost on subsequent calls (docs.anthropic.com, 2025). Pinning buys coherence; caching buys cost savings — from the same block of text. See Prompt Caching: Cut Your AI Bill for the mechanics.

Move 2 — Summarize: collapse resolved turns

Every resolved sub-problem is a candidate for compression. Eight back-and-forth messages about a refund policy question, once settled, do not need to sit verbatim in the window. Those eight turns collapse to one line:

Before (8 turns, ~1,200 tokens):
  User: "What's the refund policy for plan downgrades?"
  Assistant: "Let me check... policy 4.2 covers this..."
  User: "What if they downgraded mid-cycle?"
  ... [6 more turns of exploration] ...

After (1 line, ~20 tokens):
  ✓ Resolved: Refund #23 approved per policy 4.2 — mid-cycle proration applies.

The rule is simple: keep verbatim only the active issue. Anything resolved becomes a one-liner summary and the original turns are dropped from the window.

This discipline requires you to know what “active” means. A useful heuristic: if you would not need to re-read those turns to continue the current task, they are resolved. If there is any chance you need the reasoning trace, write a one-liner before dropping the turns — not after.

Move 3 — Prune: strip bloated tool output

Tools lie about how much of their output you actually need. A database query returns 8 KB of JSON. You consumed three fields. The remaining 7.9 KB sits in your context, spending tokens, and potentially confusing the model with irrelevant data that looks relevant because it is adjacent to data that is.

Prune aggressively — before the output ever enters the window:

Research on coding agents (SWE-Pruner, 2025) found that agents using structured pruning reduced average token consumption by 23% while completing the same tasks. The signal-to-noise improvement was the more important effect: less irrelevant context meant the model spent its attention budget on what mattered.

The pruning step belongs in your agent loop — between the tool call returning and the result being appended to the conversation. It is not a post-processing step; it is a gating step.

Tool returns raw output
        ↓
  [prune / extract step]   ← runs in your agent loop, not in Claude
        ↓
  Only the needed fields enter the context window
        ↓
  Token cost drops; signal-to-noise ratio rises

Move 4 — Compact: restructure under pressure

Compaction is what you reach for when the window is genuinely full and you need to keep going. The middle of the conversation — already summarized and pruned — collapses into a structured summary card while the pinned facts at the top remain verbatim and the active thread at the bottom stays live.

[COMPACTED SESSION SUMMARY — turns 1-34]
─────────────────────────────────────────
Goal        : debug duplicate charge for Acme Corp (INV-4492)
Confirmed   : charge fired at 14:02 and 14:03 UTC on 2026-06-20
Root cause  : race condition hypothesis in webhook handler
Ruled out   : network retry, idempotency key mismatch
Next step   : inspect handler lock logic in payments/webhook.ts

[PINNED CONTEXT — verbatim, unchanged]
Customer: Acme Corp (ID: 8821)  ...

[ACTIVE THREAD — turns 35+]
...

After compaction you have the same session in three zones: the summary card, the immutable pin block, and the live active thread. The model can continue as if it has full history — because the summary card preserves every material conclusion — but window usage resets to something sustainable.

Note: Claude Code’s auto-compact feature does something structurally similar — it triggers at approximately 95% context usage and produces a trajectory summary before the window is exhausted (platform.claude.com, 2026). If you are building your own agent loop, you are implementing the same pattern manually, with more control over what the summary preserves.

Compaction is a fallback, not a strategy. Reaching for compact before you have done pin, summarize, and prune is using a sledgehammer where a scalpel would work. If you find yourself compacting every five or six turns, you have not done the upstream work.

The two metrics that move together

Here is the satisfying property of this whole framework: pin, summarize, prune, and compact are not trade-offs. They move two metrics in your favor simultaneously.

Most optimisation decisions force a trade-off between quality and cost. This one does not. The techniques that make the model smarter on the task are the same techniques that reduce your bill.

How to apply this in practice

Concretely, here is what this looks like in a production agentic loop:

1. Build a pin block at session start. Extract any facts that will not change — account, environment, constraints, active goal — and place them at position 0. Mark the block with cache_control: {"type": "ephemeral"} so subsequent turns hit the cache.

2. Prune every tool result before appending. Write a lightweight extraction function for each tool your agent uses. For a database tool, extract the three to five fields your downstream prompt actually references. For a log reader, extract only lines matching your error patterns. This runs in your code, not in Claude.

3. Track resolved sub-issues. When a sub-thread reaches a conclusion, write a one-liner summary and pop the original turns from the message array before the next API call. Do not wait until the window fills.

4. Set a compact threshold. A practical signal: when context usage exceeds 60-70% of the window limit after pin, summarize, and prune, trigger compaction. Waiting for 95% (the auto-compact threshold) means you are already under pressure.

5. Treat the pin block as immutable. Re-inject it at the top of every call. Do not let it drift into the summary card during compaction. The pin block surviving compaction is what makes the summary card trustworthy.

Common misconceptions

“Compaction is the main technique.” It is the last resort. If you are compacting every few turns, you have skipped the upstream work of pruning tool output and summarizing resolved turns. Compact should fire rarely in a well-maintained session.

“The model reads everything equally.” It does not. The U-shaped attention curve is a real architectural property of transformer models, not a quirk of older, weaker models. Even the latest claude-opus-4-x and claude-sonnet-4-x models with 1M-token context windows show meaningful attention degradation in the middle of very long contexts. Where a fact sits matters as well as whether it is present.

“Summarizing loses important detail.” Summarizing resolved turns loses detail you no longer need. The discipline is in distinguishing what is still active from what is settled. Active issues stay verbatim; resolved issues become one-liners. If you are uncertain whether something is truly resolved, keep it verbatim a little longer — the cost of an extra turn’s context is small compared to losing a critical constraint.

“Coherent output means correct output.” A well-managed context produces coherent responses — the model stays on-task, does not contradict itself, does not forget the customer ID. But coherence is not correctness. A coherent answer can still be factually wrong or logically flawed. The next episode covers evals — the mechanism for systematically verifying that your well-managed context is actually producing right answers.

Frequently asked questions

What is the difference between summarizing and compacting? Summarizing is a scalpel: you collapse one resolved sub-thread into a one-liner while the rest of the conversation stays intact. Compacting is wholesale restructuring — a large chunk of middle conversation becomes a structured summary card, typically because window pressure demands it. Summarize proactively, turn by turn. Compact reactively, when the window is genuinely full.

How do I know when to compact? When you have already pinned stable facts, summarized resolved turns, and pruned tool output — and the window is still filling up — that is when compaction earns its place. A practical threshold: if context regularly hits 60-70% of the window limit mid-session after upstream cleanup, you need either tighter pruning or compaction as a release valve.

Should I pin context in the system prompt or inject it separately? Both work, but the pattern that survives the longest sessions is a dedicated pinned block at the very top of the context that you re-inject on every agentic turn. This prevents the pin content from being reinterpreted as conversation history as the session grows. Treat it as immutable infrastructure — it does not participate in the dialogue, it anchors it.

Does this apply to single-turn prompts or only multi-turn sessions? Pin and prune apply to single-turn prompts too — you still want stable facts placed first and lean tool output. Summarize and compact are inherently multi-turn concerns, since they act on accumulated conversation history. If you are doing a one-shot call with a large context injection, at minimum prune the injected documents to the sections the model will actually use.

Can I combine prompt caching with context engineering? Yes — they compose cleanly. The pin block, by definition, is the part of your context that is stable across turns, which is precisely what prompt caching is designed for. Mark the end of your pin block with a cache_control breakpoint and the API caches everything up to that point. You get the attention-positioning benefit of pinning and the cost benefit of caching from the same block. See Prompt Caching: Cut Your AI Bill for the full mechanics.

What is “observation masking” and how does it relate to pruning? Observation masking is a technique from 2025 research on coding agents (SWE-bench) where old tool outputs are replaced with placeholder tokens while the agent’s reasoning trace is preserved. It is a more aggressive form of pruning: instead of extracting the fields you used, you replace the entire tool output with a marker. Studies found this halved cost while matching the task-completion rate of full LLM summarisation. If you are building high-volume pipelines, it is worth considering as a middle ground between full pruning and full retention.

Where this fits in the series

This tutorial is part of How Claude Actually Works, a developer-focused course on building reliably with Claude. This episode sits at the end of the context management arc — after you understand the mechanics of how the context window works and how tokens map to your bill, this episode covers the active engineering decisions that separate a session that stays on-task from one that drifts. The prompt-caching episode (Prompt Caching: Cut Your AI Bill) is a natural complement — the same pin block that buys you coherence can be cached for a significant cost reduction. The next episode closes the loop: coherent is not correct, so we cover how to write LLM evals — how to systematically verify that your well-managed context is actually producing right answers. Browse all tutorials to follow the full series.