Day 3 · Lesson 1 — Context Engineering: Sessions & Memory
Every turn, the whole context is rebuilt from scratch.
Day 1 named the six types of context. Day 3 shows the machinery: because an LLM is stateless, the entire context is assembled fresh for every turn, and two engines do the assembling. Get this loop right and the agent remembers and personalises; get it wrong and it drowns in its own history.
From Day 1 L4: context that's loaded on every call, regardless of relevance, is —
Static, always present, always billed. Day 3 is about the dynamic side: what gets fetched and assembled anew each turn, and the two systems that manage it.
An LLM retains nothing between calls; its whole awareness is the context window of a single request. So context engineering is the dynamic assembly and management of that window for every turn — an evolution beyond static prompt engineering.1 The paper's image: it's the mise en place for an agent, gathering exactly the right ingredients before cooking, "no more and no less than the most relevant information."
Concretely, each turn runs a four-step loop:1
1. FETCH pull memories, RAG docs, recent events (using the query)
2. PREPARE assemble the full prompt — BLOCKING, on the hot path
3. INVOKE call the LLM + tools; append their output to context
4. UPLOAD persist what's new — usually in the BACKGROUND, off the hot pathSteps 2 and 4 hold the key tension of the whole day: preparing context is blocking (the user waits), so it must be fast; uploading/consolidating is expensive, so it runs in the background after the reply is sent.
The loop is driven by two components with a symbiotic relationship:1
You don't shove the messy desk into storage. You review it, discard the drafts, and file only the finalised documents. That review step (session → memory) is the engine of everything in Lessons 2–5.
The instinct is "big context window, just stuff it all in." The paper names the reason it fails: context rot. As context grows, the model's ability to attend to critical information diminishes, on top of rising cost and latency.1 More tokens doesn't buy more intelligence; past a point it just adds noise. So context engineering is active curation (summarise, prune, compact) rather than accumulation. The savvy traveller packs only what they need.
This is Day 1 L4 with its sleeves rolled up. The static/dynamic split becomes: static = the system prompt scaffold; dynamic = whatever this loop fetches per turn. And context rot is the reliability face of the same token economics from Day 1 L6: bloated context costs money and quality.
Context is the agent's entire reality for a turn, so whatever you inject becomes ground truth to the model. That's power and exposure at once: a memory or retrieved document placed in context is trusted implicitly. Hold that thought. It's why memory that's poisoned or leaked across users (Lessons 4–5) is a V Validation and C Compliance problem, not just a quality one. The assembly step is a trust boundary.
Stop equating "bigger context" with "better." Treat every turn's payload as something you curate: fetch what's relevant, compact the rest. Context rot is real, and it's on you.
Make the assembly loop explicit in your architecture: what's fetched, what blocks, what runs in the background. A shared diagram of "how context gets built each turn" prevents a lot of mystery bugs.
Session and memory are infrastructure, not app code: managed stores with latency budgets and retention policies. Decide to buy or build that substrate before agents scale.
Recall, don't re-read.
Why must an LLM's context be assembled fresh every turn?
Statelessness: outside training data, the model knows only what's in this call's window. Persistence lives outside the model, in sessions and memory.
"Context rot" means that as context grows —
Bigger isn't better past a point: attention to critical information degrades, and cost and latency rise. Curate, don't accumulate.
In the per-turn loop, which step usually runs in the background?
Uploading and memory consolidation are expensive, so they run after the reply is sent. Preparing context is blocking; it's on the hot path and must be fast.
For one agent you run, trace the four steps: what does it fetch, what blocks the user, and does anything run in the background? If "upload/consolidate" is missing, your agent has a workbench but no filing cabinet. It forgets everything the moment the session ends.
Milam, Gulli & Nawalgaria, Context Engineering: Sessions, Memory (Day 3) is the source for the whole day; the RAG overview and long-context docs give the surrounding mechanics.
Up next → Day 3 · Lesson 2: Sessions, The Workbench. Events and state, why a stateless runtime must persist history, how to compact long conversations before they rot, and the isolation + PII rules that make a session safe.
Related: Day 1 L4: static/dynamic context · Glossary · Course home