Lesson 34.1 split the world into the desk (context) and storage (durable memory). Now open the storage rooms. There are three main ones, and they are the same tools you already know from earlier parts of the course — files, databases, retrieval — used with a new question in mind: *what kind of remembering is this?*

File memory: rules and handoffs humans can read

File memory is durable state kept as readable documents — usually Markdown for prose and JSON for structured run state. You met both in Part II.

• Markdown holds rules, conventions, and handoffs: what the agent must always do, what it must never do, how one run hands work to the next. A RESEARCH-RULES.md ("cite page numbers; flag restated figures") or a HANDOFF-2026-09-12.md ("collected so far, next step, open questions") is memory a human can open, audit, and edit in seconds.
• JSON holds structured run state a program can load exactly: which steps are done, which IDs were collected, what the pending tool calls are. It is the baton from Lesson 34.1 in machine-readable form.

Files shine when the memory is small, human-governed, and versioned. Standing instructions, review checklists, run summaries, and cross-agent handoffs belong here. They fail when the data grows large, needs concurrent updates, or must be queried ("all briefs mentioning ticker X in August") — that is database territory.

A practical rule: if a person should review or approve the memory by reading it, make it a file. If a program should query it by the thousand, do not.

Database memory: operational facts with identity

Database memory is durable state kept as rows with keys — the Postgres world from Class 20. Each fact has an identity, a schema, and a current value: user 4821's tier, job 991's status, brief 2026-09-10's tickers and verdict.

Databases are the right home for:

• Operational records — jobs, orders, users, runs, artifacts. Anything with a lifecycle (queued → working → done) lives here, exactly as background jobs did in Class 26.
• Facts that update — a corrected revenue figure changes one row; every future run reads the corrected value. Files would need rewriting; transcripts would need pleading.
• Facts you query — "which sources did we already process this week?" is a SELECT, not a treasure hunt through chat logs.

The discipline databases enforce is the point: one current value per fact, timestamps on changes, no silent duplicates. When an agent "remembers" that a customer is on the annual plan, that memory should be a row someone owns — not a sentence buried in turn 214 of a chat.

Retrieval memory: knowledge fetched by relevance

Retrieval memory is source knowledge the agent pulls in by similarity at run time — the RAG pattern from Part VI. Filings, documentation, knowledge-base articles, past research: too much to paste, too varied to pre-select, so the agent queries and receives the passages most relevant to *this* task.

Retrieval is powerful and easy to misunderstand. It is not the agent "knowing" things. It is the agent *finding* things, freshly, each run. That means:

• It remembers the collection, not the answer. Update the source article and future runs retrieve the updated passage.
• Its quality depends on chunking, freshness, and evaluation — garbage sources retrieve garbage passages.
• It complements the other two rooms: the database says *which* brief ran; retrieval supplies the *material* the brief was built from.

How they work together: a conceptual tour

Consider a SweepsMonitor-style research operation at the concept level — no internals, just the pattern. Three memory mechanisms cooperate:

1. A knowledge base persists what was learned. Finished findings, validated summaries, and source references are stored durably so later runs build on earlier work instead of re-researching from zero. 2. Similarity memory avoids duplicate effort. Before launching fresh research, the agent checks what nearby work already exists — has this company, filing, or question been covered? Conceptually, embeddings let it ask "what do we already know that resembles this?" rather than exact keyword matching. 3. Source packets and a private daily capture keep runs grounded. Each run assembles a packet of the sources it actually used — named, timestamped, citable — and a daily capture preserves what the system saw that day. If a figure is later disputed, the team can trace the brief back to its packet instead of arguing from memory about memory.

The lesson for your own agents: durable research memory is a *system* — a persistent base, a way to find nearby knowledge, and per-run packets that prove provenance — not a longer prompt.

Choosing the room: a decision table

When in doubt, ask who governs it. Humans govern files. Programs query databases. Relevance governs retrieval.

Exercise: build a memory map for a research agent

Design memory for an agent that monitors three companies and writes a weekly brief.

1. Draw three columns — Files, Database, Retrieval — and place at least two items in each (e.g., standing citation rules; briefs table with status; filings collection). 2. For each item, write one line: what it holds, who writes it, who reads it. 3. Add one source packet convention: what each run records about the sources it used (names, dates, IDs) and where that packet is stored.

Finish line: a one-page memory map — three columns with items plus owners, and a short packet convention paragraph.

Verification: simulate a correction ("vendor restates Q2 revenue") and a fresh run. Point to exactly which store changes and which stores do not. If the correction requires editing a transcript or re-pasting history, the map is wrong.

Common failure mode: putting everything in retrieval ("the agent can just find it"). Standing rules and job statuses are not searched-for knowledge — they are load-every-time state and belong in files and rows.

Check your understanding

• Why do standing rules belong in a Markdown file rather than a retrieval collection?
• What does a database give you that a folder of handoff files does not?
• Why is a per-run source packet necessary even when the knowledge base is good?

Next

Your agent now has storage rooms. Lesson 34.3 faces the hardest room of all — memory *about the user* — and the permission and restraint it demands.