Comparing Memory Systems for LLM Agents: Vector, Graph, and Event Logs

Reliable multi-agent programs are largely a reminiscence design drawback. Once brokers name instruments, collaborate, and run lengthy workflows, you want express mechanisms for what will get saved, how it’s retrieved, and how the system behaves when reminiscence is improper or lacking.

This article compares 6 reminiscence system patterns generally utilized in agent stacks, grouped into 3 households:

• Vector reminiscence
• Graph reminiscence
• Event / execution logs

We concentrate on retrieval latency, hit fee, and failure modes in multi-agent planning.

High-Level Comparison

Family	System sample	Data mannequin	Strengths	Main weaknesses
Vector	Plain vector RAG	Embedding vectors	Simple, quick ANN retrieval, extensively supported	Loses temporal / structural context, semantic drift
Vector	Tiered vector (MemGPT-style digital context)	Working set + vector archive	Better reuse of necessary information, bounded context dimension	Paging coverage errors, per-agent divergence
Graph	Temporal KG reminiscence (Zep / Graphiti)	Temporal information graph	Strong temporal, cross-session reasoning, shared view	Requires schema + replace pipeline, can have stale edges
Graph	Knowledge-graph RAG (GraphRAG)	KG + hierarchical communities	Multi-doc, multi-hop questions, international summaries	Graph development and summarization bias, traceability overhead
Event / Logs	Execution logs / checkpoints (ALAS, LangGraph)	Ordered versioned log	Ground fact of actions, helps replay and restore	Log bloat, lacking instrumentation, side-effect-safe replay required
Event / Logs	Episodic long-term reminiscence	Episodes + metadata	Long-horizon recall, sample reuse throughout duties	Episode boundary errors, consolidation errors, cross-agent misalign

Next, we go system household by system household.

1. Vector Memory Systems

1.1 Plain Vector RAG

What it’s?

The default sample in most RAG and agent frameworks:

• Encode textual content fragments (messages, instrument outputs, paperwork) utilizing an embedding mannequin.
• Store vectors in an ANN index (FAISS, HNSW, ScaNN, and so on.).
• At question time, embed the question and retrieve top-k nearest neighbors, optionally rerank.

This is the ‘vector retailer reminiscence’ uncovered by typical LLM orchestration libraries.

Latency profile

Approximate nearest-neighbor indexes are designed for sublinear scaling with corpus dimension:

• Graph-based ANN buildings like HNSW usually present empirically near-logarithmic latency development vs corpus dimension for fastened recall targets.
• On a single node with tuned parameters, retrieving from as much as thousands and thousands of things is often low tens of milliseconds per question, plus any reranking price.

Main price parts:

• ANN search within the vector index.
• Additional reranking (e.g., cross-encoder) if used.
• LLM consideration price over concatenated retrieved chunks.

Hit-rate conduct

Hit fee is excessive when:

• The question is native (‘what did we simply discuss’), or
• The info lives in a small variety of chunks with embeddings aligned to the question mannequin.

Vector RAG performs considerably worse on:

• Temporal queries (‘what did the consumer determine final week’).
• Cross-session reasoning and lengthy histories.
• Multi-hop questions requiring express relational paths.

Benchmarks reminiscent of Deep Memory Retrieval (DMR) and LongMemEval have been launched exactly as a result of naive vector RAG degrades on long-horizon and temporal duties.

Failure modes in multi-agent planning

• Lost constraints: top-k retrieval misses a essential international constraint (finances cap, compliance rule), so a planner generates invalid instrument calls.
• Semantic drift: approximate neighbors match on matter however differ in key identifiers (area, surroundings, consumer ID), resulting in improper arguments.
• Context dilution: too many partially related chunks are concatenated; the mannequin underweights the necessary half, particularly in lengthy contexts.

When it’s high-quality

• Single-agent or short-horizon duties.
• Q&A over small to medium corpora.
• As a first-line semantic index over logs, docs, and episodes, not as the ultimate authority.

1.2 Tiered Vector Memory (MemGPT-Style Virtual Context)

What it’s?

MemGPT introduces a virtual-memory abstraction for LLMs: a small working context plus bigger exterior archives, managed by the mannequin utilizing instrument calls (e.g., ‘swap on this reminiscence’, ‘archive that part’). The mannequin decides what to maintain within the lively context and what to fetch from long-term reminiscence.

