Context engineering for agents

Who this is for and what you can do after reading

This guide is for developers building AI agents who notice that their agents sometimes miss the point or forget what was said earlier. After reading, you should be able to break a task into three questions about what information is needed, where it comes from and how it gets into the context, and recognize the four common context failures and their fixes.^[1]

What context engineering is

For an agent, context is what drives its planning and the actions it takes next. Context engineering is the practice of making sure the agent has the right information to complete the next step of its task.^[1]

The context window has a limited size, so builders need systems and processes for adding, removing and condensing information in it.^[1]

It differs from prompt engineering in scope. Prompt engineering focuses on a single set of static instructions that guide an agent with rules. Context engineering manages a dynamic set of information, including the initial prompt, so the agent has what it needs throughout the task. The aim is to make this process repeatable and reliable.^[1]

Five kinds of context

Context is not one thing. An agent may draw on several sources:^[1]

• Instructions: the agent's rules, including prompts, system messages, few-shot examples and descriptions of the tools it can use. This is where prompt engineering and context engineering meet.
• Knowledge: facts, information retrieved from databases and long-term memories the agent has built up. When an agent needs several knowledge stores, a Retrieval Augmented Generation (RAG) system can be added.
• Tools: definitions of external functions, APIs and MCP servers the agent can call, along with the results it gets back.
• Conversation history: the ongoing dialogue with a user. It grows longer and more complex over time and takes up space in the context window.
• User preferences: what the agent learns about a user's likes and dislikes over time, which can be stored and used for key decisions.

Plan first: three questions

Good context engineering starts with planning:^[1]

1. Define the result. What will the world look like when the agent has finished? What change, information or response should the user have after the interaction?
2. Map the context. What information does the agent need to complete the task, and where can that information be found?
3. Build context pipelines. How will the agent get the information? Options include RAG, MCP servers and other tools.^[1]

Six ways to manage context

Once information flows into the context window, it has to be managed actively. Six strategies help:^[1]

1. Agent scratchpad: the agent notes what matters for the current task during one session. The notes live outside the context window, in a file or runtime object the agent can retrieve later.
2. Memories: agents store and retrieve relevant information across multiple sessions, such as summaries, user preferences and feedback. A scratchpad covers one session; memories cover many.
3. Compressing context: when the window nears its limit, summarization and trimming keep the most relevant information or remove older messages.
4. Multi-agent systems: each agent has its own context window, so a multi-agent system is itself a form of context engineering. How context is shared and passed between agents has to be planned.
5. Sandbox environments: when an agent runs code or processes a large document, the output can consume many tokens. A sandbox can run the code and return only the results and relevant information.
6. Runtime state objects: containers that store the result of each subtask step by step, so the context stays connected only to that subtask.^[1]

Inspecting what the model received

After applying a strategy, check what the next model call actually received. A useful debugging question is whether the agent loaded too much context, the wrong context, or missed context it needed.^[1]

You do not need to log raw prompts, tool outputs or memory contents to answer it. In production, small inspection records work better, capturing counts, ids, hashes and policy labels:^[1]

• Selection: how many candidate chunks, tools or memories were considered, how many were selected, and which rule or score filtered out the rest.
• Compression: a range of source content or a trace id, the summary id, the estimated token count before and after, and whether the raw content was excluded from the next call.
• Isolation: which subtask ran in a separate agent, session or sandbox, what bounded summary came back, and whether large tool output stayed out of the parent agent's context.
• Memory and RAG: retrieval document ids, memory ids, scores, selected ids and redaction status, instead of full retrieved text.
• Safety and privacy: hashes, ids, token buckets and policy labels, in place of sensitive prompt text, tool arguments, tool results and memory bodies.

The goal is not to keep more context. It is to leave enough evidence to show which strategy ran and whether it changed the next model call as intended.^[1]

Four common failures and their fixes

When the context goes wrong, an agent can seem to suddenly get worse. There are four common patterns, each illustrated with a flight-booking case.^[1]

Context poisoning. A hallucination (false information generated by the LLM) or an error enters the context and is referenced again and again, so the agent pursues impossible goals. The fix is context validation and quarantine: validate information before it is written into long-term memory, and start fresh context threads if poisoning is detected. For example, an agent invents a direct flight from a small local airport to a distant international city that does not exist. Every later booking attempt chases that route. The fix is to check the flight and route with a real-time API before the detail enters the working context. If the check fails, the information is quarantined and not used.^[1]

Context distraction. The context grows so large that the model focuses on accumulated history instead of what it learned in training, and it can make mistakes before the window is full. The fix is context summarization: periodically compress the accumulated information into shorter summaries that keep the important details. For example, a long chat about dream destinations and an old backpacking trip can bog the agent down when the user finally asks for a cheap flight next month. The fix is to summarize only the recent, relevant parts, such as the current dates and destination, and drop the rest.^[1]

Context confusion. Unnecessary context, often too many tools, leads the model to produce poor answers or call irrelevant tools, and smaller models are especially prone to it. The fix is tool loadout management with RAG: store tool descriptions in a vector database and select only the most relevant tools for each task. Research points to keeping tool selections under 30. For example, an agent with dozens of tools may try to book a flight inside Paris when the user asks how to get around. The fix is to retrieve only tools such as rent_car or public_transport_info for that question.^[1]

Context clash. Conflicting information in the context leads to inconsistent reasoning or poor final answers, often because early wrong assumptions stay in place as information arrives in stages. The fixes are pruning, which removes outdated or conflicting information as new details come in, and offloading to a scratchpad that reconciles the conflict outside the main context. For example, a user first asks for economy class and later says business class. If both instructions stay, search results conflict. The fix is to remove or override the old instruction, or to settle the conflict in a scratchpad so only the final, consistent instruction guides the agent.^[1]

The Paris example

Asked to book a trip to Paris, an agent that uses only prompt engineering asks when the user wants to go. An agent that uses context engineering might first check the user's calendar, recall past travel preferences from long-term memory and identify which flight and hotel tools are available. Its reply then fits the user's actual situation.^[1]

Things to watch for

• Context engineering is not about adding more information. The goal is to give the agent just enough, and to show that it worked.^[1]
• When logging inspection data, store ids and labels rather than memory bodies or sensitive tool arguments.^[1]
• This guide covers concepts and categories, not code.

Where to go next

For how long-term memory works in practice, read the article on agent memory in this series. For the basics of RAG and the context window, see the concept pages.^[1]

Adapted from lesson 12 of Microsoft's open-source course *AI Agents for Beginners*^[1], released under the MIT License.