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.

1. Decide whether the system needs a memory service

Qingfeng Li described different choices in two products. Users of a coding product already wrote stable preferences into rules and project files, so it did not add automatic memory. Operations users of another product rarely maintained those files, creating a need for automatic extraction, recall, and updates.

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

A memory design specifies what to retain, when to write it, and how to organize, retrieve, update, and forget it. Sharing across sessions or teams also requires rules for who can read and write, and which version to use when records conflict.

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 write-time knowledge compilation: generating summaries, entities, events, navigation structures, and source pointers for documents, logs, and sessions. At read time, a retrieval harness provides exact full-text matching, multi-vector search, navigation, and relational queries. Agents need to locate specific passages, jump between sections, and return to source material; vector search alone does not cover these operations.

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 weekly or monthly hit baselines combined with independent scores to decide which rules to retain, demote, or retire. Topic summaries are recalled across one-day, seven-day, and thirty-day windows to reduce unrelated material in long contexts.

Hit count and correctness are measured separately: a frequently retrieved rule still needs revision if it fails quality checks. Reading and publishing higher-level memory also follow separate paths. Runtime agents read published versions and submit proposed changes for offline review rather than overwriting 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 storing stable experience as code. With bounded business definitions and enumerable inputs and outputs, a generated program can be reused without repeating the reasoning. As scenarios multiply, so do the programs and branches that require maintenance.

Participants also considered retaining code generated through Code Act as procedural memory. The generated program first passes business acceptance checks. Changes to schemas, rules, or dependencies require new tests and confirmation of the applicable scope before further reuse.

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

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.

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

Based on the 5 August 2026 workshop transcript. Internal project details have been anonymized.

Edit source · Published source · Review process