Context Engineering: Spending Finite Attention Where It Counts · Lesson 1 of 6

Lesson 1: From Prompt Engineering to Context Engineering

Learning goals:

Restate the definitions of prompt engineering and context engineering, and say why the two are an "evolution" rather than a "replacement"

Use the two ideas of "attention budget" and "context rot" to explain to a colleague what's wrong with "the window's big enough, so stuff everything in"

Point to the places in the harness loop you built in this series' course "Agent Harness Fundamentals: Loops and Control" where context only grows and never shrinks

Prerequisites: You've finished this series' course "Agent Harness Fundamentals: Loops and Control" and have a working stop_reason-driven loop on hand | Next: Lesson 2 >>

A Familiar Scene: Every Turn of the Loop, the Window Gets Heavier

In this series' course "Agent Harness Fundamentals: Loops and Control," you hand-wrote a loop like this (simplified; the four control valves — max turns, budget, and the rest — are left out for now):

JAVASCRIPT

let response = await client.messages.create({
  model: MODEL, max_tokens: 1024, tools, messages, // keep your eye on the messages array
});

while (response.stop_reason === "tool_use") {
  messages.push({ role: "assistant", content: response.content });

  const toolResults = await runToolUses(response.content, toolImpls);
  messages.push({ role: "user", content: toolResults }); // tool results come in too

  response = await client.messages.create({
    model: MODEL, max_tokens: 1024, tools, messages,
  });
}

Back then all our attention was on control flow: how to read stop_reason, how to install the control valves. Now change the angle and stare at the messages array — it only ever gets pushed to, never trimmed. Every turn, at least two things come in: the model's reply for this turn (with its tool_use blocks), and the results the tools return. That second kind is often the bulk of it: picture a single list_files bringing back a few hundred filenames, or a log search bringing back tens of KB of raw text. From that point on they sit in the window forever, re-read from scratch on every round of reasoning.

This isn't a slip in your implementation; it's the nature of an agent. "An agent running in a loop generates more and more data that could be relevant for the next turn of inference"¹, and because it holds the autonomy, it may keep going for a great many turns². In this series' course "Prompt Engineering Basics: How to Write Effective Instructions" you learned how to write a single instruction clearly — but however well an instruction is written, it's still just one small block inside the window. What actually decides how the agent performs on turn 40 is everything that happens to be sitting in the whole window at that moment.

Two Definitions: From "Write One Good Sentence" to "Manage the Whole Window"

Formalize that observation and you get two definitions.

Prompt engineering: "Prompt engineering refers to methods for writing and organizing LLM instructions for optimal outcomes"¹. The question it answers is: "How should I write and arrange this instruction for the best effect?"

Context engineering: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference"¹. The question it answers is: "For this round of reasoning, which tokens should be in the window, and which shouldn't?"

Notice the lift in perspective. The first is a one-time writing problem — write it once and it's set. The second is a tradeoff you have to re-answer on every turn of the loop. Anthropic explicitly frames context engineering as the natural progression of prompt engineering — "we view context engineering as the natural progression of prompt engineering"¹ — so the skill you built up in this series' course "Prompt Engineering Basics: How to Write Effective Instructions" isn't wasted at all. It becomes a subset of a bigger problem: the system prompt still has to be written well, but it's only one of the many context ingredients you now have to manage.

The community has more aggressive takes. A 2026 agent-engineering roadmap asserts "Prompt engineering is dead as a standalone skill in 2026."³ Note that this is that roadmap's opinionated call, and this lesson doesn't treat it as consensus — Anthropic's phrasing is far more measured: evolution, not replacement¹. That said, the one-line definition the same roadmap gives context engineering is worth keeping: "deciding what tokens are in front of the model at every step of the loop"³. And the same roadmap puts its finger on how much the harness matters: "Same model, different harness, completely different result."³ — something you should already feel in your gut from the experiments in this series' course "Agent Harness Fundamentals: Loops and Control."

Attention Budget: Every New Token Runs Up the Tab

Why is this something you have to manage? Isn't a bigger window just free rein? That brings us to the first physical fact.

"LLMs have an "attention budget" that they draw on when parsing large volumes of context"¹. The catch is that this budget is finite: "Every new token introduced depletes this budget by some amount"¹.

