---
title: "Context engineering for AI agents"
description: "Context engineering is deciding what goes into the model's context window on every call. How it differs from prompt engineering, what competes for the window, the four moves that manage it, and where memory fits."
canonical: https://past.dev/context-engineering
last-updated: 2026-08-26
---
# Context engineering for AI agents

Source: https://past.dev/context-engineering

Context engineering is the practice of deciding what goes into a model's context window on each call: the instructions, the tool definitions, the retrieved evidence, the conversation history, the working state and the output contract. Prompt engineering is one part of it, the wording of the instruction. Context engineering is the whole budget, and it is the part that decides whether a long-running agent stays coherent. Memory is the component that answers its central recurring question: of everything this system knows, which parts belong in this call?

## What is context engineering?

Every call to a model is a fixed budget of tokens spent on one composition. Context engineering is the discipline of choosing that composition deliberately: what is included, what is summarised, what is left out, and in what order.

The term became common as agents replaced single-turn prompts. A single-turn prompt is written once by a person. An agent's context is assembled on every step by code, from sources that grow, so the interesting question moved from how do I phrase this to what should be in here at all. Anthropic's [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) is worth reading alongside this page.

## Context engineering vs prompt engineering

They are not rivals, one contains the other. Prompt engineering optimises the words in a fixed slot. Context engineering decides which slots exist, what fills them and what they cost.

|  | Prompt engineering | Context engineering |
| --- | --- | --- |
| Unit of work | The wording of an instruction | The composition of the whole window |
| Who does it | A person, once, at design time | Code, on every call, at runtime |
| Changes when | The task changes | The state changes, which is constantly |
| Typical failure | The model misunderstands the instruction | The right evidence was never in the window, or was buried in noise |
| Fixed by | Rewriting the instruction | Retrieving better, compressing harder, or splitting the task |
| Measured by | Output quality on a fixed set of prompts | Tokens per call, cost per answer, and how often the needed evidence was present |

## What competes for the window

Six claimants, and they grow at different rates. Naming them is most of the work, because the one that grows fastest is rarely the one being optimised.

- **System instructions.** Fixed, small, and the only part most teams edit.
- **Tool definitions.** Fixed per call, but they scale with how many tools the agent can reach, and a large tool surface is a large permanent tax.
- **Retrieved evidence.** Elastic. This is the part retrieval quality actually controls.
- **Conversation history.** Monotonically growing, and the usual cause of a run that degrades over time.
- **Tool results.** The quietest problem: a single large output can eat more of the window than everything else combined.
- **Working state and output contract.** Small, but the parts that must never be dropped.

## Agentic context engineering: why long runs are harder

In a single-turn application the context is assembled once and thrown away. In an agent, each step appends to the last, so three things happen that never happen in a chat.

1. **The window fills with the run's own output.** Tool calls, results and intermediate reasoning accumulate, and the earliest instructions end up furthest from the model's attention.
2. **Contradictions accumulate inside one context.** A value read at step 2 and updated at step 40 are both in the window, undated, with nothing marking which one is current.
3. **Cost grows with the square of the run.** Each step resends what came before, so a long run pays for its history repeatedly.

This is why long-running agents need a store outside the window with a maintained view of current state, rather than a longer window.

## The four moves

Everything teams do in practice is one of four moves. They compose, and most systems need all four.

### Select

Put in less, but the right less. Retrieval quality, reranking, and scoping evidence to the subject of the question. The cheapest win available, and the one with the highest ceiling.

### Compress

Summarise history, truncate tool output, replace a document with the three sentences that mattered. Effective, and lossy in a direction you did not choose, so it is worth keeping the raw material addressable rather than deleting it.

### Isolate

Give a subtask its own window and return only its conclusion. A sub-agent that reads fifty files and returns a paragraph has spent its own budget, not the parent's.

### Persist

Write outside the window and read back on demand: files, a scratchpad, a database, a memory layer. This is the only move that survives the session ending.

## Where memory fits

Selecting well requires knowing what is current, and that is a property of the store, not of the retriever. A retriever ranks by similarity, so a superseded statement and its replacement score alike; whichever wins, the model is handed a contradiction and no way to resolve it.

A memory layer resolves it before the window: it keeps the validity of each fact, returns the one that holds now, and carries the dated evidence so the model can cite rather than assume. In past.dev, `POST /api/v1/recall` returns that evidence with a token budget rather than a result count, which is the shape a context assembler actually needs, and `POST /api/v1/answer` returns a grounded answer with `abstained: true` when the evidence does not establish one. [What is agent memory?](/what-is-agent-memory) covers the storage side.

## How to measure it

Context engineering is measurable, which is what separates it from prompt intuition. Four numbers, tracked per version of the assembler.

- **Tokens per call, split by claimant.** Instructions, tools, evidence, history, tool results. The split is where the surprise lives.
- **Cost per answer**, not cost per token. past.dev reports `answerCostUsd` and `recallCostUsd` on every response for exactly this reason.
- **Retrieval sufficiency**: how often the evidence needed to answer was actually in the window. Measured separately from whether the model then answered correctly, because they fail for different reasons. Our harness reports both, and the method is on [benchmarks](/benchmarks).
- **Abstention rate.** A system that never says it does not know is not being careful, it is guessing on your behalf.

## Frequently asked questions

### What is context engineering?

The practice of deciding what goes into a model's context window on each call: instructions, tool definitions, retrieved evidence, conversation history, working state and the output contract. In an agent this composition is assembled by code on every step, not written once by a person.

### What is the difference between context engineering and prompt engineering?

Prompt engineering optimises the wording of an instruction at design time. Context engineering decides the whole composition of the window at runtime: what is retrieved, what is compressed, what is isolated into a subtask and what is persisted outside the window. Prompt engineering is one component of it.

### Is context engineering just RAG?

Retrieval is one of the four moves. Context engineering also covers compressing history, isolating subtasks in their own windows, and persisting state outside the window, plus the budget decisions between them.

### What is agentic context engineering?

Context engineering applied to multi-step agents, where each step appends to the last. Three problems appear that a single-turn application never has: the window fills with the run's own output, contradictions accumulate inside one context, and cost grows as each step resends the history before it.

### How do I measure context engineering?

Track tokens per call split by what claimed them, cost per answer, how often the needed evidence was actually present, and how often the system abstained. Optimising token count alone tends to improve cost and quietly damage accuracy.

## Related

- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Choosing a vector database for RAG](https://past.dev/vector-database-for-rag)
- [Vector database vs graph database vs memory](https://past.dev/vector-database-vs-memory)
- [Memory API overview](https://past.dev/docs/memory-api/overview)
- [How we measure memory](https://past.dev/benchmarks)