Skip to main content

02.11Concept

Context engineering for AI agents

Context engineering for AI agents as AR Labs practises it: choosing which instructions, knowledge, tools and memory enter a model's context window.

On this page
  1. Why it matters more for agents
  2. Four strategies
  3. How we apply it
  4. Our position

Context engineering, as AR Labs practises it, is choosing what goes into an AI model's context window, the text the model can see when it produces its next response. A language model knows nothing about a task beyond what is in that window, so the instructions, documents, tool results and memories placed there decide what it can do. Andrej Karpathy, a founding member of OpenAI, described it in 2025 as "the delicate art and science of filling the context window with just the right information for the next step."

Prompt engineering asks how to word a request. Context engineering asks what the model should be looking at when it reads the request, and it matters most for AI agents (language models run in a loop with tools) that work over many steps. At AR Labs it shapes how we organise files, plans and agent instructions.

Why it matters more for agents

An agent works in a loop: it reads, calls a tool, receives a result, reasons, and calls another tool. Every turn adds text to the context. Over a long task the window fills with old tool output, abandoned plans and repeated instructions, and the practitioner literature names the failures that follow. Distraction: the important instruction is buried in noise. Confusion: too many tools or options, and the model picks badly. Poisoning: an early mistake stays in the context and shapes everything after it. Clash: two pieces of context contradict each other. The writer Drew Breunig catalogued these four failures in "How Long Contexts Fail" (2025). The "lost in the middle" effect, measured by Nelson Liu and colleagues in 2023, compounds them: models use information at the start and end of a long context better than information in its middle.

The figure follows one agent's window from turn 1 to turn 80. The instruction that matters stays near the top while old output, abandoned plans and repeats pile up beneath it, and by the last turn each of the four failures has a place in the stack.

Six context windows from turn 1 to 80 filling with noise around one key instruction; marks name distraction, poisoning, confusion and clash, beside a lost-in-the-middle curve.Six tall bars show one agent's context window at turns 1, 5, 10, 20, 40 and 80, filling with old tool output, abandoned plans, repeated instructions and an early mistake until the one instruction that matters sits buried near the top of a full window. Numbered marks name the four failures: distraction, confusion, poisoning and clash. A small U-shaped chart shows models use the start and end of a context better than its middle.ONE AGENT'S CONTEXT WINDOW, TURN BY TURNTURN 1TURN 5TURN 10TURN 20TURN 40TURN 801DISTRACTIONthe key instruction, buried2POISONINGan early mistake stays3CONFUSIONtoo many options4CLASHtwo plans disagreeSTANDING INSTRUCTIONSTHE INSTRUCTION THAT MATTERSOLD TOOL OUTPUTABANDONED PLANREPEATED INSTRUCTIONAN EARLY MISTAKELOST IN THE MIDDLESTARTENDUSE
Over a long task the window fills with old tool output, abandoned plans and repeats until the instruction that matters is buried, and models use the middle least.

Larger context windows did not remove the problem; they changed it. When a window held little, the question was how to fit everything in. With room for a whole codebase, the question became which of the many available files actually matter for this step. Context curation became the core skill.

There is a direct parallel in human cognition. Karpathy's "LLM OS" analogy treats the model as a new kind of processor and the context window as its RAM. A cognitive scientist would compare the window to working memory: small, easily overloaded, and only as useful as what is loaded into it. Our founding framework, cognitive ecology, treats deciding what conscious attention holds as the main lever on performance, and context engineering applies the same idea to a model.

Four strategies

Lance Martin of LangChain, in "Context Engineering for Agents" (2025), grouped the techniques used by teams at Anthropic, Cognition and elsewhere into four moves.

FIG. 01
flowchart LR
  T["Task step"] --> W["Write: save plans and notes outside the window"]
  T --> S["Select: pull in only the relevant knowledge, tools and rules"]
  T --> C["Compress: summarise finished work"]
  T --> I["Isolate: give subtasks their own context"]
  W --> CW["Context window for the next step"]
  S --> CW
  C --> CW
  I --> CW
  • Write keeps information outside the window until it is needed: a scratchpad file, a state object, a long-term memory store. In Anthropic's multi-agent research system, the lead agent saves its plan to memory so the plan survives if the context window is truncated.
  • Select retrieves only what the current step needs, including tools; agents degrade when given too many tools at once.
  • Compress summarises completed work so that it takes less room, ideally only the finished sections, so active context stays intact.
  • Isolate splits work across subagents or sandboxes, each with its own window, so that exploration in one does not pollute another.

How we apply it

Progressive disclosure in the filesystem. VOX, the lab's working system, is organised so that an agent loads the most general, constraining information first and detail only when the work reaches it. Every project folder has an instruction file stating what success looks like, a strategy file stating the current approach, and below that the active plan and task records. An agent entering a project reads them in that order and stops when it has what it needs. Each layer narrows what is relevant in the next, the same way a person orients before diving into detail.

One authoritative document per concern. A rule copied into several files, each worded slightly differently, forces the model to reconcile the copies on every turn. We keep each fact in the one document that loads when the fact is relevant, and has other documents point to it rather than restate it. Our work on logical levels found this problem in practice: one rule for an agent appeared in five files.

Matching research depth to the size of the task. A one-line fix needs little context; a new subsystem needs research into the codebase before any code is written. Coding Planner, the tooling for our coding pipeline, whose early version is published as open source, began as a way to route each task to the right depth of research before an agent starts work. That idea now runs through our coding pipeline, where each step reads a written specification grounded in the current code rather than the whole repository.

Subagents as context forks. Research and review tasks are handed to subagents that work in their own context and return a short result, so the main session stays focused.

Teaching it. The same principles, explained for non-programmers, are the core of our second brain workshop.

Our position

As models improve, poor context costs more, not less: a capable model executes a bad plan confidently and at scale instead of getting stuck on it. We treat the context an agent receives as the part of an AI system most under the builder's control, and designs it with the same care as code. The harness paradox follows from this: well-specified context is what lets an agent work well on its own.