Architecture

• Active context: the tokens at the moment current within the LLM enter (analogous to RAM).
• Archive / exterior reminiscence: bigger storage, usually backed by a vector DB and object retailer.
• The LLM makes use of specialised features to:
  • Load archived content material into context.
  • Evict components of the present context to the archive.

Latency profile

Two regimes:

• Within lively context: retrieval is successfully free externally; consideration price solely.
• Archive accesses: much like plain vector RAG, however usually focused:
  • Search area is narrowed by job, matter, or session ID.
  • The controller can cache “scorching” entries.

Overall, you continue to pay vector search and serialization prices when paging, however you keep away from sending massive, irrelevant context to the mannequin at every step.

Hit-rate conduct

Improvement relative to plain vector RAG:

• Frequently accessed objects are stored within the working set, so they don’t rely on ANN retrieval each step.
• Rare or outdated objects nonetheless endure from vector-search limitations.

The core new error floor is paging coverage relatively than pure similarity.

Failure modes in multi-agent planning

• Paging errors: the controller archives one thing that’s wanted later, or fails to recollect it, inflicting latent constraint loss.
• Per-agent divergence: if every agent manages its personal working set over a shared archive, brokers might maintain completely different native views of the identical international state.
• Debugging complexity: failures rely on each mannequin reasoning and reminiscence administration selections, which should be inspected collectively.

When it’s helpful

• Long conversations and workflows the place naive context development is just not viable.
• Systems the place you need vector RAG semantics however bounded context utilization.
• Scenarios the place you possibly can spend money on designing / tuning paging insurance policies.

2. Graph Memory Systems

2.1 Temporal Knowledge Graph Memory (Zep / Graphiti)

What it’s?

Zep positions itself as a reminiscence layer for AI brokers applied as a temporal information graph (Graphiti). It integrates:

• Conversational historical past.
• Structured enterprise information.
• Temporal attributes and versioning.

Zep evaluates this structure on DMR and LongMemEval, evaluating towards MemGPT and long-context baselines.

Reported outcomes embrace:

• 94.8% vs 93.4% accuracy over a MemGPT baseline on DMR.
• Up to 18.5% larger accuracy and about 90% decrease response latency than sure baselines on LongMemEval for advanced temporal reasoning.

These numbers underline the good thing about express temporal construction over pure vector recall on long-term duties.

Architecture

Core parts:

• Nodes: entities (customers, tickets, assets), occasions (messages, instrument calls).
• Edges: relations (created, depends_on, updated_by, discussed_in).
• Temporal indexing: validity intervals and timestamps on nodes/edges.
• APIs for:
  • Writing new occasions / info into the KG.
  • Querying alongside entity and temporal dimensions.

The KG can coexist with a vector index for semantic entry factors.

Latency profile

Graph queries are usually bounded by small traversal depths:

• For questions like “newest configuration that handed checks,” the system:
  • Locates the related entity node.
  • Traverses outgoing edges with temporal filters.
• Complexity scales with the dimensions of the native neighborhood, not the complete graph.

In apply, Zep experiences order-of-magnitude latency advantages vs baselines that both scan lengthy contexts or depend on much less structured retrieval.

Hit-rate conduct

Graph reminiscence excels when:

• Queries are entity-centric and temporal.
• You want cross-session consistency, e.g., “what did this consumer beforehand request,” “what state was this useful resource in at time T”.
• Multi-hop reasoning is required (“if ticket A is determined by B and B failed after coverage P modified, what’s the seemingly trigger?”).

Hit fee is restricted by graph protection: lacking edges or incorrect timestamps immediately cut back recall.

Failure modes in multi-agent planning

• Stale edges / lagging updates: if actual programs change however graph updates are delayed, plans function on incorrect world fashions.
• Schema drift: evolving the KG schema with out synchronized adjustments in retrieval prompts or planners yields delicate errors.
• Access management partitions: multi-tenant situations can yield partial views per agent; planners should concentrate on visibility constraints.

When it’s helpful

• Multi-agent programs coordinating on shared entities (tickets, customers, inventories).
• Long-running duties the place temporal ordering is essential.
• Environments the place you possibly can preserve ETL / streaming pipelines into the KG.

2.2 Knowledge-Graph RAG (GraphRAG)

