Agent Memory
A comprehensive subsystem for data storage, filtering, and retrieval that transforms stateless LLM calls into a stateful system: from short-term scratchpad buffers to multi-session knowledge repositories.
1. Concept Overview & Systemic Problem
Without a systemic memory, each run of an autonomous agent is completely isolated (stateless). The model is constrained by the physical size of the Context Window Limit and loses all conclusions, corrected errors, and user settings after the session ends.
Attempting to solve this directly—by sending the entire history ahead of each prompt—leads to three critical engineering deadlocks:
- Exponential growth of token costs and delays (Time to First Token).
- Model attention degradation (Lost-in-the-Middle): bloated context dilutes the Self-Attention mechanism, causing critical instructions to be missed.
- Lack of learning from mistakes: the agent repeatedly encounters the same bugs in the codebase that it has already resolved in previous sessions.
The Agent Memory architecture separates state preservation into specialized layers, providing the agent with long-term memory while minimizing token usage.
2. Architectural Taxonomy & Mental Model
In modern agent engineering, memory is standardized into four functional layers:
- 1. Short-Term (Working / Scratchpad Memory): The operational buffer for the current iteration (ReAct loop). It stores intermediate thoughts, tool call arguments, and responses from the system environment. It exists only for the lifecycle of the current task (in process memory or Redis).
- 2. Episodic Memory: A chronicle of the agent's past experiences: sequences of actions, attempts to complete tasks, reasons for test failures, and identified fixes. It allows the agent to recall: “I tried to perform the migration this way yesterday, and encountered a deadlock—I'll choose a different path.”
- 3. Semantic Memory: A repository of extracted knowledge, facts, and entities about the surrounding world, the user, and the repository. It is implemented as a structured fact database (Knowledge Graph) or a vector database with embeddings.
- 4. Procedural Memory:
The agent's "muscle memory": algorithms, fixed workflows, syntax for custom tools, code formatting rules, and system instructions (including repository
.agents/skillsand.agents/rules).
3. Technical Pipeline & Internal Mechanics
The memory lifecycle of an autonomous agent is realized through a 4-stage pipeline:
- Extraction & Filtering: A lightweight LLM parser or heuristic extractor analyzes the completed dialogue or tool step. It filters out communication noise (“thank you,” “understood”) and extracts atomic facts.
- Hybrid Indexing: The obtained entities are recorded in a storage with dual indexing: dense vectors (Dense Embeddings) for content-based search + BM25/full-text index for precise matching of identifiers, functions, and constants.
- Context-Aware Retrieval:
Before generating the next response, a ranker computes an integral relevance score for the memory recall using the formula:
Score = w1 * Relevance + w2 * Recency (exponential decay) + w3 * Importance. Only the top-$K$ most relevant fragments are loaded into the working prompt. - Memory Compaction & Consolidation: A periodic process condenses old episodic chains into high-level conclusions (Recursive Summarization), freeing up resources in the knowledge base.
4. Production Engineering Scenarios
01. Developer Personalized Context
The agent automatically captures and stores rules specific to a developer: for example, the use of strict TypeScript, error handling through Result<T, E>, aversion to seeing any, or preference for certain state libraries, eliminating the need to repeat these in every chat.
02. Architectural Context of the Codebase
Retention of decisions made weeks ago: “Why is a Redis Streams queue used in the billing module instead of a direct HTTP call?” The agent checks the semantic memory of the repository before suggesting risky refactoring.
03. State Synchronization Between Sub-Agents
In Multi-Agent architectures (e.g., orchestrator -> coder -> tester), shared state memory allows the testing agent to instantly pull all hypotheses from the architect agent without fully transferring raw logs.
5. Pitfalls, Common Mistakes & Security
- Context Poisoning: If the agent records a hallucination as valid knowledge, it will repeat this error in all future sessions. Protection: fact validation through a separate verification step and an explicit ability to delete false memories via UI/command.
- Retrieval Dilution: An excessively low similarity threshold leads to the loading of dozens of irrelevant memories, displacing the user's relevant instructions.
- Secret Leakage: Storing sensitive data (API keys, passwords from logs, tokens) in long-term storage. Protection: mandatory sanitization layer (Secret Redaction Regex/Entropy detection) at the pre-save hook level of memory.
FAQ: Agent Memory
Related terms
Context Rot & Attention Decay
Systemic degradation of accuracy, instruction adherence, and logical consistency in LLMs as dialog noise, outdated code drafts, and compiler outputs accumulate in the working context window.
Vector Databases (Vector DBs & ANN Search)
Specialized DBMS and extensions (Qdrant, pgvector, Milvus, Chroma, Turso) optimized for storing millions of high-dimensional vectors and ultra-fast Approximate Nearest Neighbors (ANN) search.
Embedded Databases (SQLite & Turso / libSQL)
Embedded (In-Process) relational database technology based on SQLite and the distributed fork libSQL (Turso), combining operation without a dedicated network server with sub-millisecond read speeds.
AI Agents (Autonomous Agents)
Software systems based on LLMs that can autonomously perceive the state of the environment, decompose complex goals, invoke external tools, and iteratively correct their own mistakes.