Agent Memory Patterns
Memory turns repeated agent work into compounding system behavior. The pattern is extract, consolidate, store, retrieve, and act.
Short-term memory is the live context window. Long-term memory is everything durable enough to survive a new session: wiki pages, logs, skills, rules, project docs, and structured stores. The important design question is not "can the agent remember?" It is "what kind of memory is this, and who owns the write path?"
Three Memory Types
| Type | Meaning | Kevin-stack examples |
|---|---|---|
| Semantic | durable facts and synthesized knowledge | wiki compiled truth, project pages, tool pages |
| Episodic | records of specific events | timelines, wiki/log.md, activity logs, transcripts |
| Procedural | how to do work | skills, workflows, rules, doctors, automation prompts |
Confusing these types causes rot. A timeline entry should not overwrite compiled truth by itself. A one-off chat note should not become a rule. A useful procedure should not sit as trivia on a project page.
The @trq212 implementation-notes.html prompt is a live hybrid of episodic and procedural memory: while the agent implements a spec, it keeps a running note of ambiguous decisions, necessary deviations, tradeoffs, and anything the human should know. That gives the model permission to make local decisions without hiding them, and it gives the next reviewer a durable diff between the requested spec and the system that actually emerged. Source: X/@trq212, 2026-05-18
Production Memory Pipeline
The hard part is consolidation. Appending everything is easy and bad. Good memory updates the existing page, merges aliases, preserves evidence in timelines, and changes the compiled truth only when the evidence justifies it.
Wiki Mapping
Kevin's wiki is a deliberately human-readable memory system:
- Compiled truth = semantic memory.
- Timeline = episodic memory.
- Skills and workflows = procedural memory.
- Frontmatter and aliases = identity resolution.
- Backlinks and related fields = graph memory.
- qmd = retrieval.
- doctor and routing evals = memory integrity checks.
This design trades automation glamor for inspectability. A vector store can retrieve facts, but a wiki page can explain why the fact matters and how it changed over time.
Runtime Memory Boundary
Kevin's agent stack now separates memory by authority:
- qmd/Kevin-Wiki owns durable compiled truth.
- Hindsight owns Hermes runtime recall and graph-shaped reflection.
- Honcho owns profile/user/peer modeling.
- Graphify owns repo topology and affected-path reasoning.
- Agent docs own project-local working facts and procedures.
The pattern: retrieve from the narrowest memory lane, verify at the source when the answer matters, then write back any reusable lesson to the durable layer. Runtime memory can suggest; the wiki, skill tree, automation files, config, and project docs decide.
Write Discipline
Agents should write memory when:
- Kevin asks to remember, ingest, add, compile, or update.
- A repeated workflow appears.
- A decision, postmortem, or contradiction emerges.
- A project/tool/person page is stale after new evidence.
- A skill or rule would prevent future recurrence.
Agents should not write memory for transient task state, guesses, or unverified external claims.
Retrieval Discipline
Before answering from memory:
- Search qmd or
_index.md. - Read the likely page plus backlinks/related pages.
- Follow only high-signal links.
- If current facts might have changed, verify against primary sources.
- File the reusable synthesis back to the wiki.
Why Structured Memory Beats Giant Context
Stuffing all history into a large context is expensive, slow, and noisy. Structured memory lets the agent select the right unit at the right time and preserve contradictions instead of blending them into soup. The goal is not perfect recall. The goal is useful, current, inspectable memory.
Memory As A Data System
The 2026 paper Are We Ready For An Agent-Native Memory System? sharpens this page's thesis: agent memory should be evaluated as a data system, not a magic context appendage. Its module split is a useful checklist for Kevin's wiki and any product memory layer:
| Module | Wiki equivalent |
|---|---|
| Representation and storage | markdown pages, frontmatter, aliases, qmd index, backlinks |
| Extraction | ingest scripts, bookmark enrichment, transcript mining, source compilation |
| Retrieval and routing | qmd search, _index.md, active-stack/router pages, related links |
| Maintenance | doctor checks, timeline/compiled-truth separation, stale-source checks, dedup/merge protocol |
The paper's most useful operational claim is that architecture should match the workload bottleneck. A memory system for exact tool names needs keyword and alias discipline; one for fuzzy project recollection needs semantic retrieval; one for evolving facts needs update correctness and maintenance policy. Source: arXiv 2606.24775v1, 2026-06-23
Memory Is Still A Tradeoff System
Michael Chomsky's critique of the "memory is markdown" school is useful because it preserves the counterweight: portable memory is correct as an ownership principle, but implementation is not solved by picking a file format. His self-thread compresses the hard parts: memory systems are still tradeoff-heavy, self-built memory often overcomplicates, collaboration creates new failure modes, observability and simplicity help but are barely enough, benchmarks are improving but incomplete, and attempts to improve agent performance can accidentally turn into a memory system, a database, or both. Source: X/@michael_chomsky, 2026-04-12; Source: X/@michael_chomsky self-thread, 2026-04-13
The practical rule is to separate ownership from mechanism. Kevin's wiki should remain portable, inspectable, and file-backed where that is the right layer; product memory still needs identity resolution, update policy, access control, observability, collaboration semantics, and benchmarks. Markdown can be the durable source of truth without pretending retrieval, consolidation, and maintenance are free.
Timeline
- 2026-07-03 | Deep-reviewed the @trq212 self-thread and clarified implementation notes as live episodic/procedural memory during agent implementation. Source: X/@trq212, 2026-05-18
- 2026-07-04 | Added Michael Chomsky's critique of oversimplified agent memory: ownership can be markdown/git-backed, but production memory still needs tradeoff management, observability, collaboration semantics, update policy, and benchmarks. Source: X/@michael_chomsky, 2026-04-12/13
- 2026-06-25 | Added the agent-memory-as-data-system lens from "Are We Ready For An Agent-Native Memory System?" and linked the MemoryData benchmark suite. Source: arXiv 2606.24775v1
- 2026-06-18 | Expanded with Kevin's semantic/episodic/procedural wiki mapping, write discipline, retrieval discipline, and memory pipeline. Source: User request, 2026-06-18
- 2026-05-31 | Page created from Mem0's long-term-memory writeup and the CoALA memory taxonomy. Captured the short vs long-term split, triad, extract-consolidate-store-retrieve pipeline, and token/latency case for structured memory. Source: Mem0, https://mem0.ai/blog/long-term-memory-ai-agents, 2026-05-31
- 2026-05-18 | @trq212's "running implementation-notes.html" technique as a procedural/episodic memory store. Source: X/@trq212, 2026-05-18