---
title: "Context Engineering: An Interactive Guide to How AI Agents Work | Keep"
description: "Learn how AI agents build and use context. The window, the loop, context rot, compaction, and memory, each explained with an interactive demo."
canonical: "https://keep.md/blog/context-engineering"
language: "en"
---

# 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.

August 10, 2026Ian 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.

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](https://platform.claude.com/docs/en/build-with-claude/context-windows), which Anthropic says is roughly 555,000 words. OpenAI’s [GPT-5.6 family of Sol, Terra, and Luna](https://openai.com/index/gpt-5-6/) holds 1.05 million. Google’s documented ceiling for [Gemini 3.1 Pro](https://deepmind.google/models/model-cards/gemini-3-1-pro/) is a million. Smaller, faster models like Claude Haiku 4.5 hold 200,000.

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](https://keep.md/tools/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.

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](https://arxiv.org/abs/2210.03629), 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.

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](https://arxiv.org/abs/2307.03172). In 2025 Chroma tested 18 models and found that [performance degrades as input grows](https://www.trychroma.com/research/context-rot) even on tasks as simple as finding a matching sentence. Anthropic’s own [context engineering guidance](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) 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.

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](https://code.claude.com/docs/en/context-window), 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.

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](https://keep.md/) 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](https://ghuntley.com/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.

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](https://x.com/steipete/status/2063697162748260627): “you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Addy Osmani’s essay on [loop engineering](https://addyosmani.com/blog/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.

## Stop re-explaining your project to every AI agent.

Automatically Keep decisions, handoffs, plans, context, and todos in one shared AI notepad that every local or cloud agent remembers.

[Start for free](https://app.keep.md/signup)

[Read the docs](https://keep.md/docs)