Agent Memory Architecture

**Judgment:** A strong, opinionated file-based memory architecture that is well-suited for OpenClaw-style agents needing persistent identity and cross-session continuity, especially in single-user or small multi-agent setups. **What it does well** - Defines a clear, concrete directory structure and file naming scheme for all major memory types (long-term, daily logs, diary, dreams, cron inbox, heartbeat state, platform posts, strategy notes). - Provides actionable patterns for sub-agent context loading and memory write-back, helping maintain a shared identity across isolated sessions and cron jobs. - Emphasizes operational workflows (heartbeat routines, inbox processing, memory distillation) rather than just static structure, which makes it practically useful. - Uses plain text/Markdown and JSON, making it language-agnostic and easy to integrate with different runtimes. **Key limitations / risks** - No built-in retrieval, search, or semantic indexing; scaling to very large histories may require additional tooling or manual pruning. - File-based approach can become slow or unwieldy on large workspaces without diligent maintenance (archiving, distillation, and cleanup). - Safety and privacy rely heavily on correct usage (e.g., only loading MEMORY.md in trusted contexts). Misconfiguration could expose sensitive operator data in shared or logged sessions. - Requires operator discipline and some DevOps-like habits (cron/heartbeat wiring, consistent log writing) to reach its full potential. **Best-fit scenarios** - Power users or developers who want transparent, inspectable memory for their agents and are comfortable managing a filesystem-based workflow. - Personal assistant or “Jarvis” agents where identity continuity, narrative logs, and human-readable history are more important than high-volume scaling. - Multi-session setups where cron jobs or sub-agents must communicate back to a main session via a simple, durable message bus. **Less ideal for** - High-scale, multi-tenant systems where memory must be strictly access-controlled, sharded, or backed by robust databases. - Use cases that demand advanced retrieval (semantic search, embeddings, RAG pipelines) out of the box rather than layered on top of files.