Critique: Designing a Memory System for LLM-Based Agents

Target: Designing a Memory System for LLM-Based Agents

This critique looks for conflicts and under-resolved tensions against the KB's current theories and evidence. The note is directionally aligned with the strongest local claims: context is scarce, session history should be retained separately from next-context loading, memory splits into storage / activation / learning, and system-definition artifacts are the cheap behavior-change substrate. The main weaknesses are not that the architecture is wrong, but that it sometimes states design choices more firmly than the current evidence supports.

Summary judgment

The design study is a good synthesis, but it currently overcommits or under-specifies in three places:

1. Store-everything is treated as an architectural premise before the full memory-system requirements model exists.
2. The four-layer architecture is presented as problem-driven necessity, but the evidence supports only weaker claims: progressive disclosure, candidate/library separation, and trace retention.
3. Activation is treated mostly as cue retrieval plus imperative framing, while recent evidence says live-context presence and compressed-memory presence still do not guarantee behavioral uptake.

Those are revision issues, not fatal conflicts. The note should become more explicit about where it is proposing a design hypothesis, where the KB already has evidence, and where the open evaluation loop remains unsolved.

1. Store-everything exposes a requirements gap beyond the library layer

The note starts from a "store everything" premise: storage is cheap, context is scarce, and the real work is selective retrieval. This matches session history should not be the default next context: persistence and next-context loading are separate decisions. It also matches distillation is transformation, not selection: retaining the raw trace preserves material for future redistillation.

The tension is with the reopened input-vs-output-driven memory workshop, but it should be stated more carefully than "store-everything conflicts with output-driven design." The current KB's mature output spec is mostly library-layer shaped: purpose, domain, include/exclude rules, type system, collection registers, and note quality bars govern durable knowledge artifacts well. They do not yet specify every output a full agent-memory system must produce.

That means the problem is not "input-driven capture is wrong." A broader memory system needs input-driven trace capture because later consumers are hard to predict. The problem is that trace capture is only one layer of the design. A complete requirements model must also name the consumers and outputs beyond the library:

• Library readers need durable notes, ADRs, indexes, source reviews, and explanations.
• Active task agents need current workshop state, plans, constraints, and task-local context.
• Context schedulers need compact metadata, priority scores, budget rules, and loading policies.
• Extraction pipelines need schemas for corrections, preferences, decisions, silent failures, procedures, and discoveries.
• Activation machinery needs cues, trigger conditions, action signatures, priority arbitration, and faithfulness checks.
• Compiled policy surfaces need generated or maintained AGENTS.md, skills, checks, scripts, always-loaded instructions, and runtime guardrails.
• Governance workflows need retention, redaction, authority, promotion, retirement, and evaluation rules.

The target note partly acknowledges this by calling store-everything a bet, not an axiom, but then treats the bet as the foundation for the rest of the architecture. It should instead say: broad trace capture preserves optionality, while the full memory-system requirements model governs extraction, promotion, retention, activation, compilation, and evaluation. The current KB has strong language for the library layer; this design is implicitly asking us to expand that language to the rest of the memory system.

Suggested revision:

• Reframe "store everything" as a capture substrate or bootstrap posture, not the full memory-design principle.
• Add a "requirements surfaces" section that names the consumers above and what each requires from the memory system.
• Explicitly distinguish "store raw traces broadly" from "mine everything equally." Trace retention preserves optionality; extraction and promotion still need consumer-specific criteria.
• State that the KB's current output-driven rules are library-layer requirements, not yet a complete specification for trace, workshop, observation, episode, activation, compiled-policy, and governance layers.

2. Raw traces are too strongly excluded from agent consumption

The note says the trace layer is for provenance and offline extraction, and "the agent never loads raw traces into a working context." That is too strong relative to the evidence the note itself cites.

Large Language Model Agents Are Not Always Faithful Self-Evolvers found that agents often depend on raw experience more reliably than condensed summaries, and that condensed memories can be ignored or misread. The ingest's extractable value is not "always use raw traces," but it does say compressed artifacts are not drop-in substitutes for replayable detail. Meta-Harness, also cited by the target note, is another case where raw execution traces remain valuable for later optimization.

The target note is right that raw traces should not be default task context. But "never" collapses two different consumers:

• The acting task agent should usually receive distilled artifacts, cues, and linked knowledge.
• The review, debugging, synthesis, or evaluation agent may need raw trace excerpts precisely because the distillate is under suspicion.

Suggested revision:

• Replace "the agent never loads raw traces" with a narrower rule: raw traces are not default action context, but may be loaded deliberately for provenance checks, faithfulness audits, debugging, dispute resolution, and redistillation.
• Add "trace excerpt loading" as an exceptional retrieval path with a higher budget and stronger framing.