Here's an analogy. Window capacity is the floor area of a warehouse; the attention budget is the crew you send in to find the goods. Expand the warehouse tenfold and the crew doesn't grow with it — the fuller the shelves, the harder it is to dig out the one item you actually want. Slipping one more "just in case" document into the window isn't a free backup; it's a real charge against the budget, paid out to cover the cost of reading it and ruling it out.

Flip to this view and a lot of habits deserve a second look. "The window can hold it, so let's just paste in the entire API doc" — holding it is a warehouse question, reading it well is a budget question, and the two aren't the same thing.

Context Rot: A Gentle Slope, Not a Cliff

The macro consequence of a budget being drained continuously has a vivid name: context rot — "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases"¹.

Two details that are easy to get wrong, pinned down here:

First, it's gradual, not a sudden drop. This degradation shows up as a performance slope — "These factors create a performance gradient rather than a hard cliff"¹ — not a hard cliff where things suddenly stop working past some token count. So you'll never get an error; the agent just gets slowly duller. In everyday terms (this is the typical shape it takes in engineering experience, not an enumeration from the source): conventions confirmed earlier start getting forgotten, files already read get read again, bugs already fixed get reverted. Degradation with no alarm is harder to track down than an error.

Second, it's a general rule, not one model's quirk. Some models degrade more gently than others, but "some models exhibit more gentle degradation than others, this characteristic emerges across all models"¹. Switching to a stronger model can postpone the problem; it can't cancel it.

Put those two together and you have this lesson's first cornerstone: "context, therefore, must be treated as a finite resource with diminishing marginal returns"¹. The thousandth token you stuff into the window and the hundred-thousandth take up the same amount of room, but they're worlds apart in the value they add. The "more is safer" instinct has the direction exactly backwards — every extra bit of "insurance" you cram in dilutes the model's attention on the information that actually matters.

Use attention budget to test the "stuff everything in for safety" instinct

A colleague sees you weighing what to put in the window each turn and tells you: "The model window is 200K tokens. Just stuff in the project docs, the full conversation history, and all the tool descriptions — having all the information is safer than missing any." Which judgment is right?

Back to Agents: Why This Is the Foundation, Not Icing

In a single-turn Q&A, you might not even notice context rot — the window gets used once and discarded, and the token count usually doesn't reach the danger zone. Agents turn this problem from "occasionally encountered" to "getting worse every turn": data in the loop only grows and never shrinks¹, and agents may autonomously run for many turns². Look back at the opening code — that messages array that only takes push and never gives anything back is this process made concrete.

On-the-ground engineering experience lines up completely. The official Claude Code docs state that "Claude's context window fills up fast, and performance degrades as it fills."⁴ They call the context window "the most important resource to manage."⁴ The same docs also have an observation worth copying down: "A clean session with a better prompt almost always outperforms a long session with accumulated corrections."⁴ — "talked longer" doesn't mean "talked better," and every correction piled up, every tangent wandered down, is still sitting in the window taking part in the next round of reasoning.

So here's an accurate position for context engineering: it's not polish you add in the tuning phase; it's the foundation of agent reliability. The four control valves in this series' course "Agent Harness Fundamentals: Loops and Control" manage "don't let the loop run away"; this course installs another set of mechanisms — "don't let the window rot." Put both sets together and your harness is actually ready to be trusted with long tasks.

This Course's Roadmap

For long-horizon tasks, Anthropic summarizes three classes of techniques — "compaction, structured note-taking, and multi-agent architectures," aimed at helping agents "maintain coherence, context, and goal-directed behavior over sequences of actions"¹. This course follows that path:

Lesson 2 dissects the window: system prompt, tool definitions, examples — how much room does each take, and how do you write them without waste.
Lesson 3 covers just-in-time retrieval: instead of stuffing all the material in ahead of time, give the agent lightweight identifiers and let it go look things up on demand.
Lesson 4 covers compaction and notes: when the window approaches the limit, how to summarize and restart, and how to record key information outside the window.
Lesson 5 covers sub-agents and context isolation: send the messy exploratory work to a sub-agent with a clean window, and only pull back the distilled conclusion.
Lesson 6 returns to your own harness and installs these mechanisms one by one.

One last reminder about proportion. Every one of these mechanisms adds complexity, and Anthropic's engineering guidance says "you should consider adding complexity only when it demonstrably improves outcomes."² So every lesson ahead explains "when is it worth doing" before it explains "how to do it" — not every agent needs sub-agents, and not every task is worth compacting.

