Skip to content

← Blog

Context EngineeringContext Management10/11/2026

Best Practices: Context Engineering

In this post, I take a closer look at so-called “context engineering”: the management of what we give AI agents as the basis for their work and continuously develop over the course of a session.

Introduction

Context engineering is one of the less obvious levers when working with AI agents. One reason is that agents manage their context more or less automatically. In this sense, the “context” is the sequence of tokens passed to a model for processing, i.e., for inference.

As soon as we start a new session, the context is already initialized by the starter or system prompt and the tools available to the agent. It may be extended by a bootstrap prompt and is then continuously built up by our further session prompts and the agents’ tool calls. Much of this happens automatically, and apart from a small indicator of how “full” the context window already is, we usually notice little of it.

Nevertheless, it is worth taking a closer look at the underlying mechanisms. The context is decisive for the quality of the artifacts the agent creates and has a considerable impact on the resulting costs. Simply keeping the context as small as possible, however, is too simplistic. A quick teaser up front: the goal is a context that contains everything relevant, not the smallest possible context.

How the Context Is Built

When we start a new session, the context is already partially filled. The coding tool gives the model basic instructions, usually via a system or starter prompt. In it, the vendor defines how the agent should work, use tools, and communicate with us. Added to this are descriptions of the available tools and, depending on the tool, further information such as personal preferences or descriptions of available skills. A no longer entirely current but still worthwhile example of a Codex starter prompt can be found in the OpenAI developer documentation.

Our own project instructions complement this foundation. Files such as AGENTS.md or CLAUDE.md are taken into account automatically by the tool. After that, the context grows through our prompts, the model’s responses, and the results of its tool calls: files read, search results, test output, and much more.

Context Window

As described at the beginning, the context comprises all information available to the model for a request. Its size is measured in tokens. Tokens are the units into which text is split for processing by the model, such as whole words, parts of words, or punctuation marks. The context window limits how many tokens the model can process in total. This lets us distinguish between the actual content and the available capacity.

Context engineering means deliberately selecting, structuring, and continuously maintaining the information in the context. And doing so within the available context window, with a view to the achievable quality of the results and the tokens required (and paid for) to get there.

Screenshot: Context window usage in Claude Code
Example from Claude Code: usage and composition of the context window in a running session

The size of the context window varies by vendor, tool, and access path. As of October 2026, for example, Anthropic’s Claude Code with Sonnet 5.5 or Opus 5.5 offers a context window of 1,000,000 tokens even in the smallest subscription tier (“Pro”). In my current OpenAI Codex configuration with GPT-6 Astra, by contrast, it is “only” 272,000 tokens.

If quality were the only concern, we would try to use the available context window optimally. Mind you, “optimally”, not “maximally”. Even with newer models, the usable fill level of the context window remains an issue. A large context window initially describes the amount of information that can technically be processed. How reliably the model uses it depends on the task and the content. A general, frequently cited limit of 80% fill level is not backed by evidence. It is unclear whether findings from older studies are still relevant. One example is this paper on “context rot” from May 2026: used as safety monitors for coding agents, Opus 4.6, GPT 5.4, and Gemini 3.1 missed dangerous actions 2 to 30 times more often when they were preceded by around 800,000 tokens of benign activity. Whether the results discussed in the paper carry over to other tasks and current models remains open. The vendors do not provide a reliable, generally applicable limit.

The matter becomes more complex because of the second factor besides the quality achieved by the agents: cost. In professional environments, billing is often token-based. And each model call counts not only the current prompt but the entire active context. A larger context therefore increases the cost of the next request to the model. How much the cost rises depends, among other things, on the model, the pricing plan, and the reuse of already processed parts of the context through prompt caching. Anyone who uses cost monitoring tools such as LiteLLM can observe this very nicely.

Automatic Context Management