3. Four layers are plausible, not established

The four layers -- trace, observation, episode, library -- are clean and useful. The evidence base, however, supports a weaker conclusion than "four layers, not fewer or more."

The comparative review establishes several convergences: progressive disclosure, the agency trilemma, the retrieval/navigation split, and the extraction-over-synthesis asymmetry (agentic memory systems comparative review). Trace-derived learning techniques in related systems shows recurring stages: trigger, source format, extraction schema, promotion/storage, reinjection. ClawVault has observations and weekly reflections; cass-memory has diaries and playbook deltas; Synapptic has weighted YAML profiles and guard compilation; AgeMem splits active/long-term memory but learns the management policy in weights. These systems support staged distillation, but not one necessary four-layer decomposition.

The target note's argument against three layers is conceptual: atomic lookup and narrative retrieval have different indexing strategies. That is a good design reason, but it is not yet empirical evidence that a separate episode layer must exist in all or most implementations. Some systems could store observations and episodes in one typed substrate with separate views, or use workshop artifacts as the narrative layer.

Suggested revision:

• Present the four-layer architecture as the design hypothesis this note recommends, not as a demonstrated necessity.
• Separate the claim "atomic and narrative memory need distinct retrieval interfaces" from the stronger claim "they require distinct layers."
• Add an evidence note: reviewed systems support progressive disclosure and typed promotion pathways; the exact layer count remains an implementation choice.

4. The episode layer under-specifies the active workshop problem

The note's "episode" is retrospective: a compressed account of a bounded work unit after it happened. But the KB's workshop layer theory says a functioning KB also needs work in motion: decision threads, experiments, queues, session logs, collaborative threads, tasks, and other artifacts with state machines and expiration.

That creates a gap. The target architecture has trace for raw history, observation for atomic extraction, episode for compressed narrative, and library for durable artifacts. It does not clearly model active workshop documents that are neither raw trace nor retrospective episode nor durable library. The note later discusses "normal durable work surfaces," but the active work surface is not given a place in the four-layer memory model.

This matters because many graduation paths originate from active work artifacts, not directly from traces. A decision thread can produce an ADR; an experiment can produce a note or nothing; a task can produce code plus an extracted procedure. Treating all of that as either trace or episode loses the stateful process structure the workshop-layer note says is missing from the current type system.

Suggested revision:

• Add an explicit distinction between retrospective episodes and active workshop artifacts.
• Either add workshop/work-surface artifacts as adjacent to the four memory layers, or say the four layers describe retrospective memory only and do not replace the active work surface.
• Use this to clarify whether "episode" is a memory artifact, a workshop artifact, or a compiled view over workshop state.

5. Activation needs behavioral faithfulness tests, not just cue firing

The note's activation design follows knowledge storage does not imply contextual activation: cue match, priority arbitration, and commitment. Typed cue indexes, imperative framing, checkpoint insertion, and contradiction surfacing are the right family of mechanisms.

The conflict is that the note treats these mechanisms as if getting the cue into context is close to solving commitment. Newer evidence is harsher. Agents Explore but Agents Ignore shows that even when a complete solution is present in the live environment and discovered, agents often fail to integrate it into the task or plan. Large Language Model Agents Are Not Always Faithful Self-Evolvers shows that condensed memories can improve systems without being causally used in the way their designers assume.

So the activation pipeline needs a fourth evaluation concept: behavioral faithfulness. Did the surfaced memory actually change the downstream action, and did it change it for the intended reason?

Synapptic is the strongest reviewed practical example here: it runs per-guard WITH/WITHOUT ablations and excludes guards that are redundant, ineffective, or backfire (Synapptic). The oracle is still imperfect, but the loop directly tests whether a behavior rule earns prompt budget. The target note does not yet incorporate that standard.

Suggested revision:

• Add behavioral faithfulness as an evaluation requirement for system-definition cues.
• Require WITH/WITHOUT or perturbation tests for cues promoted into always-loaded or high-priority activation surfaces.
• Make "commitment" less about imperative wording alone and more about measured causal uptake.

6. Store-everything underplays retention, redaction, and retirement

The note acknowledges privacy exposure and search-pollution risk, but the architecture does not give them first-class machinery. That is a conflict with several local lessons:

• Notes need quality scores to scale curation says ranking and status are needed once candidate volume grows.
• The comparative review's curation section says every serious memory system needs operations for updating, invalidating, evolving, or retiring knowledge.
• The REM review flags a missing forgetting policy as a concrete implementation gap, even where schema fields for active/superseded exist.
• Synapptic's trace pipeline scrubs secrets before LLM extraction, making redaction part of capture rather than an afterthought.
• The trajectory-informed memory ingest explicitly lists "no tip lifecycle or retirement" as a limitation.

