The context window IS the agent's memory 7 min live
b1's Thought → Action → Observation cycle has a hidden bill: every turn appends to the context window, and the window is finite. A long task grows its own history until something has to give. There are exactly two ways it gives - overflow (the task blows past the window and the run dies or degrades) and eviction (early turns get trimmed away to make room, taking early findings and standing instructions with them). Both are memory failures. Neither is a "bad model".
LiveTwo ways a context dies4 min▶
Name the failure before you fix it - same habit as the levers in b1:
- Overflow - a long task (big tool results, many turns) exceeds the window. Symptoms: API errors, truncated inputs, sudden quality cliffs late in a run. Loud, easy to spot.
- Eviction - to keep running, old turns get dropped or trimmed. Symptoms: the agent re-fetches things it already knew, contradicts its own earlier finding, or ignores an instruction given at turn 1. Quiet, easy to miss - this is the memory-off signature you will reproduce in the demo.
The standing instruction that expired. An ops team told their agent at the start of every month: "exclude refunded orders from revenue figures." Ten turns of ticket triage later, month-end numbers came out higher than finance's. Nothing crashed and no error was logged - the instruction had simply been evicted mid-run, and every later answer quietly included refunds again.
Self-studyWhy "just use a bigger window" is not the fix3 min read▶
Bigger windows delay the problem; they do not remove it. Three reasons the toolkit still matters:
- Cost and latency scale with context - every turn re-reads the whole history. A lean context is a cheaper, faster agent.
- Long tasks are unbounded - an agent that monitors tickets all day will outgrow any window eventually.
- Runs end - the window empties when the process exits. Anything the agent should know NEXT run needs long-term memory: a store, a file, a session - never the window itself.
The memory toolkit, short-term to long-term 8 min live
Every serious stack ships the same five techniques under different names. Short-term techniques manage the window inside one run; long-term techniques survive across runs. Learn the technique, and every framework's memory docs become familiar.
| Technique | What it does | Term | Where you meet it |
|---|---|---|---|
| Message trimming / filtering | Drop or truncate old turns (oldest-first, or filter big tool results) to stay under budget | Short | Raw loops · LangGraph message state helpers |
| Compaction | Summarize the history so far, replace old turns with the summary, keep going | Short | Anthropic context management · you build it below |
| Scratchpad | Agent writes findings to a file or note it re-reads every turn - findings survive eviction | Short | Anthropic memory tool pattern · self-study card |
| Sessions | Persistent conversation memory across runs - the SDK stores and replays history for you | Long | OpenAI Agents SDK "Sessions" primitive |
| Checkpointing + Store | Checkpointing persists state through failures mid-run; Store is long-term memory across threads | Long | LangGraph · Academy modules 2 and 5 |
LiveCompaction by hand6 min▶
Compaction is one extra API call: when the estimated token count crosses a threshold, ask the model to summarize the history - keeping every number, finding and standing instruction - then replace the old turns with that summary and continue. Bolt this onto your b2 loop:
from anthropic import Anthropic
client = Anthropic()
THRESHOLD = 8000 # rough token budget before we compact
def estimate_tokens(messages):
return sum(len(str(m["content"])) for m in messages) // 4
def maybe_compact(messages):
if estimate_tokens(messages) < THRESHOLD:
return messages
transcript = "\n".join(f"{m['role']}: {m['content']}" for m in messages[:-4])
summary = client.messages.create(
model="claude-opus-5",
max_tokens=500,
messages=[{"role": "user", "content":
"Summarize this agent transcript for the agent itself. "
"Keep EVERY number, finding, and standing instruction:\n\n"
+ transcript}],
).content[0].text
return ([{"role": "user",
"content": "[Summary of earlier turns]\n" + summary}]
+ messages[-4:]) # keep the freshest turns verbatim
The summarize-then-continue trade: you spend one call and lose verbatim detail, but the numbers, findings and instructions travel forward instead of falling off the edge. The summary prompt is the whole game - "keep every standing instruction" is what saves "exclude refunds".
Self-studyScratchpad pattern4 min read▶
A scratchpad moves key findings OUT of the message history entirely. The agent appends findings to a notes list (or a file), and the loop injects the notes into the system prompt every turn - so even aggressive trimming cannot evict them:
notes = [] # lives OUTSIDE messages - trimming cannot touch it
def remember(finding):
notes.append(finding) # e.g. "Feb completed revenue = $271"
def system_prompt():
return (BASE_PROMPT
+ "\n\nScratchpad - re-read before every step:\n"
+ "\n".join("- " + n for n in notes))
# in the loop: expose remember() as a tool, and rebuild
# the system prompt from notes on every messages.create call
Expose remember as a tool and the agent decides what is worth keeping - the same move Anthropic's memory tool and file-based agent memory make. Write one note per confirmed finding, not per raw tool result, or the scratchpad becomes a second overflowing context.
Watch the agent lose its own finding ★ 10 min · everyone runs it
The founder asks: "Diagnose the March dip." Below, the Daybreak Ops Agent runs that task with tools and planning on but memory OFF. Step through slowly: it fetches February correctly - $271 - then, at the synthesis step, the figure is gone and the agent contradicts the very step it just ran. That is the memory-off signature: the agent argues with its own earlier finding.
Step through with memory off. Find the step where query_sales("2026-02") returns $271 - the fetch itself is perfect.
Keep stepping to the synthesis. The February figure has been evicted, and the conclusion contradicts the step you just watched. No error, no apology.
Toggle Memory on and step through again. Same task, same tools - now the synthesis holds onto $271 → $150 all the way to the answer.
Say the diagnosis out loud: not a model problem, not a tools problem - a memory problem. Name the lever first.
Rung 2 on the ladder: 5/12 becomes 7/12 ★ 6 min · explore
Back to the 12-task scorecard from b1. Tools alone scored 5/12. Turn memory on with it and the score climbs to exactly 7/12 - rung 2 of the course ladder (1 → 5 → 7 → 10 → 12). Read WHICH two tasks flipped and why they are both memory-shaped.
Check the score reads 7/12 with tools + memory on. Two tasks flipped from red to ✓ versus b2's rung.
Flipped task 1: the February-vs-March comparison - a multi-step task where the first fetch must survive until the second one lands.
Flipped task 2: the standing exclude-refunds instruction - a rule given once, early, that must still bind many turns later.
Read the failure text on the tasks still red: diagnoses and reports need planning (b5); the outward-acting ones need guardrails (b7).
Try it yourself - this week ◐ 25-35 min total
- Implement the compaction threshold in your b2 loop: add
maybe_compactbefore everymessages.createcall, set the threshold low (even 2000) so you can watch it fire, and print the summary it produces. - Torture-test a standing instruction: give the agent "always exclude refunds" at turn 1, then feed it 10 filler turns of unrelated lookups, then ask for March revenue. Does the instruction survive? Try with trimming only, then with compaction.
- Write one scratchpad entry format for the dip diagnosis - one line per confirmed finding (for example "Feb completed revenue = $271", "1 March refund: order 1017"). Decide what does NOT belong in it.
- Skim LangChain Academy module 5 (long-term memory) and map each concept to tonight's table: which are window techniques, which are stores?
Official sources covered
This session teaches the working core of the memory and context-management guidance across the major agent stacks. Certificates, videos, and graded assessments stay on the official sites (linked each session). This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Mid-task, the agent's final answer contradicts a number it fetched correctly three steps earlier. Which lever was off?
Contradicting your own earlier finding is the memory-off signature. Tools-off invents numbers that were never in any result; planning-off stops after one shallow call. The fetch was real - keeping it was the failure.
2 · What exactly is compaction?
Compaction is summarize-then-continue: one extra model call that carries numbers, findings and standing instructions forward in condensed form. Plain deletion of old messages is trimming - cheaper, but it is exactly how "exclude refunds" gets lost.
3 · Where does the short-term vs long-term memory line actually sit?
The window empties when the run ends - trimming, compaction and scratchpads all manage life inside one run. Anything the agent must know next run needs a store: OpenAI SDK Sessions, LangGraph Store, or your own file.