Context Engineering Techniques: Compaction, Isolation, RAG and More

Five techniques, one goal

Remember the desk: the context window is the only surface the model can see. This article is about housekeeping on that desk — what to keep, what to summarize, what to send to someone else, and what to refuse to put there at all.

Context engineering has one goal: the model should see everything it needs and nothing it does not. Every technique below is a way of pulling that lever from a different direction. You will mix them in real projects — the skill is knowing which one solves your current problem.

Here is the whole article in one line each, before we go deeper:

• Compaction — take notes on the conversation, then throw the transcript away.
• Isolation — send a colleague to read forty documents; they come back with one paragraph.
• RAG with filters — ask a librarian who checks the section and the year before reading anything.
• Long-context processing — dump the whole archive on the desk, once, when the job is huge.
• State — keep a notebook and bring it to every meeting.

Compaction: summarize the past

Compaction means rewriting old parts of the context into a shorter form. Think of meeting notes: you do not keep the verbatim recording of the first hour, you keep the three decisions that came out of it. After twenty turns of conversation, you do not resend all twenty verbatim — you ask the model to summarize the first fifteen into a paragraph and send that instead. Agents that run for hours do this constantly: when the window fills up, old tool dumps get squashed into a “so far we have done X and Y” note.

The trade-off is real: summaries lose detail. Keep the essentials (system prompt, the current task, key decisions) and let the small talk go.

Isolation: give subagents their own windows

Context isolation means splitting work across multiple model calls, each with its own clean context. A research agent that needs to read forty documents does not drag all forty into the main conversation — it spins up a subagent, the subagent reads and returns a summary, and the main context only ever holds that summary. Like delegating research to a colleague: you never see their pile of books, only the one page they hand back.

You already know this pattern from functions in code: the subagent’s messy internal state is hidden behind a small return value. Isolation keeps the main window small and focused, at the cost of losing nuance across the boundary.

RAG and dynamic filters

RAG pulls in only the documents relevant to the current question. But the retrieval step is where context quality is decided, and naive “top 5 similar chunks” is rarely enough. Dynamic filters tighten retrieval at runtime: filter by language, date, document type, user permissions, or product line before ranking. The librarian checks the section, the year and your access badge before pulling anything off the shelf. Five filtered chunks beat fifty raw ones — both in tokens and in signal.

Here is the whole thing as code. Read it top to bottom — the comments name the technique each line uses:

1def build_context(query, history):
2  # This function runs on EVERY request. What it returns is
3  # literally everything the model will see.
4  context = []
5 
6  # 1. Standing instructions, always first: the rules that
7  #    must survive everything else.
8  context.append(SYSTEM_PROMPT)
9 
10  # 2. COMPACTION: 40 old turns become one paragraph.
11  #    Cheaper than history, and it drops the dead ends.
12  context.append(summarize(history))
13 
14  # 3. RAG + DYNAMIC FILTERS: search the knowledge base, but
15  #    only among chunks in the right language, from the last
16  #    12 months, that this user is allowed to see.
17  docs = retriever.search(
18      query,
19      top_k=3,
20      filters={#98c379">"lang": user_lang,
21               #98c379">"date": "last_12_months",
22               #98c379">"acl": user_permissions})
23  context.extend(docs)
24 
25  # 4. The live question goes last, where the model
26  #    pays the most attention.
27  context.append(query)
28 
29  return context

In plain words: rules first, a short version of the past next, only the documents that survived the filters after that, and the actual question at the very end. That is the shape of a well-built request.

Long-context processing: sometimes just paste it all

Modern models handle 128K tokens and more, which opens a different strategy: long-context processing — dump the entire document set into the window and let the model find what it needs. For one-off deep analysis of a codebase or a long contract, this is honest work and beats building a retrieval pipeline.

The costs: latency grows with the window, price grows faster, and attention quality degrades in the middle of very long contexts — the model does not read the middle of a huge pile as carefully as the edges. Long context is a tool for occasional heavy jobs, not the default for every user question.

State and historical context

Finally, some information must persist across sessions: user preferences, project decisions, past mistakes. This is state — carefully curated and loaded into context at the start of each session, like a notebook you bring to every meeting. The discipline here is curation: memory that grows unbounded becomes a junk drawer that poisons every future request. Store decisions and preferences; expire stale facts.

When to apply which

Watch compaction happen. Toggle the checkbox and see which parts of a long session survive — and how much budget it frees:

Where this leaves you

Each technique is also a new way to fail: a bad summary, a noisy retrieval, a stale memory. Knowing how context breaks — and how to catch it before your users do — is the piece that makes all of this real.