What it’s?

GraphRAG is a retrieval-augmented technology pipeline from Microsoft that builds an express information graph over a corpus and performs hierarchical neighborhood detection (e.g., Hierarchical Leiden) to arrange the graph. It shops summaries per neighborhood and makes use of them at question time.

Pipeline:

1. Extract entities and relations from supply paperwork.
2. Build the KG.
3. Run neighborhood detection and construct a multi-level hierarchy.
4. Generate summaries for communities and key nodes.
5. At question time:
   • Identify related communities (by way of key phrases, embeddings, or graph heuristics).
   • Retrieve summaries and supporting nodes.
   • Pass them to the LLM.

Latency profile

• Indexing is heavier than vanilla RAG (graph development, clustering, summarization).
• Query-time latency might be aggressive or higher for massive corpora, as a result of:
  • You retrieve a small variety of summaries.
  • You keep away from setting up extraordinarily lengthy contexts from many uncooked chunks.

Latency largely is determined by:

• Community search (usually vector search over summaries).
• Local graph traversal inside chosen communities.

Hit-rate conduct

GraphRAG tends to outperform plain vector RAG when:

• Queries are multi-document and multi-hop.
• You want international construction, e.g., “how did this design evolve,” “what chain of incidents led to this outage.”
• You need solutions that combine proof from many paperwork.

The hit fee is determined by graph high quality and neighborhood construction: if entity extraction misses relations, they merely don’t exist within the graph.

Failure modes

• Graph development bias: extraction errors or lacking edges result in systematic blind spots.
• Over-summarization: neighborhood summaries might drop uncommon however necessary particulars.
• Traceability price: tracing a solution again from summaries to uncooked proof provides complexity, necessary in regulated or safety-critical settings.

When it’s helpful

• Large information bases and documentation units.
• Systems the place brokers should reply design, coverage, or root-cause questions that span many paperwork.
• Scenarios the place you possibly can afford the one-time indexing and upkeep price.

3. Event and Execution Log Systems

3.1 Execution Logs and Checkpoints (ALAS, LangGraph)

What they’re?

These programs deal with ‘what the brokers did‘ as a first-class information construction.

• ALAS: a transactional multi-agent framework that maintains a versioned execution log plus:
  • Validator isolation: a separate LLM checks plans/outcomes with its personal context.
  • Localized Cascading Repair: solely a minimal area of the log is edited when failures happen.
• LangGraph: exposes thread-scoped checkpoints of an agent graph (messages, instrument outputs, node states) that may be continued, resumed, and branched.

In each instances, the log / checkpoints are the bottom fact for:

• Actions taken.
• Inputs and outputs.
• Control-flow selections.

Latency profile

• For regular ahead execution:
  • Reading the tail of the log or a latest checkpoint is O(1) and small.
  • Latency largely comes from LLM inference and instrument calls, not log entry.
• For analytics / international queries:
  • You want secondary indexes or offline processing; uncooked scanning is O(n).

Hit-rate conduct

For questions like ‘what occurred,’ ‘which instruments have been known as with which arguments,’ and ‘what was the state earlier than this failure,’ hit fee is successfully 100%, assuming:

• All related actions are instrumented.
• Log persistence and retention are accurately configured.

Logs do not present semantic generalization by themselves; you layer vector or graph indices on high for semantics throughout executions.

Failure modes

• Log bloat: high-volume programs generate massive logs; improper retention or compaction can silently drop historical past.
• Partial instrumentation: lacking instrument or agent traces yield blind spots in replay and debugging.
• Unsafe replay: naively re-running log steps can re-trigger exterior unwanted effects (funds, emails) until idempotency keys and compensation handlers exist.

ALAS explicitly tackles a few of these by way of transactional semantics, idempotency, and localized restore.

When they’re important?

• Any system the place you care about observability, auditing, and debuggability.
• Multi-agent workflows with non-trivial failure semantics.
• Scenarios the place you need automated restore or partial re-planning relatively than full restart.

3.2 Episodic Long-Term Memory

What it’s?

Episodic reminiscence buildings retailer episodes: cohesive segments of interplay or work, every with:

• Task description and preliminary circumstances.
• Relevant context.
• Sequence of actions (usually references into the execution log).
• Outcomes and metrics.

Episodes are listed with:

