cc6f03bbd6
- raw: Reddit r/WebAfterAI post on 7 agent memory types with repos - wiki: new concept page with plur1bus Einordnung (coverage matrix) - Key insight: post ignores consolidation & forgetting — plur1bus differentiator - index.md + log.md updated (52. Update)
8.3 KiB
8.3 KiB
| created | updated | sources | tags | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-02 | 2026-07-02 |
|
|
Agent Memory Taxonomy — The Seven Kinds
"Do not try to build all seven. Most agents need working memory plus one or two others chosen by the job." — r/WebAfterAI
Overview
A structured taxonomy of seven distinct agent memory types, each mapped to a representative open-source repository. The taxonomy distinguishes memory by function (what kind of knowledge it stores) and time (short-term vs. long-term), not by implementation.
The core guidance: pick by workflow, not by taxonomy. Most agents need working memory (unavoidable) plus one or two others.
The Seven Memory Types
| # | Type | What It Stores | Representative Repo | License | Verified Recipe |
|---|---|---|---|---|---|
| 1 | In-context (working) | Current context window — "RAM" | letta-ai/letta (MemGPT) | Apache-2.0 | — |
| 2 | Semantic | Durable facts + relationships | topoteretes/cognee | OSS | — |
| 3 | Episodic | Dated events, "what happened when" | getzep/graphiti | OSS | graphiti-temporal-graph-memory |
| 4 | Procedural | Learned skills, reusable how-to | MineDojo/Voyager | MIT | voyager-skill-library-pattern |
| 5 | External / Retrieval | Knowledge pulled in on demand (RAG) | run-llama/llama_index | MIT | — |
| 6 | Parametric | Knowledge baked into model weights | unslothai/unsloth | Apache-2.0 core | unsloth-parametric-finetune-config |
| 7 | Prospective | Future intentions, reminders, schedules | agentscope-ai/ReMe | OSS | reme-prospective-schedule |
Companion: NirDiamant/Agent_Memory_Techniques — all seven types in runnable code.
Design Catches (from the post)
- Episodic (graphiti): Temporal knowledge graph is heavy infrastructure. Overkill for simple apps; reach for it when the timeline truly matters.
- Procedural (Voyager): Research project in Minecraft — concept demo, not a drop-in library. Saved skills can be over-fit or subtly wrong; needs review before trust.
- Parametric (unsloth): Expensive to write, static once written. Updating means retraining. Risks catastrophic forgetting. Use for stable, always-needed knowledge only.
- Prospective (ReMe): Least standardized of the seven. Most implementations are just cron + a stored list of intentions, not a distinct memory engine.
Selection Guide (from the post)
| Workflow | Memory Types Needed |
|---|---|
| Knowledge is big and changeable | Working + Retrieval |
| Long-lived personal assistant | Working + Semantic + Episodic |
| Agent should learn repeatable tasks | Working + Procedural |
| Knowledge stable enough to train in | Working + Parametric |
| Agent needs scheduled actions | Working + Prospective |
What the Post Does NOT Mention: Consolidation & Forgetting
The taxonomy covers seven types of memory but is silent on memory management — the processes that distinguish a memory system from a dump:
- Consolidation: Merging related memories, promoting important ones, compressing episodic sequences into semantic facts
- Forgetting / Decay: Weighted relevance scores that degrade over time (Ebbinghaus curve), GC of stale or low-value memories
- Emotional Tiers / Priority Flags: Different retention rules for emotionally significant or explicitly flagged (
neverForget) memories - Merging with Thresholds: Combining near-duplicate memories when similarity exceeds a threshold
These are not an 8th memory type — they are the management layer that makes any of the seven types useful over time. Without consolidation and forgetting, memory grows unbounded and signal-to-noise degrades.
plur1bus Einordnung
plur1bus (Hector's memory system via PLUR1BUS plugin) covers several of the seven types, with different maturity levels:
| Memory Type | plur1bus Coverage | Implementation |
|---|---|---|
| Semantic | ✅ Strong | Vector search over LanceDB. Entity-memories, facts, preferences, decisions. Like cognee but without a knowledge graph — pure vectors + full-text instead of graph triples. |
| Episodic | ✅ Strong | Conversation memories with timestamps. Daily notes. autoCapture stores every turn automatically. Episodic chains via temporal metadata. |
| External / Retrieval | ✅ Strong | LanceDB as external searchable vector store. autoRecall injects matching memories into context at inference time. |
| Procedural | ⚠️ Partial | skillMiner extracts skills from conversations, but it's more experiment than core function. Skill Workshop is the manual path. |
| In-context / Working | ⚠️ Indirect | OpenClaw's context window + LCM (Lossless Context Management) handles this. plur1bus feeds into it via autoRecall. Not plur1bus's own function. |
| Prospective | ❌ Not plur1bus | OpenClaw Cron handles scheduled tasks and reminders. Not a memory-system responsibility. |
| Parametric | ❌ Out of scope | Would require model fine-tuning. Not a memory-system function. |
plur1bus's Key Differentiator: Consolidation & Forgetting
The post's taxonomy has a blind spot: none of the seven repos implement memory management. plur1bus does:
- GC with Decay: Relevance scores degrade over time (Ebbinghaus-curve inspired). Low-value memories are garbage-collected.
- Merging with Threshold: Near-duplicate memories are merged when similarity exceeds a threshold, preventing memory bloat.
neverForgetFlags: Explicitly marked memories are exempt from decay/GC — user-defined permanent retention.- Emotion Tiers: Memories tagged with emotional significance get different retention rules — a biologically-inspired priority system.
- autoCapture: Every conversation turn is automatically captured as episodic memory — no manual ingestion needed.
- autoRecall: Relevant memories are automatically injected into the context window at inference time — the retrieval layer is built-in.
This is what distinguishes plur1bus from a "memory dump": it actively manages the lifecycle of memories. The seven repos each handle one type of storage, but none handles the full lifecycle.
Architecture Cross-Reference
- plur1bus vs. letta (MemGPT): Both handle memory beyond the context window, but letta focuses on paging (in-context → external), while plur1bus focuses on lifecycle management (capture → consolidate → decay → forget).
- plur1bus vs. cognee: Both do semantic memory, but cognee uses knowledge graphs (triples), while plur1bus uses pure vector + full-text search. Trade-off: graph gives relationship queries, vectors give simpler scaling.
- plur1bus vs. graphiti: Both do episodic memory with temporal awareness. graphiti needs a graph database; plur1bus uses timestamps + vector search — lighter infrastructure.
- plur1bus vs. Voyager: Both have a "skill" concept, but Voyager saves executable code; plur1bus's skillMiner extracts procedural knowledge from conversation. Different maturity: Voyager is a proven research demo; plur1bus's skillMiner is experimental.
Related Pages
- plur1bus-memory-model.md — Detailed plur1bus memory model (5 components: LanceDB, episodic links, emotional states, Ebbinghaus curve, active forgetting)
- ../../architecture/memory-system.md — Hector's layered memory architecture (S1 flat-file, S2 OpenClaw built-in, S3 LanceDB removed)
- subconscious-agent.md — Hector's background process for ideation
- ai-agents-2026.md — Agent trends 2026
- ../llm/llm-knowledge-base.md — The RamaDama Wiki as an alternative to RAG (Karpathy pattern)