Context Engineering: An Interactive Guide to How AI Agents Work
Learn how AI agents build and use context. The window, the loop, context rot, compaction, and memory, each explained with an interactive demo.
Ian Nuttall
Context engineering is the skill of controlling what an AI model sees while it works. The model reads one stream of text (its instructions, your messages, open files, tool output) and sees nothing else. Control that stream and you control the quality of the work.
The skill matters because the model itself remembers nothing between calls. An agent that read your file a minute ago only “remembers” it because the text is resent on every turn. This guide explains how agents build context, why quality drops as context grows, and how loops and memory fix that. Each idea comes with a demo you can poke.
What is context?
Context is everything the model receives when it generates a response. Your message is a small slice of it. The harness, meaning the program wrapped around the model (Claude Code, Codex, and friends), assembles the rest on every turn. Its own standing instructions. The conversation so far. Any files the agent has opened. The output of any tools it has run.
01 / What the model sees
Context is everything inside the window
The model reads one long stream of text on every turn. Whatever is in that stream is all it knows about your task.
Inside the window
Nothing outside the window exists for the model. Not your other files, not last week's chat, not the thing you told it yesterday.
Diagram: you send a message, the harness assembles a context window (instructions, your message, files, earlier turns, tool results), and the model reads that single stream. Nothing outside the window exists for the model.
There is no side channel where the model quietly knows things. If a fact is in the window, the model can use it. If it is anywhere else, it may as well not exist.
Every model has a maximum context window
Context is measured in tokens, small chunks of text that work out to about three-quarters of an English word each. Every model has a cap on how many tokens it can process at once, and the cap covers everything. Your instructions, the conversation history, file contents, tool results, and the reply the model is about to write.
The current frontier models are close together on this. Claude Fable 5 holds a million tokens by default, which Anthropic says is roughly 555,000 words. OpenAI’s GPT-5.6 family of Sol, Terra, and Luna holds 1.05 million. Google’s documented ceiling for Gemini 3.1 Pro is a million. Smaller, faster models like Claude Haiku 4.5 hold 200,000.
02 / The limit
How much fits in today's frontier models
The whole session has to fit inside one window: instructions, conversation, files, tool output, and the reply the model is about to write.
Verified August 2026. A million tokens is roughly 555,000 words, and it still runs out faster than you would think.
Context windows, verified August 2026: Claude Fable 5 holds 1M tokens (128k reserved for output), GPT-5.6 Sol holds 1.05M (128k output), Gemini 3.1 Pro holds 1M (64k output), Claude Haiku 4.5 holds 200k (64k output).
A million tokens sounds like more than anyone could need. It runs out anyway. A single log file can cost 50,000 tokens, and an agent will happily open twelve of them. Paste something into the token counter to see how fast real text adds up. And as we will get to shortly, quality starts to slip long before the window is technically full.
An agent is a model in a loop
A chat assistant answers once and stops. An agent keeps going. It reasons about the task, does something, looks at what happened, and decides its next move, over and over until the job is done.
The doing happens through tools. A tool is a function the harness offers to the model, like read this file, run the tests, search the web. The model cannot execute anything itself. It writes a small structured request, the harness performs it, and the result lands back in the window as new context for the next turn.
03 / The loop
An agent is a model running in a loop
Reason, act, observe, repeat. The loop runs until the agent decides the task is done and writes its answer.
The model reads the window and plans its next move.
The agent loop is a circle: the task and its context come in, the model reasons about its next move, acts by calling a tool or writing the answer, observes the result as new context, and goes round again until the task is done.
Researchers named this shape the ReAct pattern, for reason and act, and every serious coding agent today runs some version of it. The part that matters for this guide is simpler. Every trip round the loop adds text to the window. The loop feeds on its own history.
Watch a real task fill the context window
Here is a genuinely ordinary agent task. A test is failing, and the agent has to work out why. Press play and keep an eye on the right panel.
04 / The loop in action
Watch a real task fill the context window
The task is small and real. The login test is failing and the agent has to find out why. Conversation on the left, context window on the right.
Press play to watch one real task move through the loop.
Conversation
The login test is failing. Find out why and fix it.
I will run the test suite first to see the error.
run_tests()
FAIL login.test.ts. Expected status 200, got 401.
Login rejects a valid user. I will read the auth code.
read_file("src/auth.ts")
340 lines of src/auth.ts
Line 121 checks token expiry the wrong way round. Fixing it.
edit_file("src/auth.ts", line 121)
Edit applied.
run_tests()
PASS. 24 tests passed.
Fixed. The expiry check was inverted, so every fresh token looked expired.
Context window, resent on every turn
3.6k tokens go to the model on the next turn
Step-through simulation of one agent task ("the login test is failing, find out why and fix it"): the agent runs the tests, reads a 340-line auth file, spots an inverted token-expiry check, edits the file, re-runs the tests, and reports the fix. Each step appends messages and tool results to the context window, which grows from 3.6k tokens to about 7.8k. The whole window is resent to the model on every turn.
Two things are worth noticing. At step 6 the agent read one medium-sized file, and that single read cost more tokens than the entire conversation before it. The file did nothing wrong. Files are just big, and agents read a lot of them.
The second thing is the label on that right panel. The model is stateless, so the harness resends the whole window on every turn. What looks like a colleague who remembers your morning conversation is closer to a brilliant temp who gets rebriefed from a transcript every few seconds, and whose briefing keeps getting longer.
Quality degrades as context grows
A growing window would be harmless if models used all of it equally. They do not. Researchers showed in 2023 that models are strongest at the start and end of their context and measurably worse in the middle, a finding known as lost in the middle. In 2025 Chroma tested 18 models and found that performance degrades as input grows even on tasks as simple as finding a matching sentence. Anthropic’s own context engineering guidance treats attention as a budget that thins out as the window fills.
People call the combined effect context rot. The session gets heavier, the useful fraction shrinks, and the model starts missing things that are right there in the window.
05 / Context rot
A long session slowly buries what matters
Fast-forward the same session. The orange block is the one fact the agent still needs. Watch where it ends up.
Early in a session the window is mostly empty and everything in it matters.
Lost in the middle
Models pay most attention to the start and end of the window. Facts buried in the middle get overlooked.
Recency bias
Whatever arrived last carries outsized weight, even when an earlier instruction matters more.
Noise buildup
Every loop step leaves residue. Old file dumps and stale test output dilute the signal.
As an agent session runs on, residue from finished steps fills the context window and the one fact the agent still needs drifts into the middle, where models pay the least attention. Three failure patterns: lost in the middle (facts mid-window get overlooked), recency bias (the latest text carries outsized weight), and noise buildup (old file dumps dilute the signal).
I hit this most on long coding sessions. Around the hour mark an agent will confidently reach for an approach we abandoned forty minutes earlier. The abandoned plan is still sitting in the window. The correction is buried in the middle, in exactly the spot models skim.
Compaction summarizes old work to free space
Harnesses handle a heavy window the way you handle a full notebook. Summarize the old pages, keep the summary, move on. Claude Code does this automatically as a session approaches the context limit, and you can trigger it yourself with a compact command. The finished work gets rewritten into a short summary that preserves decisions and outcomes while the bulky tool output is dropped.
06 / Compaction
Compaction rewrites the window to free space
Every cell is about 175 tokens. Press compact and watch the finished work get wiped, cell by cell, and replaced with one short summary.
The window holds 12,570 tokens of finished work. Press compact to fold it away.
Compaction demo, drawn as a disk defragmenter: a 12,570-token window full of old file contents, test output, and reasoning is wiped cell by cell and replaced with one short summary. The window drops to 4,390 tokens. Instructions, tools, and recent turns survive; the wiped detail is gone unless it was saved outside the window.
Compaction is lossy on purpose. That is the trade. The agent keeps working with a light window, but any detail that did not make the summary is gone unless it was written down somewhere outside the conversation. Every agent power user eventually learns this the hard way, usually mid-task. (Mine involved a database column rename the summary decided was not worth mentioning.)
Memory is what survives between sessions
The fix for a disposable window is old technology. Write things down. Agents that work well across sessions keep notes outside the conversation: a spec file, a decision log, a memory store they can search next time. A fresh window plus three paragraphs of good saved context routinely beats a 400,000-token session limping along at the rot stage.
This layer is the one I spend my days on, because it is where Keep sits: a save-anything library your agents can search, so context survives the window that produced it. Whatever you use for the job, the principle holds. The window is rented. Files are owned.
Saved context has its own failure mode, which is going stale. A note that says the plan costs £39 will outlive the price change. Date what you save, record where it came from, and let current sources win arguments with old notes.
Loop engineering prompts the agent for you
Once statelessness clicks, a strange idea becomes obvious. If a fresh window plus good saved context beats a long rotted session, stop protecting the session. Restart on purpose.
Geoffrey Huntley took that to its logical extreme in mid-2025 with a technique he named Ralph, after Ralph Wiggum. It is a bash loop that feeds the same prompt file to a coding agent forever. Each pass starts a brand-new agent with a clean window. Progress lives in git and in files, never in conversation memory. Held together by, essentially, optimism, Ralph still built a working programming language, and Huntley reports one engineer delivered a $50,000 contract with it for $297 in tokens.
07 / Loop engineering
Design the loop, not the prompt
An outer loop restarts the agent with a clean window and better context each time. Progress lives in files and git, not in the conversation.
A fresh agent starts with a clean window and reads the spec.
Each pass starts clean. No rot, because nothing stale carries over.
Loop engineering is an outer circle around the agent loop: the goal and its checks go in, a fresh agent runs with a clean window, the checks run, and whatever failed becomes new context for the next run. When the checks pass, the loop exits and the work ships. Progress lives in files and git rather than in the conversation, so nothing stale carries over.
The pattern grew into a discipline. Peter Steinberger put it bluntly: “you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Addy Osmani’s essay on loop engineering describes the same move as replacing yourself as the person who prompts the agent, and quotes Claude Code’s creator Boris Cherny describing his job as writing loops.
You can see the idea shipping in the harnesses themselves. Claude Code and Codex added scheduled automations, sub-agents, and skills. Open-source harnesses like OpenCode and Pi made the loop programmable. Always-on runtimes like OpenClaw and Hermes go furthest, running agents around the clock with persistent memory, so each loop starts from what the last one learned. Every one of these is a context engineering machine. The loop decides what the next fresh window gets to see.
What to do with this
You now have the mental model that most agent advice assumes. When an agent gets stubborn or forgetful mid-session, you can usually name the cause. The window filled, rot set in, or a compaction ate the detail you needed. The remedies follow from the mechanics. Keep sessions short and focused. Write decisions into files the next session can load. Let checks, rather than vibes, decide when the loop is done.
The window is temporary. What you save is what compounds.