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.

The final sections record how the findings changed the Memory module overview and the M1–M5 specifications.

1. Decide whether the system needs a memory service

Qingfeng Li contrasted two products for different users. Developers already write stable preferences into rules and project files, so one coding product did not add automatic memory. Operations users rarely maintain those files, so another product needed extraction and recall. The decision starts with change frequency and the user’s willingness to maintain explicit rules.

The group compared two product choices. 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.

Coding agents can also read language, framework, and project conventions directly from the local environment. Producing a second natural-language copy introduces another source of error and staleness. 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?

Those answers determine whether repository files, a database, or a dedicated memory service fits the system.

2. Memory has a full lifecycle

Memory belongs 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 separate write-side knowledge-compilation path. Documents, logs, and sessions first gain summaries, entities, events, navigation, and source pointers. A retrieval harness then chooses exact text, multi-vector, navigation, or relational access. He noted that pure vector search is unfriendly to agents that must locate and jump through material.

A write-time process can turn documents, logs, and sessions into summaries, entities, events, navigation structures, and pointers to source material. The workshop used knowledge compilation for this process. The read side needs a retrieval harness: exact full-text matching, multi-vector search, navigation, relational queries, and source traversal 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 described how one production system reviews retained rules. Rules receive weekly or monthly hit baselines plus an independent score before retention, demotion, or retirement. Frequent use does not prove correctness. Topic summaries are also recalled across one-day, seven-day, and thirty-day horizons to limit attention drift.

Discussion of hierarchical retention, hit scoring, offline review, and intrinsic memory produced 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.

The workshop also 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.

Explicit, activated, and parametric memory raise questions about 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 described compiling stable experience into code and defined when the approach stops paying off. Bounded business definitions with enumerable inputs and outputs can justify a reusable program; an effectively unbounded scenario makes branch maintenance more expensive than the benefit.

The workshop also examined 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. Concepts extracted from the workshop

These terms describe work between the current specifications. The workshop revised existing patterns without adding a number to fill the matrix.

7. 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.

8. 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

This page lists workshop participants and consolidates the discussion by theme. It does not map internal practice point by point to a person or organization. Conclusions adopted after comparison appear in the Memory module overview and individual pattern specifications.

Edit source · Published source · Review process