Class 33 gave you teams of agents with roles, handoffs, and contracts. Now comes the question every one of those agents faces on its second run: what does it still know? A new chat starts blank. A durable agent does not — but only because somebody designed what persists, where it lives, and how it gets loaded back.

This lesson draws the line that makes the rest of the class possible: the current conversation is working space, not storage.

The conversation is a desk, not a filing cabinet

Think of the model's context — everything handed to it for this one turn — as the top of a desk. The current user message sits there. So do the recent messages, the retrieved passages, the tool results, and the instructions you packed in. The agent can see all of it and reason over it. That is its power, and its limit.

Three facts about that desk:

1. It is temporary. Close the session, start a new run, hit the token budget — the desk gets cleared or the oldest papers slide off. Nothing on it is promised to survive. 2. It is expensive. Every token on the desk costs money and attention on every single turn. A transcript that grows forever makes each step slower, pricier, and worse at finding the point. Long context degrades focus; you met this in Class 9 on tokens and context windows. 3. It is unselective. A raw transcript keeps the wrong things at equal weight: the typo, the abandoned idea, the corrected mistake, the lunch order. An agent that re-reads all of that every turn is not remembering — it is rummaging.

Durable memory is everything outside the desk that a future turn or run can deliberately load back: a file, a database row, a retrieval collection, a saved run state, a user-approved preference. Memory answers a different question than context. Context asks "what am I looking at right now?" Memory asks "what did we decide to keep, and how do I fetch exactly that?"

The five places durable memory lives

When people say "the agent remembers," they usually mean one of these:

Notice what is missing from that table: "the whole chat log." A transcript can be *archived* — stored as a record — but it becomes memory only when something extracts the durable part (a decision, a fact, a preference) and writes it to one of these homes with a name, an owner, and a reason.

Why agents need compact, current state

An agent in a loop (Class 30) faces a compounding problem. Each turn appends messages and tool outputs. By turn forty, the desk holds forty turns of history — including three wrong turns the agent already corrected. The model now spends its budget re-reading its own mistakes and is more likely to repeat them. Operators call this context rot: the state the agent reasons over gets staler and noisier the longer the run goes.

The fix is a discipline, not a bigger window:

• Compact. After each phase, the agent (or the orchestrator) writes down the *current state* in a few lines: what is decided, what is collected, what remains. That summary goes forward; the raw chatter stays behind.
• Current. State gets refreshed when facts change. "Waiting on filing Q3" becomes "Q3 filing fetched, 14 pages" — the old line is replaced, not appended to forever.
• Loaded on purpose. Each new turn or run reads exactly the state it needs — the handoff file, the job row, the retrieved passages — instead of inheriting everything that ever happened.

A useful image: a relay runner does not carry the whole race history. They carry the baton — position, lap, next handoff. Your agent's durable memory is the baton.

Worked example: the research agent's three piles

Mara runs a nightly research agent that watches a sector and drafts a morning brief. Early on she pasted the entire previous day's chat into each new run. Costs climbed, and the brief started repeating Tuesday's corrected error on Thursday.

She redesigned around three piles:

• Must know now (context): today's task instruction, the three tickers under review, this morning's fetched prices, the brief template. This fits on the desk and changes every run.
• Must remember later (durable memory): the standing rules file ("always cite filing page numbers; never invent quotes"), the Postgres table of past briefs with dates and tickers, the user preference ("flag accounting changes explicitly"). These persist across runs and load by reference.
• Must retrieve when relevant (retrieval): last quarter's filings, the macro series, the knowledge-base articles. Nobody pastes these in advance; the agent queries for the passages matching today's tickers.

One incident proved the design. A data vendor corrected a revenue figure mid-week. Mara updated one database row and one standing note. Thursday's run loaded the corrected fact automatically — no transcript surgery, no "remember that I told you last Tuesday" pleading. The transcript of Tuesday still exists in the archive, but the *memory* is the corrected row.

Exercise: the three-pile split

Pick one agent you care about — real or planned. A support bot, a research summarizer, a review helper.

1. Must know now: list the 3–6 items that belong in context for a single run (task, inputs, today's tool results, output format). 2. Must remember later: list what must survive between runs, and name where each item lives (file, database row, saved preference — be specific). 3. Must retrieve when relevant: list what should stay in storage until a query earns it a place on the desk.

Finish line: a one-page doc with the three headed lists, each item annotated with its home ("context," plus the file/table/collection name for anything durable).

Verification: cover the "must know now" list and ask: could a fresh session reconstruct the run from the durable homes plus a new task message? If anything essential exists only in an old transcript, it is misfiled — move it.

Common failure mode: filing everything as "must know now" and pasting last week's log into every prompt. If the list grows each run, you built context, not memory.

Check your understanding

• Why does re-reading a full transcript each turn get more expensive *and* less accurate over time?
• Name the five homes of durable memory and one example of each.
• What is the difference between archiving a transcript and remembering a fact from it?

Next

You can now tell working space from storage. Lesson 34.2 opens the storage rooms one by one — files, databases, and retrieval — and shows which kind of remembering each one is good at.