Tool vendors are of course aware of the balancing act between keeping all information relevant to the session in the context and keeping an eye on the context size at the same time. That is why common coding tools offer mechanisms for automatic context management:

  • Loading information on demand: The agent initially reads only the parts of the project that are relevant to the task. This principle is also known as just-in-time context. Progressive disclosure applies it to instructions and tools: for skills, only the name and description are available at first, and the full instructions are loaded only when the skill is actually used. The descriptions of the tools provided by an MCP server can also be loaded on demand. This prevents the initial context from already containing all detailed instructions and tool definitions.

  • Offloading results and notes: Current coding tools can, for example, offload extensive tool output to temporary files, from which the agent takes only the excerpts it needs into the context. This behavior is easy to observe. It is worth taking a look at your own /tmp directory. On my machine, I typically find the leftovers of the latest AI sessions there. Cleaning up is obviously not yet one of the agents’ core competencies, but that may still come. In addition, some coding tools offer a memory feature that lets agents store selected insights and decisions in persistent notes and read them back later. This can happen automatically or on explicit instruction.

  • Removing content that has been read from the context: Content that has already been read may be removed from the active context again. Typical candidates are older tool outputs such as file contents or search results.

  • Context compaction: Context compaction (called auto compaction when it runs automatically) goes one step further and replaces parts of the context with automatically generated, condensed versions. The goal is to preserve the objective of the current session, important decisions, the current state of work, and open issues. This process can take several minutes and is indicated accordingly in the tools. In my view, context compaction is a necessary evil that makes continued work in long, complex sessions possible in the first place. However, it is also clear that we do not know for sure which parts of the context are treated as, for example, “important decisions” and preserved. And which are not. In my experience, the quality of the results still suffers from context compaction today, so I try to avoid compactions where possible. I come back to this point in more detail below in the section “Manual Context Maintenance”.

  • Delegating subtasks: If the coding tool supports subagents, the main agent can, for example, delegate research to another agent with its own context window. The files it reads, its search results, and its intermediate steps then do not additionally fill the main context. All that comes back is a compact result report. Claude Code, for example, uses built-in subagents for code exploration.

Manual Context Maintenance

Even though automation already takes a lot of context engineering off our hands, we should not rely on it completely. If only because the motivation to reduce costs is probably less pronounced on the vendor side than on the user side. I therefore recommend getting to know the following techniques for manual context maintenance and integrating them into your own workflows with agents:

  • Limit sessions: In my opinion, the most important and simplest technique is: one task per session. I have already touched on this point indirectly in my posts on feature specifications and implementation plans. Instead of trying to cram everything from specification through planning and implementation into a single session, we create separate artifacts in separate sessions. Each new session receives the results of the previous steps that are relevant to its task as its foundation. Among many other benefits, this keeps the context of each session small and focused.
  • Select tools and skills deliberately: It is of course tempting to enable as many tools and skills as possible in the coding tool’s configuration. After all, this makes your own agents “more powerful” and offers new opportunities for automation. But all of this also takes up space in the context window, even if only names and descriptions are loaded at first. In the screenshot above, the MCP tools occupy around 17,000 tokens in the context, while another roughly 124,000 tokens are marked as “deferred” and are loaded only when needed. I therefore try to enable only the tools that are absolutely necessary by default. I add rarely used tools as needed.
  • Write prompts carefully: Every prompt has to be written carefully and with focus. That sounds trivial, but in my experience it is anything but. Vague prompts lead to exploratory file reads and correction loops that needlessly fill the context. I write prompts the way I used to write source code. Even if agents invite you to chat, a prompt is not a “conversation”. It is a targeted work instruction, in fact a kind of new source code.
  • Avoid auto compaction: For me, automatic context compaction is the signal to review the scope of my session; see the first item in this list. It is not that I abort immediately and “force” a new session. As a rule, I keep working for the time being and bring the session to a sensible end. But as a signal that it is time to start wrapping things up, compaction definitely does the job.
  • Try semantic anchors: The idea behind semantic anchors is to use established technical terms such as “arc42” or “Nygard-style ADR” in prompts. The assumption is that the model draws on knowledge it has already learned, which saves many tokens of description. There is even a catalog on GitHub that collects suitable terms. Personally, I find the idea behind it exciting, which is why I mention it in this post, but I have little experience with it myself so far. Success depends on whether the models know the terms and interpret them as intended.

Conclusion

As the cost question becomes increasingly relevant, at least in professional environments, it is worth anchoring context engineering explicitly in your own development process. In my view, separate sessions for specification, planning, implementation, and reviews are the most effective measure to start with. It is also worth regularly reviewing all standard prompts, such as the bootstrap prompt and the project instructions, and sharpening their focus where necessary instead of simply “making them shorter”. In addition, established best practices, such as the mentioned attention to automatic context compaction, should be communicated to teams regularly. Anyone who has already established an AI-Driven Development process with corresponding documentation has a relatively easy time. For everyone else, this is another opportunity to consider the benefits of such a process in their own organization.