Pattern Matrix/White Paper/Memory
ADPS Agent Design Pattern White Paper · Module Overview
Memory Module · Turning Past Work into a Governed Runtime Asset
When to use an agent memory system, how it borders knowledge and control, and how its five specifications divide the work.
Scope: This page describes the memory subsystem as a whole. The M1–M5 specifications remain authoritative for pattern-level mechanics and verification.
If perception is an agent's eyes and action is its hands, memory is its past. It places perception, reasoning, and action on a time axis so that the next run can continue from facts, progress, and experience left by the previous one.
Memory is not an isolated runtime step. A tool call may produce a memory candidate, a failure may update the counterexample store, and a resumed task may reload both progress and authoritative business state. ADPS treats memory as a cognitive function to make a specific set of engineering responsibilities reviewable: what is retained, who may write it, when it is retrieved, which version wins, and how a team can trace a decision back to the memory that influenced it.
Decide whether a memory service is needed
Not every agent needs a dedicated memory system.
| Situation | Recommended treatment |
|---|---|
| One-shot questions, transformations, or short tool flows | Keep the agent stateless and pass required data with the request |
| Stable preferences maintained by technical users | Use versioned files, configuration, or project rules |
| Large domain corpora queried on demand | Build a governed knowledge base and retrieval pipeline |
| Changing user preferences and task experience that users will not maintain manually | Add a memory service with admission, retrieval, and governance |
| Approval state, balances, batches, or payment receipts | Keep authoritative facts in databases, state machines, or ledgers; memory stores references and explanations |
Two questions provide a useful first filter: is the information stable enough to maintain by hand, and will the user actually maintain it? When both answers are yes, a clear file structure is often more reliable than automatic memory.
Three engineering boundaries
| Adjacent system | Its responsibility | Memory's responsibility |
|---|---|---|
| Knowledge base | Reusable domain documents, facts, and evidence | How a user, task, or agent used those materials and what experience followed |
| Data ontology | The entities, attributes, and relations in the business world | What happened around those objects and which judgments the agent made |
| Control plane | Current authoritative state, transaction results, and execution constraints | Goals, progress narrative, historical explanation, and references to authoritative state |
Infrastructure may be shared, but ownership must remain explicit. A vector store may carry both document and memory indexes while the approval system still decides the current approval state. A natural-language summary cannot override a newer batch version in the database.
The minimum memory envelope
Content alone is not a usable memory record. A production envelope needs at least the following fields:
memory_id: mem_01J7...
kind: episodic # working | episodic | semantic | procedural | meta
scope:
tenant_id: acme
project_id: payroll
source:
type: tool_event
ref: trace://run-8842/tool-17
validity:
valid_from: 2026-08-05T09:00:00Z
valid_to: null
supersedes: mem_01J6...
trust:
status: accepted # candidate | accepted | rejected | retired
reviewed_by: policy://memory-admission-v3
retrieval:
keys: [approval-version, payroll-batch]
risk: medium
Identity, type, scope, source, valid time, version relation, publication state, and retrieval conditions are all operational fields. Without them, conflict handling, access control, rollback, and deletion remain ad hoc.
From candidate event to usable experience
Several stages are easy to omit:
- A candidate pool precedes long-term memory. Session summaries, tool events, and model reflections enter a staging area before they can affect active memory.
- Admission determines reuse. The system checks provenance, scope, sensitive data, conflicts, and risk. High-risk material requires reproduction or human review.
- Compilation keeps the source pointer. Summaries, entities, events, and navigation structures improve access, while conclusions remain traceable to original material.
- Retrieval is assembled for the current task. Goal, token budget, permission, valid time, and risk determine what enters context.
- Use produces a trace. The system records which memory was retrieved, whether the model used it, and which decision it influenced.
- Versions resolve change. Supersession and valid-time fields preserve history instead of silently deleting an old fact.
How the five specifications divide the work
| Pattern | Responsibility | Boundary |
|---|---|---|
| M1 Hierarchical Retention | Place memory by scope, functional partition, and access tier | Frequent use is not proof of correctness; rare high-risk rules must not be evicted automatically |
| M2 RAG Pipeline | Build multiple indexes over large sources and retrieve evidence for the current task | RAG supplies business evidence, not authoritative business state |
| M3 Progress Tracking | Preserve goals, milestones, and recovery position across a long task | Progress narrative references the control plane; it does not replace it |
| M4 Failure Journals | Turn failure events into verified lessons that can be recalled | A model's immediate root-cause guess remains a candidate diagnosis |
| M5 Procedural Memory | Package verified methods as triggerable, versioned runtime assets | Open-ended work resists heavy compilation; dependency changes require recertification |
M1 through M4 are core patterns. M5 remains an extension. M2 occupies the single Memory × Chain cell in the public matrix. Iterative retrieval is a mature implementation of the pattern, not a second coordinate.
Three directions under review
Memory Admission studies how candidate content enters the correct scope and is currently being evaluated at Memory × Route. Knowledge Compilation studies how raw material becomes navigable, searchable, and directly readable at write time. Versioned Memory covers valid time, supersession, conflict, snapshots, and rollback; it is currently treated as an update-loop and governance concern.
Collective memory sharing is not yet a separate pattern. Its first-order problems are scope, permission, admission, and propagation control. Several agents reading the same store does not by itself create a parallel topology.
Questions that need more field evidence
- How can unattended systems detect and quarantine low-quality auto-archived memory?
- Is there a reproducible migration path among explicit, activated, and parametric memory?
- How can a resumed task prove that it did not repeat an irreversible side effect?
- How should shared memory prevent a bad lesson from spreading across agents, projects, or tenants?
- How should evaluation cover writing the right memory, retrieving the right item, using it correctly, and retiring it safely?
Contributors to this module
This list is based on attributable speech in the transcript of the ADPS memory workshop held on 5 August 2026. Inclusion credits a contribution to this module; it does not imply that a contributor or their organization endorses every conclusion in the white paper.
| Name | Public role at the workshop | Main contribution to this module |
|---|---|---|
| Haofen Wang (王昊奋) | Tenured professor and doctoral advisor, Tongji University; first rotating chair of OpenKG | Memory lifecycle, memory scaling, and reuse of organizational experience |
| Jia Huang (黄佳) | ADPS founder; workshop co-host | Mapping to the two-axis framework, discussion structure, and white-paper editing |
| Yingfeng Zhang (张颖峰) | Co-founder and CEO, InfiniFlow | Knowledge compilation, retrieval harnesses, and the division between write-time and retrieval-time work |
| Qiuai Fu (付求爱) | Huawei Cloud AIOps technical lead | Memory extraction, retrieval, and periodic consolidation for coding agents |
| Dong Zhang (张栋) | Tencent expert engineer; head of Wukong R&D security | Hierarchical retention, hit scoring, offline audit, and intrinsic memory |
| Mo Zhou (周默) | Algorithm architect, User Operations Department, Platform Marketing Center, JD Retail | Forgetting, dynamic ontologies, collective memory, snapshots, and Code Act |
| Yutao Chen (陈玉涛) | Solution specialist, MemTensor | Explicit, activated, and parametric memory; versioning, decoupling, and adaptation by scenario |
| Qingfeng Li (李庆丰) | Senior director, Sina Weibo | The boundary between memory and knowledge bases, and when a separate memory system is unnecessary |
This page incorporates material from the ADPS memory workshop held on 5 August 2026. The public specification retains testable engineering mechanisms. Named practice and quantitative claims enter the case library only after publication approval and measurement review.