Lessons 34.1 through 34.3 built the stores and the permission model. Now the unglamorous part that decides whether any of it works six months from now: maintenance. Memory without maintenance becomes a attic — full, stale, and faintly hazardous. This lesson gives you the caretaking routines.

Freshness starts with timestamps

Every durable memory item needs to answer "how old is this and is it still true?" That requires, at minimum:

• Source timestamp — when the underlying fact was true (filing date, price as of, preference set on).
• Stored timestamp — when your system captured it.
• Expiry or review date — when it must be re-checked, refreshed, or dropped. Prices expire in minutes; standing citation rules survive years; a user's "traveling this month" preference dies at month's end.

Without these, retrieval happily serves last year's price with this year's confidence, and run state from a crashed Tuesday run resumes as if nothing changed. Timestamping is the cheapest reliability upgrade in the whole memory system — and it is the direct application of the Data freshness thinking from Part VI: every dataset, including memory, has a half-life.

Archive versus delete: forgetting on purpose

Not all forgetting is equal. Teach two operations and use them deliberately:

• Archive means the item leaves active memory but remains findable for audit, debugging, or history. Old briefs, superseded rules, last quarter's handoffs. Archived items are excluded from context and retrieval by default but can be cited when provenance matters ("what did we believe in March, and why?").
• Delete means the item is gone — from active stores, retrieval indexes, and backups on their schedule — subject to any audit record the policy requires. User-deleted preferences, expired credentials, retracted data, anything kept past consent.

The failure modes are symmetric. Teams that never delete accumulate stale, sensitive ballast that leaks into retrieval and handoffs. Teams that delete instead of archiving destroy the trail they need when a decision is disputed. The rule: archive history, delete liability. If the future might need to know *that it existed*, archive. If keeping it creates risk without value, delete — and record the deletion itself.

Summary refresh and retrieval evaluation

Two routines keep the remaining memory honest:

Summary refresh. Long-lived state gets periodically rewritten from current truth rather than patched forever. A weekly job (or a maintenance run) rebuilds the standing summary — open items, current figures, active preferences — from the database rows and current files, discarding accumulated cruft. Think of it as the compact-and-replace discipline from Lesson 34.1, scheduled. Refresh cadence follows consequence: nightly for operational state, quarterly for standing knowledge.

Retrieval evaluation. A retrieval collection is a living index, and indexes rot: sources go stale, chunking choices age, duplicates creep in. Periodically run a fixed set of probe queries with known-good answers and check whether the right passages still come back. If recall slips, the problem is the collection — not the model — and the fix is re-chunking, expiring sources, or rewriting the thin articles nobody retrieves. This is the same eval-set instinct Part IX will formalize; start it here for memory.

Both routines belong under Infrastructure monitoring (Part VII thinking): maintenance is a scheduled job with logs, alerts, and an owner — not a hope.

Handoffs: memory that travels between runs

A run handoff is the baton one execution passes to the next: what was collected, what was decided, what remains, what to watch. Good handoffs are small, structured, and boring:

Run: nightly-brief 2026-09-12
Collected: Q3 filings for tickers A, B (packet #441); macro series v18
Decided: lead with accounting-change flag on ticker B
Remaining: ticker C filing delayed — retry at 06:00
Watch: vendor restatement rumor on ticker A (unconfirmed)
Next action: resume with packet #441 + retry C

Write handoffs to files (readable) backed by rows (queryable): the Markdown note for humans, the job row's status fields for programs. Each handoff names its inputs by reference — packet IDs, row IDs, file versions — so the next run loads exactly those rather than re-deriving the world from a transcript. And each handoff expires: a "retry at 06:00" instruction is garbage by noon, and the maintenance rules should say so.

Later, Project Control (Part X) will govern who approves changes to standing memory and how releases roll out. Anticipate it now: standing rules files and preference schemas change through review, not silent self-edits. Lesson 34.5 makes that loop explicit.

Exercise: create AGENT-MEMORY.md

For one agent, write an AGENT-MEMORY.md with one row per memory type. Required columns: type, owner, update trigger, retention, verification method.

Adapt the rows to your agent, but keep all five columns — a memory item without an owner rots, one without a trigger goes stale, one without retention accumulates, and one without verification is a rumor.

Finish line: a committed AGENT-MEMORY.md with every memory type your agent uses, all five columns filled.

Verification: pick any row and simulate its trigger (a restatement, a user edit, a new run). Walk the update path: who acts, which store changes, what expires, how you confirm. If any step is "someone remembers to," assign the owner or the job that does it.

Common failure mode: listing stores without triggers — a beautiful inventory nobody maintains. Every row needs a *when* that fires without heroics.

Check your understanding

• Why does a memory item need both a source timestamp and a stored timestamp?
• When do you archive, and when do you delete? Give one example of each.
• What breaks when a handoff references "last Tuesday's chat" instead of packet and row IDs?

Next

Your memory now has a caretaker's schedule. Lesson 34.5 closes the class with the slowest, most powerful loop of all: how the agent *gets better* over time without quietly rewriting its own rules.