• Metadata (time home windows, members, instruments).
• Embeddings (for similarity search).
• Optional summaries.

Some programs periodically distill recurring patterns into higher-level information or use episodes to fine-tune specialised fashions.

Latency profile

Episodic retrieval is often two-stage:

1. Identify related episodes by way of metadata filters and/or vector search.
2. Retrieve content material inside chosen episodes (sub-search or direct log references).

Latency is larger than a single flat vector search on small information, however scales higher as lifetime historical past grows, since you keep away from looking out over all particular person occasions for each question.

Hit-rate conduct

Episodic reminiscence improves hit fee for:

• Long-horizon duties: “have we run an analogous migration earlier than?”, “how did this type of incident resolve prior to now?”
• Pattern reuse: retrieving prior workflows plus outcomes, not simply info.

Hit fee nonetheless is determined by episode boundaries and index high quality.

Failure modes

• Episode boundary errors: too coarse (episodes that blend unrelated duties) or too high-quality (episodes that minimize mid-task).
• Consolidation errors: improper abstractions throughout distillation propagate bias into parametric fashions or international insurance policies.
• Multi-agent misalignment: per-agent episodes as an alternative of per-task episodes make cross-agent reasoning tougher.

When it’s helpful?

• Long-lived brokers and workflows spanning weeks or months.
• Systems the place “related previous instances” are extra helpful than uncooked info.
• Training / adaptation loops the place episodes can feed again into mannequin updates.

Key Takeaways

1. Memory is a programs drawback, not a immediate trick: Reliable multi-agent setups want express design round what’s saved, how it’s retrieved, and how the system reacts when reminiscence is stale, lacking, or improper.
2. Vector reminiscence is quick however structurally weak: Plain and tiered vector shops give low-latency, sublinear retrieval, however wrestle with temporal reasoning, cross-session state, and multi-hop dependencies, making them unreliable as the only real reminiscence spine in planning workflows.
3. Graph reminiscence fixes temporal and relational blind spots: Temporal KGs (e.g., Zep/Graphiti) and GraphRAG-style information graphs enhance hit fee and latency on entity-centric, temporal, and multi-document queries by encoding entities, relations, and time explicitly.
4. Event logs and checkpoints are the bottom fact: ALAS-style execution logs and LangGraph-style checkpoints present the authoritative document of what brokers really did, enabling replay, localized restore, and actual observability in manufacturing programs.
5. Robust programs compose a number of reminiscence layers: Practical agent architectures mix vector, graph, and occasion/episodic reminiscence, with clear roles and recognized failure modes for every, as an alternative of counting on a single ‘magic’ reminiscence mechanism.

---

References:

• MemGPT (digital context / tiered vector reminiscence)
  • https://arxiv.org/abs/2310.08560
  • https://arxiv.org/pdf/2310.08560
  • https://research.memgpt.ai/
• Zep / Graphiti (temporal information graph reminiscence, DMR, LongMemEval)
  • https://arxiv.org/abs/2501.13956
  • https://www.getzep.com/
  • https://github.com/getzep/graphiti
  • https://www.emergentmind.com/topics/zep-a-temporal-knowledge-graph-architecture
• GraphRAG (knowledge-graph RAG, hierarchical communities)
  • https://microsoft.github.io/graphrag/index/default_dataflow/
  • https://graphrag.com/reference/graphrag/global-community-summary-retriever/
  • https://github.com/microsoft/graphrag
• ALAS (transactional / disruption-aware multi-agent planning, execution logs)
  • https://arxiv.org/abs/2505.12501
  • https://arxiv.org/abs/2511.03094
  • https://www.themoonlight.io/en/review/alas-transactional-and-dynamic-multi-agent-llm-planning
  • https://www.researchgate.net/publication/397322324_ALAS_Transactional_and_Dynamic_Multi-Agent_LLM_Planning
• LangGraph (checkpoints / reminiscence, thread-scoped state)
  • https://docs.langchain.com/oss/python/langgraph/memory
  • https://medium.com/@anil.jain.baba/long-term-agentic-memory-with-langgraph-824050b09852
• Supplemental GraphRAG + temporal KG context
  • https://memgraph.com/blog/how-microsoft-graphrag-works-with-graph-databases

The publish Comparing Memory Systems for LLM Agents: Vector, Graph, and Event Logs appeared first on MarkTechPost.