Agent memory is a governance problem before it is a database decision

The opening claim. Anders Swanson, an Oracle developer advocate, says what teams using coding agents see daily: context windows are not memory. An agent can run a session, reproduce a failure, synthesize a procedure, then lose it all. The next agent repeats the work and the same wrong turns. Larger contexts and scratchpad files bury useful signal in noise. Memory only begins when experience becomes managed state.

The pattern. Swanson outlines a memory loop: formation, recall, consolidation, and evaluation. Memories are typed objects, split into episodic, semantic, procedural, and working state. The storage schema combines a primary key, text, tags, vector embeddings, full-text index, graph links, temporal validity, and audit events. Retrieval is hybrid, merging vector similarity, lexical search, relational entities, graph traversal, and recency into a scored context card. That is a coherent architecture, and the database-centric framing is plausible for teams that already need persistence.

The governance gap. The strongest material is about what can go wrong: stale memories after tooling changes, conflicts between instructions, over-recall crowding the context card, silent drift as memory grows, data leakage, and poisoned memory from prompt injection. His advice is concrete: redact secrets and PII before writing, scope memories to agents, workflows, teams, and users, and require admin review and suppression. Agent memory without governance is a liability.

The vendor tell. Swanson works for Oracle and the talk ends with a push toward Oracle's multi-model database, Python SDK, and developer hub. He presents no production benchmarks, no customer success metrics, and no comparison against alternatives. The conceptual pattern is useful, but the evidence is architecture opinion from someone selling the storage layer. Teams should separate the pattern from the particular product pitch.

The adoption trade-off. There is real cost in building memory: redaction pipelines, embedding jobs, graph links, temporal logic, feedback scoring, and admin tooling. A small team using Claude Code or Codex is probably better served by a thin persistence layer or manual context notes until the pattern is proven. The talk is aimed at larger, multi-tenant environments where file-based scratchpads and grep genuinely break down. That is where memory becomes a database problem rather than a prompt engineering problem.

What is missing. No one in this talk shows a working memory system in production. The hardest parts, deciding what deserves memory, how to measure recall quality, and how to prevent contradictory facts, are described at a high level. The strongest line is that feedback closes the loop; without evaluation, memory decays. Watch for production write-ups and benchmarks from teams actually shipping this. Until then, treat this as a design pattern worth assessing, not a proven solution.