Recap

Context engineering is the natural progression of prompt engineering: the first manages "which optimal token set to maintain in the window at reasoning time," the second manages "how to write and organize instructions," and the perspective lifts from one sentence to the whole window¹.
"Prompt engineering is dead as a standalone skill" is an opinionated assertion from a community roadmap³; this lesson uses the more measured phrasing — evolution, not replacement¹.
LLMs parse context using a finite attention budget, and every new token consumes some of it¹ — "the window can hold it" and "the model can use it well" are two different things.
Context rot is a gradual performance slope rather than a cliff, steeper on some models and gentler on others but the trend appears across all models¹, so it doesn't error out; it just quietly makes the agent duller.
Context is a finite resource with diminishing marginal returns¹; data in the agent loop only grows and never shrinks¹, which is why the official Claude Code docs call the context window "the most important resource to manage."⁴
The three classes of techniques for long-horizon tasks — compaction, structured note-taking, and multi-agent architectures¹ — correspond to the main threads of Lessons 4 and 5; Lesson 6 installs them into your harness. Before introducing any complexity, confirm it actually improves outcomes².

>> Lesson 2: Anatomy of Context: System Prompt, Tools, and Examples

Effective context engineering for AI agents — Anthropic Engineering — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴
The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) — https://github.com/codejunkie99/agent-roadmap-2026 ↩ ↩² ↩³ ↩⁴
Best practices for Claude Code — Claude Code Docs — https://code.claude.com/docs/en/best-practices ↩ ↩² ↩³ ↩⁴

Exercises

Six practices are listed below. Which mainly belong to prompt engineering (focused on "how to write and organize the instruction itself"), and which mainly belong to context engineering (focused on "which tokens to maintain in the window on each round of reasoning")? Classify each one and write a one-sentence rationale for each.

Level 1: Sort Six Practices Into Two Drawers

Rewrite the system prompt from "you are an assistant" to a specific description of responsibilities and boundaries
Every turn of the harness, replace tool results from three turns ago with a one-line summary
Add an "input looks like this, output looks like that" example to the task instruction
Given a 500-page product manual, only give the model the table of contents and file paths, and let it look things up when needed
Change "be concise" in the instruction to "reply in no more than three sentences"
When the session reaches turn 40, compress the full history into a summary and use it to restart with a fresh window

Done criteria · checked locally

Provides a clear criterion for the judgment: does this practice change "the quality of some instruction text," or "the entry and exit and retention of the token set in the window" — rather than slapping on labels by feelClassification matches the reference answer (1, 3, 5 are prompt engineering2, 4, 6 are context engineering), or for disputed items, gives a self-consistent argument based on the stated criterionCan use the ideas of attention budget or finite resource to explain why the context engineering category is not optional in multi-turn agent scenarios

Without calling a real model, write a standalone script that simulates the loop from this series' course "Agent Harness Fundamentals: Loops and Control" running for 20 turns: each turn, append a simulated assistant message (assume 200 characters) and a simulated tool result (assume 3000 characters) to messages, and print the cumulative character count turn by turn. Then add a switch: keep only the most recent 5 turns' worth of tool results (move older ones out of the list), and run it again. Answer two questions: what trend does the cumulative count show in each of the two modes? What does the difference say?

Level 2: Install a Minimal Observation Gauge on the Loop

Done criteria · checked locally

The script runs independently and outputs the cumulative count turn by turnthe "keep everything" mode shows linear growth, confirming "data in the loop only grows and never shrinks"The "keep only the most recent 5 turns of tool results" mode clearly slows its growth rate from turn 6 onward (the tool results cap out, leaving only the assistant messages slowly accumulating), and can point out that the difference comes entirely from trimming tool resultsCan connect the observation to this lesson's ideas: unmanaged linear growth continuously drains the finite attention budget, so the content to trim first is "largest in size and shortest in usefulness"

Lesson 1: From Prompt Engineering to Context Engineering

A Familiar Scene: Every Turn of the Loop, the Window Gets Heavier

Two Definitions: From "Write One Good Sentence" to "Manage the Whole Window"

Attention Budget: Every New Token Runs Up the Tab

Context Rot: A Gentle Slope, Not a Cliff

Back to Agents: Why This Is the Foundation, Not Icing

This Course's Roadmap

Recap

Footnotes

Exercises