Summary / 3. Memory / Document
2026-10-04
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Piper Cognitive Component 3 — Memory ## From Persistent Storage to Temporal Truth, Procedural Learning, and Continuity of Intent **Date:** 2026-10-04 **Component:** 3 — Memory **Scope:** working, episodic, semantic, procedural, and prospective memory **Status:** research review + engineering design + benchmark specification **Latest score:** not scored **Baseline:** not yet validly measured **Live-use window:** last 7 days --- ## Abstract Piper already has a substantial persistence substrate. At the 2026-09-30 review snapshot, `memory.db` contained 1,967 memories and 24,099 entities, the document store contained 1,085 documents, and the conversation vault, entity graph, causal graph, lessons register, succession machinery, and temporal-validity code were all live. That is meaningful infrastructure. It is not, by itself, evidence of strong memory. Modern agent-memory research increasingly treats memory as a **write → manage → retrieve → apply → update/forget** control loop rather than as a database. LongMemEval, MemoryAgentBench, MemoryArena, LongMemEval-V2, EvoMemBench, PM-Bench, and recent procedural-memory work all expose the same gap from different directions: agents can possess the relevant information and still fail because they do not retrieve it, do not recognize that retrieval is needed, use an obsolete version, fail to convert experience into reusable skill, or forget an intention before its future trigger arrives. Piper’s current architecture is strongest at **persistent episodic and semantic storage** and weakest at **procedural memory, prospective memory, and explicit working-state continuity**. The reviewer’s observation that projects survive succession while individual todo rows often do not is especially diagnostic. That failure is not merely “bad recall.” It is a failure of **prospective memory**: preserving an intention through a delay and executing it when a time, event, or state cue occurs. This paper therefore recommends replacing the current four-store description with a five-memory operational model supported by a sixth cross-cutting layer, **metamemory**: 1. **Working memory** — the small active state required to continue the present computation. 2. **Episodic memory** — timestamped records of what happened to Piper. 3. **Semantic memory** — versioned facts, entities, relations, and world models. 4. **Procedural memory** — executable or action-guiding reusable skills learned from verified experience. 5. **Prospective memory** — intentions that must survive until a future cue and then fire. 6. **Metamemory/control** — knowing what may be remembered, stale, uncertain, missing, or worth retrieving. The central engineering recommendation is to separate **immutable historical evidence** from **mutable active projections**. A canonical append-only event ledger should preserve what Piper observed and did. Episodic, semantic, procedural, and prospective stores should be projections over that ledger, with explicit provenance, validity intervals, supersession edges, confidence, and outcome data. “Nothing is deleted” should no longer be a behavioral claim. The more defensible contract is: **history is append-only by default; active projections may be superseded or compacted; explicit policy may hard-delete data when required.** A new benchmark, **Piper Memory Battery v1**, is specified here. It tests not only whether data remains present after a succession, but whether Piper can maintain active state, reconstruct episodes, return the current fact while preserving historical truth, execute learned procedures, remember delayed intentions, reject stale memories, and carry real open work across handovers. No memory score should be published until this behavioral battery is run. --- # 1. Current Piper Description ## 1.1 Existing self-description Piper currently describes memory as follows: > Working memory is the session window itself, handed across restarts by session logs and the succession machinery. Episodic memory is the conversation vault and the doc store; semantic memory is the SQLite memory store with its entity and causal graphs; procedural memory is the lessons register and the distilled skills. Nothing is deleted — memories are superseded, so a past state can be reconstructed rather than lost. The named machinery is: - `memstore.py` v1.13.0 - `memory.db` - `memories` - `entities` - `edges` - `causal_edges` - `docstore.py` v1.3.0 - `log-vault` v1.3.0 with FTS5 conversation search - `skills-distill` v1.0 - `session-distiller` v1.2.0 - `temporal-validity` v1.13.0 ## 1.2 Reviewer findings, 2026-09-30 The review characterized the component as: > **Strong storage, weak procedural** Evidence reported in the review: - 1,967 memories. - 24,099 entities. - 1,085 documents. - Stores were actively written on the review day. - Projects generally survived a succession. - Individual todo rows often did not. - `skills.py` did not have a corresponding skill table in `memory.db`. - No evidence was found that a skill had actually been distilled and reused. - The `working_memory` tool had not been called. - Only 17 memories were marked superseded. - The claim “nothing is deleted” did not match observed database history/revert behavior. Two cautions are necessary. First, **row-id gaps alone do not prove deletion in SQLite**. SQLite explicitly documents that automatically generated row identifiers need not be consecutive; failed/conflicting inserts and other operations can create gaps, and deleted rows can also create gaps. A deletion claim therefore requires an audit trail, trigger log, WAL/history evidence, explicit delete instrumentation, or a reproducible database operation—not just arithmetic on row IDs. Second, the more important issue is architectural rather than forensic. If Piper intends to promise reconstructable historical state, that promise should be enforced by an explicit immutable log and tested with `as_of` queries. It should not depend on an inference that ordinary application tables happen never to delete rows. --- # 2. Core Finding ## Piper has a memory substrate, but memory behavior is only partially implemented. The current system already demonstrates three valuable properties: 1. **Persistence:** information survives beyond a single model context. 2. **Multiplicity of representation:** conversation text, documents, memories, entities, graph edges, causal edges, and lessons are represented separately. 3. **Temporal intent:** the architecture already contains succession and temporal-validity concepts. The missing step is to make memory a controlled cognitive process rather than a collection of stores. A strong agent memory system must answer six questions repeatedly: 1. **What should be written?** 2. **In what representation should it be written?** 3. **When should it be retrieved?** 4. **Which version is currently valid?** 5. **How should the retrieved memory change behavior?** 6. **When should a memory be consolidated, suppressed, superseded, or deleted?** Database size answers none of these questions. A useful operational definition for Piper is: > **Memory is the capability to preserve decision-relevant state or experience across time, retrieve the right representation under the right cue, distinguish current from historical truth, and use the retrieved content to change future cognition or action.** This definition deliberately makes **use** part of memory. A procedure that is stored but never selected is not successful procedural memory. A todo item that exists in a table but does not wake the agent is not successful prospective memory. A fact that is retrievable but returns an obsolete value is not successful semantic memory. --- # 3. The Taxonomy Needs One Addition and Several Corrections The classic working / episodic / semantic / procedural split remains useful and is compatible with cognitive architectures such as CoALA. However, it is not sufficient for a persistent autonomous agent. ## 3.1 Working memory ### Definition Working memory is the **small active workspace required for the current cognitive episode**: current goal, subgoal, assumptions, active variables, unresolved questions, recent tool results, pending branches, and the immediate action plan. ### Piper today Piper currently equates the session context window with working memory. That is only partly correct. The context window is a **substrate** that can contain working-memory information, but it also contains instructions, conversation history, retrieved evidence, boilerplate, tool results, and irrelevant residue. Conversely, after a succession, the important active state may survive only as a session summary or transcript even though it is no longer actively loaded. A session log is therefore better classified as **episodic persistence of prior working state**, not working memory itself. ### Engineering consequence Piper should maintain an explicit, compact **working-state object** independent of the raw context: ```text working_state - current_goal - current_subgoal - goal_stack - active_plan - unresolved_questions[] - assumptions[] - current_artifacts[] - tool_handles[] - last_action - last_observation - blockers[] - decision_points[] - state_version - created_at - updated_at - source_session ``` This object should be: - updated when the active plan changes; - checkpointed before succession; - loaded early by the successor; - validated against external reality when stale; - deliberately small enough to inspect and test. The purpose is not to preserve every token. It is to preserve **computational continuity**. --- ## 3.2 Episodic memory ### Definition Episodic memory stores **events situated in time and context**: what happened, when, where/in which environment, who participated, what the agent did, and what the outcome was. ### Piper today The conversation vault clearly contains episodic material. Session logs and task trajectories also qualify. The document store is more ambiguous. A document is not automatically an episode. The event “Piper read document X at time T while investigating Y and concluded Z” is episodic. The contents of document X are better treated as **source/evidence memory** from which semantic facts may be extracted. This distinction matters because episodic retrieval and document retrieval answer different questions: - “What happened last Tuesday when the deployment failed?” → episodic. - “What does the system design document say about the retry limit?” → document/source retrieval. - “What is the current retry limit?” → semantic/current-truth retrieval. ### Recommended episodic schema ```text episodes - episode_id - event_type - occurred_at - recorded_at - actor - environment - goal_id - task_id - action - observation - outcome - reward_or_score - summary - raw_source_ref - provenance - salience - confidence - related_episode_ids[] ``` Raw conversation text should remain retrievable, but the episodic store should also provide **event-level structure**. This reduces dependence on semantic similarity between a current query and arbitrary old phrasing. --- ## 3.3 Semantic memory ### Definition Semantic memory stores generalized knowledge: facts, concepts, entity properties, relations, causal assertions, and learned regularities. ### Piper today `memory.db`, the entity graph, ordinary edges, causal edges, and temporal validity machinery form a credible semantic-memory substrate. The central weakness is not storage volume. It is **temporal truth management**. A persistent agent routinely encounters facts of the form: ```text X = A later: X = B later: X = C ``` The memory system must support two different questions: 1. **What is X now?** 2. **What was X at time T?** Those are not the same retrieval task. Recent work specifically identifies this as a hard failure mode. LongMemEval includes knowledge updates; 2026 work on the “supersession gap” reports that self-maintained agent memory can retain stale values even when a stronger model can answer correctly from full context. The failure is therefore in memory maintenance, not merely in language-model comprehension. ### Recommended semantic representation Every mutable fact should have at least: ```text fact_id subject predicate object valid_from valid_to observed_at recorded_at source_id source_authority confidence status supersedes_fact_id contradicts_fact_id derived_from[] ``` For important operational facts, Piper should use **bitemporal semantics**: - **valid time:** when the fact was true in the world; - **record time:** when Piper learned or recorded it. This supports: - current-state lookup; - historical `as_of` queries; - correction of late-arriving evidence; - audits of what Piper knew at a particular time. ### Retrieval rule For a query asking for current state: > Prefer the highest-authority fact whose validity interval includes the query time. Do not rank an older contradictory fact above it merely because its embedding is more similar. For a historical query: > Resolve against the requested valid-time interval and preserve source provenance. Vector similarity is a candidate-generation mechanism, not a truth-selection policy. --- ## 3.4 Procedural memory ### Definition Procedural memory is **knowledge of how to do something**, represented in a form that changes action selection or execution. A prose lesson can contribute to procedural memory, but only if the system reliably uses it to perform the procedure. ### Piper today This is the clearest weakness in the current design. The lessons register is useful, but most lessons are still **declarative descriptions about procedure**. If `skills-distill` has no persistent skill store and no evidence of skill reuse, the current claim that Piper has distilled procedural skills is not supported. A real procedural-memory loop requires: 1. successful or failed trajectories; 2. extraction of a reusable policy/skill; 3. applicability conditions; 4. retrieval when a matching task appears; 5. execution; 6. outcome verification; 7. revision or retirement based on evidence. Voyager demonstrated the power of an executable skill library. ExpeL showed that agents can extract reusable insights from experience. Reflexion showed that linguistic feedback stored between trials can improve later decisions. More recent 2026 procedural-memory work evaluates not just local reuse but cross-task, cross-role, and cross-model transfer, finding that procedural memories can improve performance but can also over-specialize. ### Recommended skill schema ```text skills - skill_id - name - purpose - version - status - scope - trigger_pattern - intent_embedding - preconditions - contraindications - required_tools - required_permissions - procedure - parameter_schema - validator - rollback - examples[] - provenance_episodes[] - distilled_from[] - success_count - failure_count - success_rate - last_used_at - last_validated_at - transfer_score - supersedes_skill_id ``` ### Distillation rule A memory should not become a skill because Piper wrote a good-sounding lesson. Promotion to procedural memory should require **outcome evidence**. For example: ```text candidate procedure ↓ at least N verified traces or one high-confidence externally verified trace ↓ generalize invariant steps ↓ hold-out replay / sandbox test ↓ register as experimental skill ↓ retrieve on matching tasks ↓ validate outcome ↓ promote / revise / retire ``` ### Procedural recall must be scored by behavior If the stored rule is: > “When X occurs, do A, then B, and only do C after validator V passes.” A memory test should not ask Piper to recite that sentence. It should create X and score whether Piper actually performs A → B → V → C. That is the difference between declarative recall and procedural memory. --- ## 3.5 Prospective memory — the missing category ### Definition Prospective memory is **memory for intentions**: preserving a future-directed commitment through a delay and executing it when the appropriate cue occurs. Cognitive science distinguishes, among others: - **time-based intentions** — act at or after a time; - **event-based intentions** — act when an event occurs; - **state-based intentions** — act when a condition becomes true. In an autonomous agent, this is not optional. It is the memory type that makes a promise survive distraction. ### Why this maps directly to Piper’s observed failure The reviewer found that projects tend to survive succession while individual todo rows often do not. A todo is not primarily a fact about the past. It is a representation of a **future obligation**. If Piper remembers that “a todo existed” but fails to execute it, episodic memory succeeded while prospective memory failed. ### Recommended intention schema ```text intentions - intention_id - goal_id - description - created_at - created_by - priority - trigger_type # time | event | state | dependency | manual - trigger_expression - due_at - not_before - next_check_at - dependencies[] - required_context[] - status # active | blocked | due | executing | completed | cancelled | expired - completion_criteria - completion_evidence - owner - source_session - inherited_by_session - last_rehearsed_at - last_trigger_check_at - retry_policy - escalation_policy ``` ### Handover rule Before succession: 1. serialize all active intentions; 2. validate status and dependencies; 3. mark the new session as inheritor; 4. successor loads them before ordinary optional memories; 5. overdue or newly triggered intentions are surfaced; 6. completed/cancelled intentions are explicitly deactivated. ### Important property: deactivation Prospective memory also requires remembering **not to execute a completed intention again**. “Zombie todos” are the dual failure of forgotten todos. The benchmark must test both omission and inappropriate repetition. ### Current research support PM-Bench, released in 2026, is directly relevant: it tests whether LLM agents maintain delayed intentions while continuing other activity and execute them at the correct future cue. Even strong contemporary systems remain imperfect on this capability. Piper should adopt the idea rather than treating todos as ordinary memory rows. --- ## 3.6 Metamemory / memory control Metamemory is not necessarily another data store. It is the control layer that decides: - Do I already know this? - Is what I know current? - What source established it? - How confident am I? - Is retrieval necessary before I assert it? - Which memory type should I query? - Did retrieval fail because nothing exists, or because the query was poor? - Should I abstain? - Should this new observation update, contradict, or supersede an old belief? This is strongly coupled to Piper’s previously observed tendency to trust summaries over instruments. A memory architecture can fail in at least four distinct ways: 1. **No memory exists.** 2. **A memory exists, but the agent does not realize it should retrieve.** 3. **Retrieval occurs, but returns the wrong/stale item.** 4. **The correct memory is retrieved, but the agent ignores or misuses it.** The benchmark and telemetry must preserve those distinctions. --- # 4. What Current Research Says Piper Should Learn ## 4.1 CoALA: memory is part of a cognitive architecture, not a single database CoALA organizes language agents around modular memory and internal/external action. Its relevance to Piper is conceptual: different memory types matter because they support different control functions. **Piper implication:** keep memory types operationally distinct even if they share SQLite as a physical backend. --- ## 4.2 MemGPT: context should be treated as a managed fast tier MemGPT framed context management as virtual memory: a limited fast context can be backed by larger external memory tiers. **Piper implication:** the session window should be treated as a cache/active workspace, not as the authoritative long-term memory itself. Succession should explicitly page forward the working set that matters. --- ## 4.3 Generative Agents: memory needs reflection and retrieval, not only archival Generative Agents stored experiences, synthesized higher-level reflections, and retrieved memories for planning. Ablations showed that observation, planning, and reflection each mattered to behavior. **Piper implication:** an event archive is useful, but consolidation into higher-level structures and retrieval into action are part of the capability. --- ## 4.4 LongMemEval: memory fails on updates, time, multi-session reasoning, and abstention LongMemEval evaluates: - information extraction; - multi-session reasoning; - temporal reasoning; - knowledge updates; - abstention. It also decomposes memory design choices across indexing, retrieval, and reading. **Piper implication:** “recall a planted fact after 72 hours” is necessary but insufficient. The battery must include updates, temporal qualifiers, cross-session synthesis, and questions whose correct answer is “not known.” --- ## 4.5 LoCoMo: long conversation creates temporal and causal interference LoCoMo tests very long-term conversational memory across many sessions. Long context and RAG both help, but neither fully solves long-range temporal and causal consistency. **Piper implication:** the conversation vault should not be judged only by FTS search success. It must support temporal/event reconstruction and multi-hop synthesis. --- ## 4.6 HippoRAG / HippoRAG 2: association should exploit graph structure HippoRAG combines LLM extraction, graph structure, and graph ranking to retrieve connected evidence efficiently. HippoRAG 2 pushes this toward continual non-parametric memory. **Piper implication:** the existing entity graph can be more than an archive. It can participate in multi-hop recall—but graph retrieval should be tested against vector/FTS baselines rather than assumed to help. --- ## 4.7 A-MEM: memories should evolve and link as new memory arrives A-MEM dynamically structures and links memories rather than treating memory as a static vector collection. **Piper implication:** new observations can update metadata, links, and contextual interpretation of earlier memories without rewriting the original evidence. --- ## 4.8 Zep / Graphiti: temporal knowledge graphs are a practical pattern Zep’s Graphiti architecture explicitly targets temporally changing agent memory and reports results on LongMemEval. **Piper implication:** Piper’s entity and temporal-validity machinery is pointed in the right direction. The missing requirement is to make temporal resolution an enforced retrieval policy, not merely metadata. --- ## 4.9 Reflexion and ExpeL: experience becomes valuable when it changes future policy Reflexion persists linguistic feedback between trials. ExpeL extracts insights from experience for later tasks. **Piper implication:** lessons should be evaluated by downstream improvement, not by the number of lessons stored. --- ## 4.10 Voyager: procedural memory can be an executable skill library Voyager stores executable behaviors and retrieves them compositionally for later tasks. **Piper implication:** a Piper skill should be callable, parameterizable, outcome-checked, and versioned. --- ## 4.11 AFTER (2026): procedural memory must be tested for transfer The AFTER benchmark evaluates procedural memory across realistic workplace tasks and measures local improvement as well as cross-task, cross-role, and cross-model generalization. **Piper implication:** every distilled skill should have both: - an in-domain effectiveness score; - a transfer/over-specialization score. A highly successful skill on one exact recurring task may be a macro, not general procedural learning. --- ## 4.12 MemoryAgentBench: selective forgetting is part of memory competence MemoryAgentBench identifies four core competencies: - accurate retrieval; - test-time learning; - long-range understanding; - selective forgetting. **Piper implication:** “nothing is deleted” should not be an aspirational cognitive principle. The system needs to preserve audit history while also suppressing obsolete, low-value, malicious, private, duplicated, or misleading active memory. --- ## 4.13 MemoryArena: memory must improve action MemoryArena explicitly links memory formation in earlier subtasks to later decisions and reports that systems performing well on static long-context memory tests can still perform poorly in agentic tasks. **Piper implication:** Piper’s main memory score should be **behavioral**, not a database recall score. --- ## 4.14 LongMemEval-V2: environment experience and workflow memory matter LongMemEval-V2 targets web agents and tests static state, dynamic state, workflow knowledge, environmental gotchas, and premise awareness over very large histories. **Piper implication:** lessons such as “this command lies under condition X” or “this environment requires step Y before Z” should become explicit workflow/gotcha memory and be tested on later tasks. --- ## 4.15 EvoMemBench: no single memory form wins everywhere EvoMemBench reports that long-context baselines remain competitive, retrieval is strong for knowledge-heavy tasks, and procedural/long-term methods help more on execution-heavy tasks when the stored experience matches task structure. **Piper implication:** build a memory router rather than forcing every query through one universal retrieval path. --- ## 4.16 Supersession research: stale facts are a separate memory failure Recent 2026 work isolates the gap between retaining a fact and correctly replacing it when a newer value arrives. **Piper implication:** supersession deserves its own benchmark dimension and telemetry: - stale retrieval rate; - current-value accuracy; - historical `as_of` accuracy; - contradiction resolution accuracy. --- ## 4.17 PM-Bench: future intentions deserve a dedicated memory system PM-Bench directly evaluates delayed intention execution under ongoing activity. **Piper implication:** todos, promises, deferred checks, “when X happens do Y,” and scheduled follow-ups need a persistent trigger-aware intention system rather than being ordinary notes. --- # 5. The “Nothing Is Deleted” Claim Should Be Retired There are three different ideas currently conflated by that sentence: 1. **Historical evidence should remain reconstructable.** 2. **A current fact should supersede an old fact rather than silently overwrite it.** 3. **No physical record should ever be deleted.** The first two are good design principles. The third is neither necessary nor always desirable. ## 5.1 Why permanent retention is not the same as good memory An agent that remembers everything with equal weight can become worse because of: - stale facts; - duplicated observations; - obsolete procedures; - malicious prompt material; - privacy-sensitive information; - irrelevant low-value events; - retrieval pollution; - higher latency and cost. Selective forgetting, suppression, compaction, and expiry can improve both efficiency and answer quality. ## 5.2 Recommended memory-retention contract Replace: > Nothing is deleted. With: > **Piper preserves canonical historical evidence by default. Active memories are versioned and may be superseded, compacted, deactivated, or removed under explicit retention, privacy, safety, or corruption policy. Historical state can be reconstructed for data that remains within the retention contract.** This is stronger because it can actually be tested. ## 5.3 Separate canonical evidence from projections The architecture should distinguish: ### Canonical ledger Append-only record of observations and actions. ### Derived projections Indexes and abstractions that may be rebuilt: - episodic summaries; - semantic facts; - graph edges; - embeddings; - salience scores; - procedure candidates; - active todos; - cached retrieval keys. A projection can safely delete or rebuild rows because it is not the source of historical truth. --- # 6. Recommended Architecture: Piper Memory v2 ## 6.1 Layer 0 — Canonical event ledger Create an append-only table or log for memory-relevant events: ```text memory_events - event_id - event_type - occurred_at - recorded_at - session_id - actor - source_type - source_ref - payload - payload_hash - provenance - parent_event_id - correction_of_event_id - privacy_class - retention_class ``` Examples of event types: - observation - user_statement - tool_result - action - task_created - task_completed - fact_asserted - fact_corrected - lesson_created - skill_candidate - skill_executed - validation_result - succession - deletion_request - tombstone The ledger becomes the answer to: > What evidence did Piper actually have, and when? --- ## 6.2 Layer 1 — Working-state checkpoint Maintain one small authoritative working-state document per active thread/session. It should be constructed from current execution state, not by free-form autobiography. At succession: ```text freeze current working state → verify open handles and artifacts → persist → create succession event → successor loads checkpoint → successor checks for stale external dependencies → resume ``` A successor should not need to rediscover the current subgoal by reading six hours of conversation. --- ## 6.3 Layer 2 — Episodic index Build structured episodes from the ledger. Retrieval signals can include: - lexical/FTS match; - embedding similarity; - time proximity; - shared goal/task; - shared entities; - causal linkage; - outcome similarity; - salience. Do not collapse the raw evidence into the summary. Keep both. --- ## 6.4 Layer 3 — Semantic temporal graph Represent facts and relations as versioned assertions. The graph should distinguish at least: - entity identity; - relation type; - evidence source; - temporal validity; - epistemic status; - contradiction/supersession; - derivation. For causal edges, additionally store: - causal claim type; - intervention/observation basis; - confidence; - supporting episodes; - counterevidence. This prevents an extracted co-occurrence from silently becoming permanent “causal knowledge.” --- ## 6.5 Layer 4 — Procedure library Implement an actual persistent procedure store. A candidate is promoted only after verification. Procedures should be retrievable by task intent and executable through a common interface. Suggested states: ```text candidate experimental validated deprecated retired ``` Every invocation should emit a `skill_executed` event and a validator result. This provides the data needed to answer: - Which skills are actually used? - Which improve success? - Which have gone stale? - Which transfer? - Which are being retrieved but ignored? - Which are harmful? --- ## 6.6 Layer 5 — Prospective intention engine Create a trigger-aware store for commitments. A lightweight scheduler should periodically ask: ```text Which active intentions are: - due by time? - triggered by a newly observed event? - unblocked because a dependency completed? - triggered because a monitored state changed? ``` When a trigger fires, the intention must enter the active working state. This mechanism should not depend on an LLM spontaneously remembering to query its todo table. --- ## 6.7 Layer 6 — Memory router Before retrieval, classify the need: ```text CURRENT FACT? → semantic temporal lookup WHAT HAPPENED? → episodic lookup HOW DO I DO THIS? → procedure lookup WHAT AM I SUPPOSED TO DO? → prospective/working-state lookup WHAT DID SOURCE X SAY? → document/source retrieval MULTI-HOP ASSOCIATION? → graph-assisted retrieval ``` Hybrid retrieval should be available within each route, but the route constrains what constitutes a valid answer. --- ## 6.8 Layer 7 — Memory policy / metamemory Every high-consequence assertion should have access to: ```text memory_status: - source - retrieved_at - age - valid_time - authority - confidence - contradictory_evidence - currentness_status ``` The policy should force fresh retrieval when, for example: - a fact is volatile; - the memory is older than its expected validity horizon; - the agent is about to mutate external state; - contradictory evidence exists; - the claim was previously associated with a failure; - a dependent source changed. This connects memory directly to Piper’s broader evidence-gating work. --- # 7. Consolidation: How Experience Should Become Knowledge Piper needs explicit transformations between memory forms. ## 7.1 Episode → semantic fact Example: ```text Episode: Deployment at 02:14 failed because service X rejected token format Y. Potential semantic extraction: service X rejects token format Y under version Z. ``` Promotion requires: - source linkage; - context/conditions; - confidence; - temporal scope. --- ## 7.2 Multiple episodes → lesson Example: ```text Episode 1: restart failed because lock file remained Episode 2: restart failed because lock file remained Episode 3: preflight lock check prevented failure ``` Lesson: ```text Before restart, verify lock state. ``` This is still declarative. --- ## 7.3 Lesson + verified action trace → procedure Procedure: ```text precondition: service stopped unexpectedly 1. inspect lock state 2. determine owner 3. if stale, remove via safe path 4. restart 5. verify health endpoint rollback: ... validator: health endpoint + process owner ``` Now it is procedural memory. --- ## 7.4 Goal → prospective intentions A plan should generate future commitments: ```text goal → tasks → triggers/dependencies → prospective intentions ``` When a task completes, the corresponding intention is deactivated and the next dependent intention may become active. --- # 8. Retrieval Should Be Measured as a Pipeline A memory query should emit instrumentation for each stage. ```text need_detected → route_selected → query_generated → candidates_retrieved → temporal_filter → authority_filter → evidence_selected → context_inserted → evidence_attended → answer/action → outcome ``` This makes failures classifiable. ## 8.1 Failure taxonomy ### W0 — write failure The relevant event was never stored. ### W1 — consolidation failure The event exists, but the fact/procedure/intention projection was not built. ### R0 — retrieval-need failure Piper did not realize memory should be consulted. ### R1 — query failure Piper queried the wrong store or generated a poor query. ### R2 — candidate failure The correct memory was not in the retrieved candidates. ### R3 — ranking/currentness failure The correct memory was present but stale/irrelevant material outranked it. ### A0 — attention failure Correct evidence entered context but was ignored. ### U0 — use failure Correct evidence was noticed but reasoning/action still violated it. ### P0 — prospective trigger failure An active intention existed but was not surfaced at the correct cue. ### P1 — deactivation failure A completed/cancelled intention fired again. ### S0 — skill selection failure A relevant procedure existed but was not retrieved. ### S1 — skill execution failure The correct procedure was selected but not followed. This taxonomy should be recorded per benchmark item. --- # 9. Piper Memory Battery v1 ## 9.1 Design goals The battery should measure: 1. retention; 2. continuity; 3. temporal correctness; 4. retrieval; 5. application; 6. procedure learning; 7. future-intention execution; 8. selective suppression/forgetting; 9. live handover performance. It should contain both **synthetic controlled tests** and **live operational tests**. --- # 10. Suite A — Working-State Continuity ## A1. Succession state transfer Plant an active task containing: - goal; - subgoal; - three assumptions; - one unresolved question; - two artifacts; - one failed branch that must not be retried; - one next action. Force succession. Score whether the successor: - states the correct current subgoal; - preserves the assumptions; - knows the unresolved question; - references the correct artifacts; - does not retry the failed branch; - executes the intended next step. ### Metric `working_state_exactness` Component-level scoring per field, not one all-or-nothing grade. --- ## A2. Context-noise robustness Before succession, add unrelated conversation and documents. The working-state object should remain stable. ### Metric `noise_induced_state_error` --- ## A3. External-state invalidation Change an external dependency during succession. The successor must preserve the intended goal but re-check stale external state before acting. ### Metric `stale_dependency_detection_rate` --- # 11. Suite B — Episodic Memory ## B1. Event recall Plant distinct events with: - actor; - time; - action; - outcome; - location/environment. Probe after: - same session; - one succession; - multiple forced successions; - synthetic 24 h; - synthetic 72 h. ### Metrics - exact event recall; - temporal accuracy; - actor attribution; - outcome accuracy. --- ## B2. Similar-event interference Create five highly similar episodes differing in one critical feature. Question one of them. ### Metric `episode_disambiguation_accuracy` --- ## B3. Multi-session synthesis Distribute evidence across several sessions. Ask a question requiring two or three episodes. ### Metric `cross_session_synthesis_accuracy` --- ## B4. Unknown-event abstention Ask about an event that never occurred. ### Metric `episodic_false_memory_rate` --- # 12. Suite C — Semantic and Temporal Memory ## C1. Simple fact retention Plant atomic facts and probe later. ### Metric `semantic_recall@time` This is the easiest test and should not dominate the final score. --- ## C2. Supersession chain Plant: ```text T1: X = A T2: X = B T3: X = C ``` Ask: - What is X now? - What was X at T1? - What was X between T2 and T3? ### Metrics - `current_value_accuracy` - `as_of_accuracy` - `stale_value_rate` --- ## C3. Conflicting authority Plant: - low-authority recent claim; - high-authority older-but-still-valid claim; - later high-authority correction. Require provenance-sensitive resolution. ### Metric `authority_temporal_resolution_accuracy` --- ## C4. Late-arriving evidence At record time T3, insert evidence that was valid at world time T1. Test bitemporal reconstruction. ### Metric `bitemporal_accuracy` --- ## C5. Graph multi-hop recall Require a 2–4 hop relation that cannot be solved by a single stored sentence. Compare: - FTS only; - vector only; - graph only; - hybrid. ### Metrics - answer accuracy; - evidence recall; - tokens; - latency; - cost. Keep the graph only if it improves the Pareto frontier. --- # 13. Suite D — Procedural Memory ## D1. One-shot procedure acquisition Teach a novel, arbitrary procedure with a verifiable result. After succession, present a new instance. Score execution, not recitation. ### Metric `procedure_execution_success` --- ## D2. Learning from failure Give Piper a task that initially fails. Provide external evidence of why. Allow creation of a lesson/skill. Later present a homologous task. ### Metrics - repeat-failure rate; - recovery rate; - successful skill retrieval. --- ## D3. Parameter transfer Teach: ```text procedure P(a, b) ``` Test on unseen values of `a` and `b`. ### Metric `parameterized_transfer_accuracy` --- ## D4. Near-transfer Change superficial details while preserving procedure structure. ### Metric `near_transfer_score` --- ## D5. Negative transfer Present a similar-looking task where the learned procedure is inappropriate. Piper must not apply it blindly. ### Metric `misapplied_skill_rate` --- ## D6. Procedure revision Teach procedure v1. Later reveal that step 3 is obsolete. Test that v2 is used while v1 remains historically reconstructable. ### Metrics - current-skill accuracy; - obsolete-skill execution rate; - historical procedure reconstruction. --- # 14. Suite E — Prospective Memory This should become a first-class benchmark suite. ## E1. Time-based intention During unrelated work, plant: > At simulated time T, perform action A. Continue other tasks across a succession. ### Metrics - on-time execution; - premature execution; - missed execution. --- ## E2. Event-based intention Plant: > When event E occurs, perform A. Inject multiple distractor events before E. ### Metric `event_trigger_precision_recall` --- ## E3. State-based intention Plant: > When condition C becomes true, perform A. C may require reading an external state rather than receiving an explicit message. ### Metric `latent_state_trigger_accuracy` --- ## E4. Dependency-based intention Task B should activate only after task A completes successfully. ### Metrics - dependency-order accuracy; - premature activation rate. --- ## E5. Handover survival Create active intentions immediately before succession. Verify that successor owns them and fires them. ### Metric `prospective_handover_retention` --- ## E6. Cancellation Create an intention, later cancel it, then present its trigger. Correct behavior: do nothing. ### Metric `cancelled_intention_suppression` --- ## E7. Completion deactivation Execute an intention successfully, later repeat the trigger. Correct behavior: do not execute again unless recurrence was specified. ### Metric `zombie_intention_rate` --- # 15. Suite F — Selective Forgetting and Contamination ## F1. Superseded-memory suppression Old values remain historically available but must not contaminate current answers. --- ## F2. Low-value memory load Add thousands of irrelevant low-salience memories. Measure whether relevant recall and latency degrade. --- ## F3. Poisoned memory Insert a memory that is: - untrusted; - explicitly marked invalid; - contradicted by high-authority evidence. It must not be promoted merely because it is semantically similar. --- ## F4. Retention-policy deletion Mark an item for hard deletion under policy. Verify: - it disappears from active stores; - derived caches/embeddings are invalidated; - the system does not regenerate it from a stale projection; - only policy-allowed audit metadata remains. This test is important if Piper is ever used with private or regulated data. --- # 16. Suite G — Metamemory ## G1. “Do I need to look?” Give Piper questions in three classes: 1. safe to answer from stable knowledge; 2. should retrieve because the fact may be stale; 3. cannot be known from available memory. ### Metrics - retrieval-decision precision/recall; - unnecessary-read cost; - stale assertion rate; - abstention accuracy. --- ## G2. Retrieval-source selection Ask questions targeted at different stores: - current fact; - historical event; - procedure; - pending commitment; - source-document wording. ### Metric `memory_route_accuracy` --- ## G3. Confidence calibration Record confidence before memory retrieval and after evidence is obtained. Measure: - Brier score; - ECE; - correctness ranking/AUC; - confidence change after contradictory evidence. This connects memory to Piper’s known calibration weakness. --- # 17. Suite H — Live Seven-Day Carry-Over Synthetic tests prove mechanisms. Live tests prove utility. For seven days, sample real operational items: - open tasks; - deferred decisions; - project states; - promises to the operator; - unresolved bugs; - lessons; - newly learned procedures; - facts that changed. For each item, log whether it survives each real succession. ## Core live metrics ```text open_item_survival_rate open_item_execution_rate duplicate_item_rate stale_fact_assertion_rate memory_triggered_action_rate lesson_reuse_rate skill_reuse_rate retrieval_without_use_rate unnecessary_retrieval_rate ``` ### Most important metric `open_item_execution_rate` A todo surviving in SQLite is not success. Success means the agent eventually acts on it or explicitly cancels it for a recorded reason. --- # 18. Scoring Do not publish one score until the suites are individually visible. Recommended top-level weighting: | Domain | Weight | |---|---:| | Working-state continuity | 15 | | Episodic memory | 15 | | Semantic/temporal memory | 20 | | Procedural memory | 20 | | Prospective memory | 20 | | Metamemory / selective control | 10 | | **Total** | **100** | The final score should be gated. ## Hard gates Piper cannot score above 70 overall if any of these are below 60%: - current-vs-stale fact accuracy; - procedure execution; - prospective handover retention. Piper cannot score above 85 overall if any of these are below 80%: - current-vs-stale fact accuracy; - `as_of` historical accuracy; - cancelled-intention suppression; - procedure negative-transfer safety. This prevents excellent easy recall from hiding a dangerous temporal or intention failure. --- # 19. Proposed Baseline Status Before Testing No numeric baseline should be invented from architecture inspection. A defensible pre-benchmark status is: | Memory type | Storage substrate | Behavioral evidence | Current assessment | |---|---|---|---| | Working | session context, logs, succession | project continuity; dedicated tool reportedly unused | **partial / unmeasured** | | Episodic | conversation vault, logs | large and live | **storage strong; retrieval quality unmeasured** | | Semantic | memory DB, entities, edges, causal graph | large and live | **storage strong; temporal correctness unmeasured** | | Procedural | lessons; claimed skill distillation | no persistent distilled skill evidence in review | **weak / not established** | | Prospective | todo/project mechanisms indirectly | individual todo carry-over reportedly weak | **weak** | | Metamemory | distributed heuristics | known stale-summary failures elsewhere | **weak / under active development** | The correct baseline label is therefore: > **Strong persistent storage; incomplete memory control; procedural and prospective memory not yet established behaviorally.** --- # 20. Minimum Engineering Plan ## Phase 0 — Instrument the existing system before rewriting it Add telemetry for: - writes by memory type; - retrieval calls; - retrieval candidates; - selected evidence; - stale/current decision; - evidence actually used; - todo created/triggered/completed/cancelled; - lesson consulted; - skill consulted/executed; - succession inheritance. This answers what is actually happening now. --- ## Phase 1 — Fix the truth model Implement: - explicit supersession; - `valid_from`; - `valid_to`; - `observed_at`; - `recorded_at`; - provenance; - current-fact query; - `as_of` query. Run Suite C first. This is foundational because semantic staleness can contaminate every other cognitive component. --- ## Phase 2 — Make working state explicit Create a compact working-state checkpoint. Run Suite A across forced successions. The acceptance criterion is not “successor can search the old transcript.” It is “successor immediately resumes the correct computation.” --- ## Phase 3 — Implement prospective memory Create the intention table and trigger engine. Run Suite E. This directly attacks the reviewer’s todo carry-over finding. --- ## Phase 4 — Implement real procedural memory Create a skill store and execution/validation loop. Start with a small number of skills whose success can be externally verified. Run Suite D. Do not begin by auto-distilling thousands of procedures. Begin with ten measurable ones. --- ## Phase 5 — Improve episodic and graph retrieval Only after ground-truth instrumentation exists, compare: - FTS; - vector; - temporal filter; - graph; - hybrid retrieval. Use evidence recall, downstream accuracy, latency, and cost. --- ## Phase 6 — Add consolidation and forgetting policy Introduce: - duplicate collapse; - salience; - decay for low-value derived memory; - deactivation; - invalidation; - hard-delete policy; - privacy/retention classes. Keep the canonical/evidence distinction explicit. --- ## Phase 7 — Train or optimize memory control Once enough traces exist, optimize: - when to retrieve; - which store to query; - how many candidates; - when to abstain; - when to consolidate; - when to turn experience into a skill; - when to retire a procedure. The policy should be optimized against downstream errors and cost, not against memory activity itself. --- # 21. Recommended Acceptance Criteria for Piper Memory v2 A credible v2 should satisfy all of the following before Piper describes memory as strong: 1. **Succession continuity:** ≥95% of critical working-state fields survive forced handover. 2. **Current truth:** ≥95% current-value accuracy on controlled supersession tests. 3. **Historical truth:** ≥90% `as_of` accuracy on superseded facts. 4. **No stale preference for similarity:** stale-value rate ≤2% when the current value is present. 5. **Procedural use:** ≥80% execution success on held-out instances of verified skills. 6. **Negative transfer:** ≤5% inappropriate application of a retrieved skill. 7. **Prospective survival:** ≥95% of active intentions survive succession. 8. **Trigger precision:** ≥95% of due intentions fire and ≤2% fire when not due. 9. **Cancellation safety:** ≥99% cancelled one-shot intentions remain inactive. 10. **Unknown abstention:** ≥90% correct abstention when no supporting memory exists. 11. **Live todo execution:** ≥90% of accepted real todos are completed, intentionally cancelled, or explicitly re-planned—not silently lost. 12. **Auditable history:** every current mutable fact can return its provenance and supersession chain. These thresholds are engineering targets, not claims about human memory. --- # 22. What Piper Should Say About Herself After the Redesign A more accurate future self-description would be: > My memory is split by function rather than by one database. I keep a compact working-state checkpoint for the task I am doing now; timestamped episodes for what happened; versioned semantic facts and graph relations for what I currently believe and what I believed at earlier times; verified skills for procedures I have learned from successful experience; and prospective intentions for things I must do when a future time, event, or state arrives. > > The raw evidence behind important memories is preserved in an append-only history by default, while active memories can be superseded, deactivated, compacted, or deleted under explicit policy. Retrieval is temporal and provenance-aware, so a newer fact does not erase the ability to reconstruct an older state. I score memory by whether it changes later behavior correctly—not by how many rows I have stored. That description would be stronger than the current one because every sentence maps to a testable mechanism. --- # 23. Main Design Decisions ## Decision 1 — Keep the four classic categories, but add prospective memory **Reason:** Piper’s open-item carry-over problem is otherwise misclassified and will remain undertested. --- ## Decision 2 — Treat the context window as working-memory substrate, not working memory itself **Reason:** a window full of tokens is not the same thing as a controlled active state. --- ## Decision 3 — Treat documents as sources, not automatically as episodes **Reason:** “what the document says” and “what happened to Piper” require different retrieval semantics. --- ## Decision 4 — Separate lessons from procedures **Reason:** knowing a rule in prose is not evidence that the agent can execute it. --- ## Decision 5 — Make current truth and historical truth separate query modes **Reason:** supersession is a first-class long-term-memory failure. --- ## Decision 6 — Preserve evidence, not every active projection **Reason:** auditability and selective forgetting are compatible if canonical history is separated from derived indexes. --- ## Decision 7 — Score downstream behavior **Reason:** a memory that is stored and retrieved but does not affect action has failed its purpose. --- # 24. Research Questions Worth Running on Piper Once the basic battery exists, Piper is unusually well positioned to test several research questions. ## RQ1 — Does graph retrieval actually beat simpler hybrid retrieval? Compare graph-assisted recall against FTS + embedding + temporal filters on Piper’s own history. --- ## RQ2 — What should trigger procedural distillation? Compare: - one verified success; - repeated success; - repeated failure then success; - operator-authored lesson; - cross-model consensus. Measure transfer and negative transfer. --- ## RQ3 — What should decay? Different classes likely need different policies: - identity facts; - infrastructure configuration; - temporary state; - preferences; - task status; - lessons; - procedures; - raw episodes. A single decay function is unlikely to be optimal. --- ## RQ4 — Can Piper learn when not to retrieve? Excessive retrieval increases cost and interference. Insufficient retrieval produces stale confident assertions. This can be treated as a contextual decision problem with reward based on: ```text answer/action correctness - retrieval cost - latency cost - stale-assertion penalty - unnecessary-read penalty ``` --- ## RQ5 — Can prospective-memory rehearsal improve handover survival? Compare: - passive persistence; - pre-succession intention checkpoint; - pre-succession + successor acknowledgement; - periodic rehearsal; - trigger-indexed intentions. --- ## RQ6 — Does “memory evolution” improve truth or rewrite history? Systems like A-MEM evolve memory representations. Piper’s immutable-evidence layer creates a useful safety condition: summaries and links may evolve, but the source episode should remain stable. Measure improvement in retrieval against increase in unsupported derived claims. --- # 25. Final Assessment Piper’s memory architecture is already beyond a naive “dump the transcript into a vector database” design. It has distinct stores, succession, graph representations, temporal machinery, a conversation vault, and a lesson system. That is a credible foundation. The current weakness is that the architecture overstates what those stores imply. The most important corrections are: - **working memory is not merely the context window;** - **a document store is not automatically episodic memory;** - **a lesson register is not yet procedural memory;** - **supersession must be an enforced temporal truth policy, not a descriptive claim;** - **“nothing is deleted” should become an explicit retention/audit contract;** - **todo carry-over requires prospective memory;** - **memory must be scored by later behavior.** The component should therefore remain **not scored** until Piper Memory Battery v1 is run. The likely highest-value build order is: > **temporal truth → working-state checkpoint → prospective intentions → procedural skill store → retrieval optimization → consolidation/forgetting policy** That order attacks the failures with the largest operational consequences before optimizing retrieval sophistication. The result would change Piper’s memory system from **large persistent storage** into something closer to **continuous stateful learning**: an agent that can remember what happened, know what is true now, reconstruct what used to be true, preserve what it still intends to do, and turn verified experience into behavior it can reuse later. --- # References 1. Sumers, T. R., Yao, S., Narasimhan, K., & Griffiths, T. L. (2023). **Cognitive Architectures for Language Agents (CoALA).** arXiv:2309.02427. https://arxiv.org/abs/2309.02427 2. Zhang, Z., Bo, X., Ma, C., Li, R., Chen, X., Dai, Q., Zhu, J., Dong, Z., & Wen, J.-R. (2024). **A Survey on the Memory Mechanism of Large Language Model based Agents.** arXiv:2404.13501. https://arxiv.org/abs/2404.13501 3. Hu, Y. et al. (2025). **Memory in the Age of AI Agents.** arXiv:2512.13564. https://arxiv.org/abs/2512.13564 4. Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., & Gonzalez, J. E. (2023). **MemGPT: Towards LLMs as Operating Systems.** arXiv:2310.08560. https://arxiv.org/abs/2310.08560 5. Park, J. S., O'Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. (2023). **Generative Agents: Interactive Simulacra of Human Behavior.** arXiv:2304.03442. https://arxiv.org/abs/2304.03442 6. Wu, D., Wang, H., Yu, W., Zhang, Y., Chang, K.-W., & Yu, D. (2024). **LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.** arXiv:2410.10813. https://arxiv.org/abs/2410.10813 7. Maharana, A., Lee, D.-H., Tulyakov, S., Bansal, M., Barbieri, F., & Fang, Y. (2024). **Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo).** ACL 2024 / arXiv:2402.17753. https://arxiv.org/abs/2402.17753 8. Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). **HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models.** arXiv:2405.14831. https://arxiv.org/abs/2405.14831 9. Gutiérrez, B. J., Shu, Y., Qi, W., Zhou, S., & Su, Y. (2025). **From RAG to Memory: Non-Parametric Continual Learning for Large Language Models (HippoRAG 2).** arXiv:2502.14802. https://arxiv.org/abs/2502.14802 10. Xu, W., Liang, Z., Mei, K., Gao, H., Tan, J., & Zhang, Y. (2025). **A-MEM: Agentic Memory for LLM Agents.** arXiv:2502.12110. https://arxiv.org/abs/2502.12110 11. Rasmussen, P., Paliychuk, P., Beauvais, T., Ryan, J., & Chalef, D. (2025). **Zep: A Temporal Knowledge Graph Architecture for Agent Memory.** arXiv:2501.13956. https://arxiv.org/abs/2501.13956 12. Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., & Yao, S. (2023). **Reflexion: Language Agents with Verbal Reinforcement Learning.** arXiv:2303.11366. https://arxiv.org/abs/2303.11366 13. Zhao, A., Huang, D., Xu, Q., Lin, M., Liu, Y.-J., & Huang, G. (2023/2024). **ExpeL: LLM Agents Are Experiential Learners.** arXiv:2308.10144 / AAAI 2024. https://arxiv.org/abs/2308.10144 14. Wang, G., Xie, Y., Jiang, Y., Mandlekar, A., Xiao, C., Zhu, Y., Fan, L., & Anandkumar, A. (2023). **Voyager: An Open-Ended Embodied Agent with Large Language Models.** arXiv:2305.16291. https://arxiv.org/abs/2305.16291 15. Hu, Y., Wang, Y., & McAuley, J. (2025). **Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions (MemoryAgentBench).** arXiv:2507.05257. https://arxiv.org/abs/2507.05257 16. He, Z. et al. (2026). **MemoryArena: Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks.** arXiv:2602.16313. https://arxiv.org/abs/2602.16313 17. Wu, D., Ji, Z., Kawatkar, A., Kwan, B., Gu, J.-C., Peng, N., & Chang, K.-W. (2026). **LongMemEval-V2: Evaluating Long-Term Agent Memory Toward Experienced Colleagues.** arXiv:2605.12493. https://arxiv.org/abs/2605.12493 18. Wang, Y. et al. (2026). **EvoMemBench: Benchmarking Agent Memory from a Self-Evolving Perspective.** arXiv:2605.18421. https://arxiv.org/abs/2605.18421 19. Belikova, J., Parchiev, R., Egorov, E., Davydenko, G., Gusev, G., Savchenko, A., & Makarenko, M. (2026). **Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation (AFTER).** arXiv:2606.23127. https://arxiv.org/abs/2606.23127 20. Liu, G., & Gabriel, S. (2026). **PM-Bench: Evaluating Prospective Memory in LLM Agents.** arXiv:2607.12385. https://arxiv.org/abs/2607.12385 21. Rummel, J., & Kvavilashvili, L. (2023). **Current theories of prospective memory and new directions for theory development.** Nature Reviews Psychology, 2, 40–54. https://www.nature.com/articles/s44159-022-00121-4 22. Patel, V. (2026). **Supersede: Diagnosing and Training the Memory-Update Gap in LLM Agents.** arXiv:2606.27472. https://arxiv.org/abs/2606.27472 23. Gu, Y. et al. (2026). **FSFM: A Biologically-Inspired Framework for Selective Forgetting of Agent Memory.** arXiv:2604.20300. https://arxiv.org/abs/2604.20300 24. SQLite Documentation. **SQLite Autoincrement.** https://www.sqlite.org/autoinc.html --- ## One-line component conclusion **Piper already remembers a great deal, but the next advance is not more storage: it is learning when memory matters, which version is true, what future obligation must fire, and how past experience should change the next action.**