Pattern White Paper/Workshops/Memory

ADPS held its first workshop on the Memory module on 5 August 2026. The discussion began with a basic design question: what deserves to persist beyond one context window, and when does that requirement justify a dedicated memory system? From there, the group examined admission, retrieval tools, version conflicts, forgetting, procedural memory, and parametric memory.

This page organizes the discussion by engineering question and records how it changed the Memory module overview and the M1–M5 specifications.

1. Decide whether the system needs a memory service

Qingfeng Li compared product choices for different user groups. When developers can maintain stable preferences and project rules in repository files, those files already perform the memory function. Non-technical users are less likely to keep such material current, which creates a stronger case for automatic extraction, recall, and revision.

Qiuai Fu noted that coding agents can read language, framework, and project conventions directly from the local environment. Producing a second natural-language copy introduces another source of error. The remaining memory work covers extraction, retrieval, and periodic consolidation.

The workshop therefore placed two questions before storage selection:

1. Does the information require dynamic writing, reuse across sessions, and automatic recall?
2. Are users willing and able to maintain explicit rules themselves?

Once these answers are clear, a team can choose among repository files, a database, or a dedicated memory service.

2. Memory has a full lifecycle

Haofen Wang placed memory in the context of long-term adaptation and organizational experience. A production design has to answer seven questions together: what to retain, when to retain it, how to organize it, how to retrieve it, how to update it, when to forget it, and how to reuse it across sessions or groups. Vector insertion followed by similarity search covers only part of that lifecycle.

The discussion also established three engineering boundaries:

• A knowledge base holds reusable domain material. Memory records how a particular user, task, or system used that material and what happened during the work.
• A data ontology defines the entities, properties, and relationships in a business domain. Memory records experience gained while an agent works with those objects.
• A control plane owns current authoritative state. Approval results, business status, and receipts for irreversible actions belong in databases, state machines, or ledgers. Memory may retain references, explanations, and history.

These boundaries now appear in the Memory module overview.

3. Design writing and retrieval separately

Yingfeng Zhang described a write-time process that turns documents, logs, and sessions into summaries, entities, events, navigation structures, and pointers to source material. He calls this process knowledge compilation. The read side needs a retrieval harness: exact full-text matching, multi-vector search, navigation, relational queries, and source traversal all cover different access paths. Pure vector search does not provide that complete toolset.

This discussion changed the emphasis of M2. The specification now covers both the write pipeline and the read pipeline, and it requires retrieval output to carry version, time, scope, source pointers, and trace context. Knowledge Compilation remains a candidate pattern while ADPS collects schemas and evaluation methods.

4. Writing requires admission, versioning, and retirement

Dong Zhang discussed hierarchical retention, hit scoring, offline review, and intrinsic memory. The group made an important distinction: hit count measures use, while correctness requires a separate signal. Reading published higher-level memory and releasing revisions should also follow different paths. A runtime agent should not directly overwrite published medium- or long-term memory.

Mo Zhou covered forgetting, dynamic ontologies, collective memory, and snapshots. Retirement policy depends on the domain; time, access frequency, correctness, business risk, and scope may all affect it. Collective memory needs sharing boundaries, admission rules, and propagation controls so that one bad lesson does not spread across agents, projects, or tenants.

Yutao Chen separated explicit, activated, and parametric memory, and discussed coexisting versions, timestamps, and decoupling the agent from the memory layer. This view expanded M1 beyond a single scope hierarchy. The specification now treats scope, functional type, and access tier as independent dimensions.

5. The boundary of procedural memory

Mo Zhou also described Code Act, in which a stable lesson is compiled into executable code. It fits bounded tasks with stable definitions and a need for exact reproduction. The first generated program still requires acceptance, and changes to schemas, rules, or dependencies trigger recertification. Open-ended domains create too many variants for this approach to remain economical.

M5 now covers first-use acceptance, an applicability envelope, and recertification after invalidating changes. It remains an extension pattern.

6. Changes made to the white paper

The workshop led to the following revisions:

1. The module overview now begins with adoption criteria and the boundaries with knowledge bases, ontologies, and control planes.
2. M1 now covers a candidate pool, admission, hierarchy, versioning, retirement, and proof of deletion.
3. M2 occupies the single Memory × Chain coordinate and specifies write pipelines, multiple indexes, and the retrieval harness.
4. M3 adds a goal contract, references to authoritative state, artifact checkpoints, and side-effect deduplication after recovery.
5. M4 separates raw failure facts, candidate diagnoses, and validated lessons; active recall reads only published lessons.
6. M5 adds first-use acceptance, an applicability envelope, and recertification after invalidating changes.

Memory Admission, Knowledge Compilation, and Versioned Memory remain candidate mechanisms. ADPS will evaluate each on its own evidence rather than add patterns to fill empty matrix cells.

7. Open questions

• How can unattended candidate memory be kept from promoting temporary guesses into long-term recall?
• What reviewable migration and rollback path can connect explicit, activated, and parametric memory?
• How can a dynamic ontology accept new concepts while old tasks remain reproducible?
• How should collective memory evaluate sharing scope, write authority, and error propagation?
• How should memory evaluation cover writing, retrieval, use, and retirement in one test program?

Related pages

• Memory module overview
• M1 Hierarchical Retention
• M2 Retrieval-Augmented Generation
• M3 Progress Tracking
• M4 Failure Journals
• M5 Procedural Memory
• White Paper contributors