The target note says premature graduation is worse than late graduation because every graduated artifact creates a maintenance obligation. That is correct, but it shifts the maintenance issue upward to the library while leaving lower layers too append-only. Raw traces also create obligations: privacy, legal retention, user-requested deletion, secret handling, index poisoning, and obsolete cue decay.

Suggested revision:

• Add trace-layer redaction and retention policy as part of the minimum architecture, not a later operational concern.
• Add observation-level decay, supersession, duplicate handling, and retirement as normal lifecycle fields.
• Treat "store everything" as "store everything eligible under retention and redaction policy."

7. Role and lifecycle tags are right, but source-of-truth rules are missing

The note's role axis is one of its strongest moves. It imports axes of artifact analysis cleanly: the same artifact can be consumed as knowledge or as system-definition depending on use. The lifecycle tag is also useful.

The missing piece is source-of-truth control for library-to-observation backflow. The note says a library artifact may need a companion cue so it fires by situation match. That is correct, but once a cue is generated from a library artifact, there are now two policy surfaces:

• the library artifact that explains or authorizes the policy
• the cue index entry that operationalizes it

If the library artifact changes, the cue can become stale. If the cue is edited directly, it can drift away from the rationale. This is especially risky because system-definition artifacts are behavior-changing, not just references.

Suggested revision:

• Treat cue indexes derived from library prose as compiled views, not independent sources of truth.
• Add provenance, source hash, and regeneration rules for library-derived cues.
• Say direct cue edits are allowed only for candidate observations that have not yet graduated to a library-owned policy.

8. The note broadens beyond software, but many mechanisms still assume software-like surfaces

The note says library can mean notes, manuals, policies, decision records, procedures, checks, or agent instructions, and later broadens to "normal durable work surfaces." That is an improvement over software-only framing.

But several proposed mechanisms still depend on software-like affordances: action signatures, destructive-operation checks, tests, scripts, migrations, runbooks, source-quality checks, and deploy-time policies. Those are not wrong, but they are not equally available in research advising, personal assistance, creative work, or organizational memory.

The KB's broader theory says transfer from one source discipline must be tested by failure mode, not analogy. Psychology-to-agent transfer needs per-principle failure-mode testing makes that standard explicit. The same standard should apply here: the design should state which prerequisites a domain needs before typed cue indexes and promotion thresholds work.

Suggested revision:

• Add a "domain prerequisites" subsection: observable traces, identifiable actions, durable work surfaces, evaluable outcomes, recurring task families, and authority to modify system-definition artifacts.
• Mark software/project work as the reference domain, then state which mechanisms are expected to generalize and which require adaptation.

9. The agency trilemma is diagnosed but not resolved into design authority

The note names the agency trilemma: agent-managed memory has context but burns reasoning tokens; external services scale but guess what matters; human co-management has quality but low throughput. The proposed architecture implicitly chooses an external/post-hoc extraction pipeline plus human review for promotion.

That choice should be made explicit. Without an authority model, the architecture does not say who can promote a cue into system-definition, who can retire a stale cue, who approves always-loaded instruction changes, or when an agent can write directly into the durable layer. Those are not implementation details; the comparative review identifies agency as the most consequential dimension.

Suggested revision:

• Add an "authority model" section mapping each transition to its decision-maker: extractor, scheduler, human reviewer, test oracle, or learned policy.
• Separate low-risk observation writes from high-risk system-definition writes.
• Require stronger review/evaluation for writes that change always-loaded or high-priority behavior.

Highest-value revisions

1. Recast "store everything" as trace-retention bias inside a broader memory-system requirements model, not as the design's whole value criterion.
2. Weaken "four layers are required" to "four layers are the proposed design because they separate atomic lookup, narrative recall, and durable curation."
3. Add active workshop/work-surface artifacts as adjacent to retrospective episodes.
4. Add behavioral faithfulness testing for cues and condensed memories.
5. Add source-of-truth and compilation rules for library-derived cue indexes.
6. Add domain prerequisites and an explicit authority model.

Candidate extracted claims

These might deserve companion notes if they survive revision:

• Store-everything is a capture posture, not a complete memory design. Full memory-system requirements must cover library, workshop, trace, observation, episode, activation, compiled-policy, and governance consumers.
• Episodes are retrospective memory; workshops are active memory. A complete agent memory system needs both narrative recall and stateful work-in-motion artifacts.
• Cue activation needs behavioral faithfulness testing. A cue that fires but does not causally change action has not closed the activation gap.
• Library-derived cues should be compiled views. System-definition indexes generated from library prose need provenance and regeneration, or they become divergent policy surfaces.