Skip to main content

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:

  1. Exponential growth of token costs and delays (Time to First Token).
  2. Model attention degradation (Lost-in-the-Middle): bloated context dilutes the Self-Attention mechanism, causing critical instructions to be missed.
  3. 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/skills and .agents/rules).

3. Technical Pipeline & Internal Mechanics

The memory lifecycle of an autonomous agent is realized through a 4-stage pipeline:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
/ Frequently Asked QuestionsSchema.org FAQPage

FAQ: Agent Memory

Vector RAG provides only semantic search of static documents. True agent memory includes episodic error tracking, working state (Scratchpad/Checkpointer), temporal relevance assessment (Recency/Decay), and automatic fact updating and invalidation.
/ Internal links
All terms