What is context engineering? A working definition for agent builders

Context engineering is the work of deciding what goes into a model's context window at each step of a task, and in what form, so the model has what it needs to do the next thing right and as little as possible that it doesn't.

That's the whole definition. The rest of this post is why it became its own discipline, what a context is actually made of, the handful of operations you have for shaping it, how it fails, and the part of it that most agent setups leave out entirely.

Where the term came from

The phrase took off in June 2025. Shopify's Tobi Lütke said he preferred "context engineering" to "prompt engineering" because it describes the core skill better: giving the model all the context it needs for the task to be plausibly solvable. Andrej Karpathy agreed within a day and sharpened it: in any serious LLM application, the craft is filling the context window with just the right information for the next step. Anthropic's applied AI team followed in September with a long guide to context engineering for agents, and the term stuck.

It stuck because it named a shift people had already made. Prompt engineering is about one string, written once, usually by hand. An agent running for forty turns doesn't have a prompt; it has a context that's rebuilt on every call from a dozen sources, most of which nobody typed. The system prompt is maybe 5% of what the model reads by turn thirty. The other 95% is tool definitions, file contents, command output, earlier turns and whatever retrieval pulled in. Engineering that 95% is the job.

Prompt engineering vs context engineering

Prompt engineering didn't go away. It became one input among many: the system prompt is a context engineering decision like any other, just the one that changes least.

What a context is made of

On any given call, a coding agent's context is built from roughly seven things:

1. The system prompt. The harness's instructions: how to use tools, how to format output, what not to do.
2. Instruction files. CLAUDE.md, AGENTS.md, Cursor rules. Loaded at session start, paid for on every turn.
3. Tool definitions. Every tool's name, description and input schema. Connect five MCP servers with twenty tools each and you're spending thousands of tokens describing tools before the user has typed anything.
4. The conversation so far. Every user message and every assistant turn.
5. Tool results. File reads, grep output, test logs, API responses. In a coding session this is usually the largest category by far, and most of it is read once and never needed again.
6. Retrieved knowledge. Whatever a search step pulled in: docs, code chunks, tickets.
7. Memory. What carries over from outside this session: the agent's own notes, a user profile, or a team's recorded history.

Context engineering is deciding, for each of those, what's in, what's out, what gets summarized and what gets loaded only when asked for.

Why it's hard: the window is finite, and attention is worse than finite

The obvious constraint is size. Every model has a maximum context, and a long agent session hits it.

The less obvious constraint matters more: models get worse well before the window is full. Researchers showed in 2023 that models use information at the start and end of a long input better than information in the middle. Chroma's 2025 "context rot" study tested 18 models and found performance drops as input length grows, even on simple tasks, and that distractors (text that looks relevant but isn't) make it drop faster. A million-token window doesn't mean a million tokens of useful attention.

So every token you add has a price beyond its cost in dollars: it competes with every other token for the model's attention. A context engineer's default question isn't "what might help?" It's "what's the smallest set of tokens that makes the next step likely to go right?"

The four operations

LangChain's Lance Martin grouped context engineering techniques into four operations, and it's the most useful map we've found:

• Write: save information outside the window so it doesn't have to stay in it. A scratchpad file, a todo list, a progress note, a memory store.
• Select: pull information into the window when it's needed. Retrieval, grep, loading a skill's instructions only when the skill is invoked, recalling a memory.
• Compress: keep the meaning, drop the tokens. Summarizing old turns, compacting the conversation near the limit, clearing tool results the agent has already acted on.
• Isolate: split work across separate windows. A sub-agent explores in its own context and hands back a summary; a sandbox holds large objects outside the model's view.

Every technique you'll read about is one of these, or two combined. Compaction is compress. Sub-agents are isolate plus compress. Skills with progressive disclosure are select. We go through each one, with what it costs and what it loses, in Context management strategies for coding agents.

How contexts fail

Drew Breunig catalogued the ways a long context goes wrong, and they're worth knowing by name because each one has a different fix:

• Poisoning. A wrong fact, often a hallucination from an earlier turn, gets into the context and is treated as true from then on. Fix: verify before writing anything to memory, and let wrong facts be removed.
• Distraction. The context gets so long the model leans on it over what it learned in training, and repeats past actions instead of reasoning fresh. Fix: compress and prune.
• Confusion. Irrelevant material, like forty tool definitions for a task that needs three, pulls the model toward the wrong action. Fix: select tools and documents per task.
• Clash. Two pieces of context disagree, such as an old decision and the one that replaced it, and the model has no way to know which wins. Fix: reconcile before injecting, so only the current one arrives.

The last one is the most underrated, and it's mostly a memory problem. Any system that stores decisions over months will eventually store contradictory ones. If both get retrieved, the model averages them or picks one at random.

The part most setups skip: context nobody wrote down

Look at the seven sources again. Six of them are things the agent can reach on its own: its harness, its files, its tools, its session. The seventh, memory, is the one that has to come from outside, and it's where the hardest context lives.

The context that decides whether an agent does a task right is often something like: the production database is being phased out and new accounts land in ridgeline; the integration tests need the VPN; we tried the queue approach in March and reverted it because of ordering. None of that is in the repository. It was said in a session, a Slack thread or a review comment, by a teammate, weeks ago. No amount of selecting, compressing or isolating inside one session recovers it, because it was never in the session to begin with.

That's the gap Glen fills. It records your team's agent sessions and the tools you already use (Slack, GitHub, Linear, Notion, call transcripts), turns them into observations with a source on each, and injects what's relevant into the session before the agent goes looking. In context engineering terms, it does all four operations on a team's history so the agent doesn't have to:

• Write: every session is recorded through plugin hooks, with no one deciding to save anything.
• Select: relevance is judged against the live session, and only what applies is injected.
• Compress: instead of handing over ten raw transcripts, Glen returns one synthesized answer with a citation on every claim.
• Reconcile: when a newer decision contradicts an older one, the older one stops surfacing, which is the clash failure handled before it reaches the window.

We measured what that does to a real workload in Replaying 100 PRs with and without Glen: 29% fewer tokens, 21% faster, quality at parity or better. The savings came almost entirely from the start of each session, the phase where an agent without the right context greps around rebuilding what the team already knew.

A short checklist

If you're building an agent, or just configuring one for your team, these are the questions context engineering asks:

1. What does the model see on turn one, and how many tokens is it before the user types?
2. Which of your always-loaded instructions are needed on every turn, and which could load on demand?
3. What happens to tool output after the agent has acted on it?
4. What happens when the session approaches the window limit, and what does compaction lose?
5. Which exploration could run in a sub-agent and come back as a summary?
6. What does the agent need that was never written down, and where will it come from?
7. When two stored facts disagree, which one does the model see?

Most teams have answers for the first five. The last two are where agents still lose the most time, and they're the two Glen is built for.

npx @tryglen/cli@latest install

Start free · Glen's MCP server