Context Engineering

What Context Engineering is

If Prompt Engineering is about phrasing the instruction well, Context Engineering is the broader step: managing everything that goes into the model's context window on each call — the instructions, the retrieved knowledge, the history, the tool results and the examples. In 2026, as systems became multi-step agents, this became the single most critical skill.

The core idea: the model is only as good as the context you gave it. Throw too much irrelevant information at it — it gets confused and expensive. Give it too little — it guesses. Context Engineering is finding the right mix: the right information, in the right amount, in the right order.

The context window and its problems

The context window is the amount of text (in tokens) the model can "see" in a single call. Even when it's huge, there are three real problems:

• Lost in the middle: models tend to pay more attention to the start and end of the context, and less to the middle. Critical information buried in the middle can "vanish."
• Context rot: as the context grows and accumulates (in a conversation or an agent), quality degrades — the model confuses details and loses focus.
• Cost and time: every token in the context costs money and time. A bloated context = a big bill and a slow response.

The conclusion: more context isn't necessarily better. The goal is relevant, concise context, not maximal.

Parts of the context

Good context is made of several parts, each needing management:

1. System prompt / instructions: role, rules, format. Relatively stable.
2. Retrieved knowledge (RAG): the most relevant passages from the knowledge base — not everything, only the relevant.
3. Conversation history: previous messages. The part that grows and needs management.
4. Tool results: outputs from tool calls (search, API). Can be enormous.
5. Examples (few-shot): 1–3 examples that steer the model.
6. The current query: what the user just asked.

Key techniques

1. Selective retrieval

Instead of pushing a whole document, retrieve only the relevant passages with RAG. This is the basic tool for shrinking context without losing information.

2. Compression & summarization

When the history or a tool result is too big — summarize it before putting it in the context. For example, in a long conversation: summarize the first 10 messages into a paragraph, and keep only the latest ones in full.

3. Ordering & structuring

Put the critical information at the start or end (not the middle). Use clear tags/headings (<knowledge>...</knowledge>) so the model distinguishes between parts. Clear structure improves accuracy.

4. Memory management

Not everything needs to be in every call. Keep "long-term memory" (user preferences, facts) separately, and retrieve only what's relevant to each interaction — exactly like RAG, but over memory.

5. Tool result pruning

A tool that returns 5,000 lines of JSON — don't insert all of it. Filter/summarize before returning it to the model. This is one of the big problems in agents.

The big challenge: context in agents

In a multi-step agent, the context accumulates — each step adds a thought, a tool call and a result. After 15 steps, the context is bloated, expensive, and suffers from context rot. This is why agents "fall apart" on long tasks.

Strategies that work:

• Interim summarization: every few steps, summarize the progress and "reset" the detailed history.
• Sub-agents: split a task into sub-agents, each with its own clean context, and return only the result.
• External scratchpad: store state/findings outside the context (a file/DB) and retrieve as needed instead of dragging everything along.
• Aggressive tool-result pruning: keep only what's needed to continue.

Common mistakes

• "More context = better." The common mistake. A bloated context hurts accuracy and cost.
• Throwing in a whole document. Instead of retrieving only the relevant passage.
• Not managing history in an agent. The context swells until the system collapses.
• Critical information in the middle. It vanishes due to lost-in-the-middle. Put it at the start/end.
• Unstructured context. Mixing instructions, knowledge and history without separation confuses the model.