leejk/ jk lee

Agent Memory: Bolt It On, or Build It Native · 2026.05

Agent Memory Frameworks — A Four-Way Comparison and Selection Guide

agentmemory · hermes-agent · Mem0 · Letta — viewed across two layers: memory infrastructure and memory runtime

·
#agent-memory#agentmemory#hermes-agent#mem0#letta#memgpt#framework#landscape

Within a single week, the agent memory framework landscape consolidated. rohitg00/agentmemory (8.3k stars) entered GitHub trending, NousResearch/hermes-agent (149k stars) surged 2k stars per day, and three evaluation papers (LongMemEval-V2, MEME, MemPrivacy) adopted Mem0, Letta, LangMem, and Graphiti as testbeds. Four frameworks became directly comparable in the same place, exposing a layer split — memory infrastructure (agentmemory, Mem0) and memory runtime (hermes-agent, Letta). The piece sorts all four along this split and closes with five usage-scenario routes.

TL;DR

  • Within a single week, four memory frameworks gathered in the same place. agentmemory (8.3k★ · 2.5 months · MCP-server-style memory engine) · hermes-agent (149k★ · self-improving runtime) · Mem0 (55.6k★ · memory API layer) · Letta/MemGPT (22.7k★ · stateful agent platform). All met in the same single week, in GitHub trending and as testbeds in the evaluation papers (LongMemEval-V2, MEME, MemPrivacy).
  • The layer split became clear — memory infrastructure vs. memory runtime. agentmemory and Mem0 are memory infrastructure (external engines you layer onto an agent), while hermes-agent and Letta are memory runtimes (full agent runtimes with memory embedded). Same category, but orthogonal design assumptions.
  • The two frameworks within each layer carry decisive design differences. Infrastructure layer — agentmemory has 12 auto hooks + SQLite + BM25+vector+graph fusion, Mem0 has a manual add() API + Qdrant/pgvector + vector+graph. Runtime layer — hermes-agent has 200+ models + 7 backends + 6 messaging platforms, Letta has Postgres + vector DB + its own runtime lock-in.
  • Combinability differs by layer. Memory infrastructure (agentmemory/Mem0) can layer onto any agent — Claude Code, Cursor, even hermes-agent itself. A memory runtime (hermes-agent/Letta) keeps its own memory as the core but can take an external memory engine as a plugin. So one infrastructure + one runtime is the natural combination.

1. What Happened Over the Week

One Sunday. rohitg00/agentmemory entered GitHub trending. Just 2.5 months after release, 8.3k stars, and it came out swinging with benchmark numbers like 95.2% R@5 (LongMemEval-S) as its marketing centerpiece, alongside the self-claim "#1 persistent memory for coding agents." The same day, the MemPrivacy paper (MemTensor + Tongji) hit arXiv, adopting LangMem, Mem0, and MemoBase as a PII-protection testbed and measuring that raw masking loses 26–42% of utility while MemPrivacy stays within 1.6%.

Two days later, Tuesday. NousResearch/hermes-agent surged 2k stars in a day on the tagline "the agent that grows with you." Ten months from release, it grew double-digit percent in a week off a base of 149k stars.

The next day, Wednesday. Two evaluation papers published the same day. LongMemEval-V2 (UCLA) put forward its own AgentRunbook-R/C baselines while making RAG-based systems like Mem0 and Letta indirect comparison targets. MEME (KAIST + Tübingen + NAVER) adopted Mem0, Graphiti, MD-flat, and Karpathy Wiki as a six-system memory testbed and showed that every system collapses simultaneously on dependency reasoning (Cascade 3% · Absence 1%).

Bundle the five signals into one week and a single current appears. agentmemory and hermes-agent take the trending spotlight while three evaluation papers pull Mem0, Letta, LangMem, and Graphiti in as objects of objective measurement. The two currents didn't overlap by chance — they signal that the category has matured enough that comparison of evidence has replaced comparison of claims. Entrants come in carrying benchmark numbers (agentmemory self-publishing R@5 95.2%), and the evaluation tools pin existing frameworks as their comparison targets.

It's the same pattern as the moment, laid out in the Agent Framework series, when four metaframes appeared simultaneously over four months. Just as the metaframe category did, the memory-framework category has reached the same place where simultaneous entry accelerates once a measurable layer forms.

This week's current is why the four frameworks this piece covers met in the same place. agentmemory (released 2026-02) · hermes-agent (2025-07) · Mem0 (2023-06) · Letta (2023-10) — their release dates span three years, yet in a single week they were all bound to the same benchmarks, the same trending, the same comparison table. And in that place, the layer split began to show.

2. Layer Classification — Memory Infrastructure vs. Memory Runtime

Sort the four frameworks by the layer they solve and they split into two places.

Layer Framework Position
Memory infrastructure agentmemory (rohitg00, 8.3k★) An MCP-server-style memory engine you layer onto any agent
Memory infrastructure Mem0 (mem0ai, 55.6k★) A vector+graph memory layer called via a manual API
Memory runtime hermes-agent (Nous Research, 149k★) A full agent runtime with a built-in learning loop embedded
Memory runtime Letta/MemGPT (letta-ai, 22.7k★) A stateful agent platform with core/archival memory embedded in Postgres + a vector DB

Memory infrastructure is an external engine. A tool you layer onto an agent (Claude Code, Cursor, OpenCode, even hermes-agent). Whatever agent environment the user runs, the same memory flows through. Memory runtime is the agent itself as the core. Memory is embedded inside it, and it works only once the user brings the runtime in as their main environment.

That the two layers are separable responsibilities is this piece's core assertion. Which agent runtime you put on top of the memory layer is the user's decision. A cross-layer combination like agentmemory + hermes-agent can run concurrently because the two occupy different layers — whereas two within the same layer (agentmemory + Mem0, or hermes-agent + Letta) collide directly.

2.1. The Capture · Storage · Retrieval · Lifecycle 4-Axis Matrix

Sort the four frameworks along the Capture · Storage · Retrieval · Lifecycle axes laid out by the Agent Memory category index:

Axis agentmemory Mem0 hermes-agent Letta
Capture 12 hooks, automatic (zero manual) manual add() call agent-curated + periodic nudge agent self-edit (core memory)
Storage SQLite + iii-engine (0 external DB) Qdrant/pgvector + graph DB SQLite FTS5 + Honcho user model Postgres + vector DB (archival)
Retrieval BM25 + Vector + Graph (RRF fusion) Vector + Graph FTS5 + LLM summarization Vector (archival), core memory inline
Lifecycle 4-tier consolidation + decay + auto-forget passive extraction (manual prune) skill self-improvement + Honcho evolution agent-managed (self-determined)

The table shows that the two frameworks within each layer carry different answers on all four axes. In the infrastructure layer, agentmemory and Mem0 are orthogonal on all four — capture, storage, retrieval, lifecycle. So are hermes-agent and Letta in the runtime layer.

2.2. Meta-Axes — The Spots That Affect Operating Decisions

Beyond the four axes, the meta-axes tied directly to the layer decision and the choice of usage environment:

Axis agentmemory Mem0 hermes-agent Letta
Type memory engine + MCP server memory layer API full agent runtime full agent runtime
Lock-in none (any MCP client) none (API only) the hermes runtime as core the Letta runtime as core
External DB none (SQLite + iii) Qdrant/pgvector required SQLite alone Postgres + vector DB
MCP compatibility native (MCP server) optional integration MCP server compatible optional
Target user users who layer onto an agent environment developers building their own agents individuals + researchers enterprise · stateful-agent builders
Benchmark self-claim LongMemEval-S R@5 95.2% LoCoMo R@5 68.5% (none — self-improvement mechanism) LoCoMo R@5 83.2%
Release date 2026-02-25 2023-06-20 2025-07-22 2023-10-11

Be conscious that the benchmark self-claim numbers are not directly comparable. LoCoMo and LongMemEval-S are different tasks. Which benchmark each framework uses for its self-claim points to its design identity. All four frameworks must be evaluated on a common benchmark like LongMemEval-V2 (2026-05-13) or MEME before objective comparison is possible — a spot that will accumulate around Q3 2026.

3. Memory Infrastructure

3.1. agentmemory — A Memory Engine Extending the Karpathy Wiki

rohitg00/agentmemory — 8.3k★ (2.5 months), released 2026-02. An MCP-server-style memory engine built on the iii-engine. The README in one line:

"Persistent memory for Claude Code, Cursor, Gemini CLI, Codex CLI, Hermes, OpenClaw, pi, OpenCode, and any MCP client." — README

The crux is that it integrates instantly into 16+ agent environments via MCP. The README's Works With Every Agent table explicitly lists 16 — Claude Code · OpenClaw · Hermes · Cursor · Gemini CLI · OpenCode · Codex CLI · Cline · Goose · Kilo Code · Aider · Claude Desktop · Windsurf · Roo Code · Claude SDK + REST API.

agentmemory's self-positioning spells out its cited origin: "extends Karpathy's LLM Wiki pattern — confidence scoring · lifecycle · knowledge graphs · hybrid search." That is, the body is the markdown-wiki pattern Karpathy laid out plus four systematic mechanisms.

Six design mechanisms:

  1. Automatic capture — 12 hooks. Auto-integration of Claude Code's 12 hooks + MCP + skills, and Codex CLI's 6 hooks + MCP + skills. The design goal is zero manual calls from the user.
  2. Hybrid retrieval — BM25 + Vector + Graph (RRF fusion). Combines three retrievers via Reciprocal Rank Fusion. agentmemory's own measurement: LongMemEval-S R@5 95.2% — a +9-point gain over BM25 alone (86.2%).
  3. 0 external DB — SQLite + iii-engine. Self-hosted by default. The embedding model is all-MiniLM-L6-v2 (local, free, no API key required).
  4. 4-tier consolidation + decay + auto-forget. The memory lifecycle auto-consolidates into 4 tiers, applies temporal decay, and even auto-forgets. Not agent-curated but engine-side automation.
  5. Multi-agent coordination — MCP + REST + leases + signals. A lease + signal mechanism for when multiple agents access the same memory server concurrently.
  6. Real-time viewer. A web viewer on local port 3113 displays memory state in real time. In the session replay tab, you can scrub the timeline of prompt, tool call, tool result, and response (0.5×–4× playback).

Token efficiency — the assertiveness of the design: agentmemory's own calculation table:

Approach Tokens/year Cost/year
Paste full context 19.5M+ exceeds context window
LLM-summarized ~650K ~$500
agentmemory ~170K ~$10
agentmemory + local embeddings ~170K $0

Self-claims 99% token savings. Exactly the same place as the baseline-shaving of the metaframe category (ECC §2.1 token defaults), but carried out at the memory layer.

Limitations:

  • 2.5 months old — a short production-validation surface. External validation of the 12 hooks' capture accuracy, the RRF fusion's long-tail edge cases, and the multi-agent lease + signal's concurrency stability is still thin as of v0.9.0. For production adoption, pinning a frozen v0.9.0 is recommended.
  • Only the LongMemEval-S (V1) measurement is self-published. Not yet measured on V2 (released 2026-05-13).
  • No external party has validated the 12 hooks' capture accuracy — the general trade-off of engine-side automation.

3.2. Mem0 — Universal Memory Layer

mem0ai/mem0 — 55.6k★, released 2023-06 (~3 years). "Universal memory layer for AI Agents." The oldest player in the category.

Design summary:

  • API layermem0.add() · mem0.search() · mem0.update(). The agent calls explicitly.
  • vector + graph search — Qdrant/pgvector + a graph store. The point of differentiation from agentmemory's added BM25 fusion.
  • External DB dependency — Qdrant, pgvector, Neo4j, etc. A DB is required, whether self-hosted or cloud.
  • lifecycle: passive extractionmanual extraction from user utterances, then storage. No auto hooks.

Mem0 is close to the category's origin point — the player that categorized the design assumption itself, "let's separate out the memory layer." Its release three years ago is the place that first spelled out this design assumption.

This is the spot where MemPrivacy paper §4 adopted Mem0 as one of three testbeds and measured -0.73% accuracy loss under PL2-PL4 protection. That Mem0 became a baseline for objective evaluation is a direct signal of the category's maturity.

Limitations:

  • The external-DB operating burden of Qdrant, pgvector, Neo4j, etc. is a clear contrast with agentmemory's 0 external DB. The decision cost of self-hosted Mem0 ops vs. cloud Mem0 usage is added on top.
  • The manual add() API makes capture the user's responsibility. You need explicit calls inside the agent code for when to store what — the exact opposite design assumption from agentmemory's 12 hooks.

4. Memory Runtime

4.1. hermes-agent — A Self-Improving Agent Runtime

NousResearch/hermes-agent — 149k★ (~10 months after a 2025-07 release), a flagship Nous Research project. The README's first line:

"The only agent with a built-in learning loop — it creates skills from experience, improves them during use, nudges itself to persist knowledge, searches its own past conversations, and builds a deepening model of who you are across sessions." — README

If agentmemory is an external memory layer, hermes-agent is a full agent runtime with a learning loop embedded. The core of the design is different.

The five elements of the core learning loop:

  1. Agent-curated memory with periodic nudges — the agent curates its own memory. It periodically nudges itself: "isn't this worth remembering?"
  2. Autonomous skill creation — after completing a complex task, it auto-generates a reusable skill. Self-learning not spelled out by an external dev.
  3. Skill self-improvement during use — a skill, once created, improves itself while in use. It folds usage frequency and outcomes into a feedback loop.
  4. FTS5 session search + LLM summarization — searches past conversations themselves via SQLite FTS5 full-text search + LLM summarization. A design where the conversation becomes memory.
  5. Honcho dialectic user modeling — integrates the Honcho library to maintain a separate evolving model of the user. That is, task memory and user memory are separated.

Core features beyond memory:

  • 200+ model support — OpenRouter · OpenAI · Anthropic · Nous Portal · NovitaAI · NVIDIA NIM · Xiaomi MiMo · z.ai/GLM · Kimi · MiniMax · HuggingFace. Switch with a single hermes model line.
  • Messaging gateway — Telegram · Discord · Slack · WhatsApp · Signal · Email + CLI. Six platforms run concurrently. Voice-memo transcription is supported too.
  • 7 terminal backends — local · Docker · SSH · Singularity · Modal · Daytona · Vercel Sandbox. Daytona/Modal offer serverless persistence (hibernate when idle, wake on demand).
  • cron scheduler — register tasks like "a report every morning at 8" in natural language. Runs unattended.
  • subagents + RPC — isolated subagents compress multi-step pipelines into a zero-context-cost turn.
  • agentskills.io compatibility — explicitly compatible with the open standard. A link to the skill ecosystem laid out in the expert skill-pack piece.

RL training surface — the environments/ directory holds Atropos RL environments, so batch trajectory generation + RL training code ship together. A signal that Nous Research does its next-generation tool-calling model training with hermes-agent — i.e., hermes-agent is not just a user tool but a training-data generator.

Limitations:

  • 149k★, but it doesn't go into enterprise commercial operation — it's individual-user/researcher-centric.
  • Being a full agent runtime, it isn't a mode you layer onto an existing agent environment (Claude Code, etc.). It's only meaningful once you bring hermes in as your main environment.
  • The PII/secrets transmission surface of the cross-platform messaging gateway runs head-on into the spot the MemPrivacy piece catches. The possibility of sensitive information flowing through external messaging infrastructure like WhatsApp, Telegram, Signal — controllable in a personal setting, but enterprise adoption needs an additional security review.

4.2. Letta/MemGPT — A Stateful Agent Platform

letta-ai/letta — 22.7k★, released 2023-10 (~2.5 years). The successor to the MemGPT paper (Packer et al., 2023). "Platform for building stateful agents."

The design core:

  • OS metaphor — separates core memory (in-context) and archival memory (external vector DB) like an OS's RAM and disk. The agent swaps its own memory directly.
  • stateful agent runtime — the agent instance maintains persistent state. No state loss between sessions.
  • agent self-edits — the agent directly modifies its own core memory. The exact opposite of agentmemory's external hook model.
  • External DB dependency — Postgres + a vector DB. Assumes enterprise-grade operation.

Letta's core drawback is Letta runtime lock-in. It can't be layered onto an existing agent environment like Claude Code or Cursor — Letta has to be the runtime core. The agentmemory README comparison table explicitly marks this spot as "Framework lock-in: High (must use Letta)."

hermes-agent is close to the direct successor to Letta — a self-improving agent runtime, but designed so the model, terminal, and messaging gateway are all swappable. That is, a form that layers plugin possibility on top of the OS metaphor MemGPT laid out.

The MEME paper didn't test Letta itself but measured agent self-edits — the core of Letta's design — via file-based agents (MD-flat, Karpathy Wiki). Simultaneous collapse at Cascade 3% · Absence 1% — the agent self-edit model is powerless at dependency reasoning. A finding Letta users should register.

Limitations:

  • That it can't be layered onto an existing agent environment is an entry cost for users accustomed to environments like Claude Code or Cursor. The lock-in is only justified in environments where an enterprise stateful agent is the core.
  • The enterprise infrastructure operating assumption of Postgres + a vector DB is a burden for individuals and small teams.
  • agent self-edits are powerless at dependency reasoning, as the MEME paper proved (Cascade 3% · Absence 1%). A warning surface in domains where dependency matters (project management, relational data).

5. Combination and Conflict — When Used Together in the Same Project

Because the four frameworks occupy different layers, their combinability and conflict surfaces also differ by layer.

5.1. Memory Infrastructure + Memory Runtime — A Natural Combination

agentmemory's own README spells out Hermes integration:

"Hermes: MCP + plugin" — agentmemory README · Works With Every Agent

That is, first-class support for using the agentmemory memory engine as hermes-agent's external memory. In this combination:

  • Use agentmemory's BM25+Vector+Graph hybrid retrieval where it's stronger than hermes's FTS5 alone.
  • hermes-agent's Honcho user modeling and skill self-improvement are places agentmemory doesn't touch.
  • agentmemory's 12-hook auto-capture may overlap with hermes sessions' agent-curated memory + periodic nudge — an explicit decision is needed on which capture is canonical.

Response: have hermes-agent's built-in memory handle only user modeling, and delegate working memory to agentmemory. That is, the layer split applies even at the capture unit.

5.2. Two Within the Same Layer — Direct Conflict

Two memory infrastructures together (agentmemory + Mem0) — two frameworks in the same layer, so direct conflict. No decision on which is canonical. agentmemory's auto hooks and Mem0's manual API accumulate the same information in two places.

Two memory runtimes together (hermes-agent + Letta) — direct conflict. Both are designed to be the runtime core, so concurrent operation is impossible. That said, an external memory engine like agentmemory can serve as a common memory layer — i.e., a migration path between the two is possible via external memory.

Response: only one per layer. §6 decides which fits, depending on the usage scenario.

5.3. Metaframe + Memory Framework Combinations

The category index laid out that all four frames in the Agent Framework series (Superpowers · GSD · gstack · ECC) have their own memory mechanism. Whether you can additionally lay an external memory engine like agentmemory on top of these four frames is the combinability question.

  • Superpowershas no user working memory of its own, so laying agentmemory alongside fills Superpowers' blank spot exactly. A natural combination.
  • GSD.planning/ markdown state is the core. Orthogonal to agentmemory at the capture unit — GSD captures at phase boundaries, agentmemory via 12 hooks. The two captures may store the same information differently, so a separate response is needed.
  • gstack/learn user-explicit + domain skills automatic. agentmemory's 12 auto hooks may conflict with gstack's explicit design assumption. Response: activate only some of the agentmemory hooks.
  • ECCinstinct v2 auto-extraction + confidence scoring. Directly competes with agentmemory's 4-tier consolidation. For ECC users, turning on only one of the two is rational.

So metaframe + external memory engine is a natural combination only for Superpowers. The other three already have their own memory, so agentmemory becomes a duplicate.

6. Usage Scenarios — Five Recommendations

On the surface there are four frameworks, but by usage scenario the choice is clear.

6.1. Claude Code/Cursor user + no metaframe → agentmemory

The simplest path. Spin up the MCP server once and integrate it into your agent environment. Its hooks work with zero manual configuration. The token-cost savings (~98% vs. LLM-summarized) take effect immediately.

6.2. Superpowers user → augment with agentmemory

Superpowers has no user working memory, so agentmemory drops exactly into the blank spot. The MCP server + Superpowers SessionStart bootstrap coexist. Install it once and working context auto-accumulates across sessions.

6.3. GSD/gstack/ECC user → augment with external memory, carefully

For a metaframe that already has its own memory mechanism, adding an external engine creates capture conflict. Two alternatives:

  • Use the memory engine retrieval-only — leave capture to the metaframe and tap only agentmemory's hybrid retrieval.
  • Use only the metaframe's own memory — don't add an external engine. Operate on the metaframe's design assumption as-is.

6.4. Individual + cross-platform messaging → hermes-agent

If an individual user talks to the same agent from Telegram, Discord, and Slack while needing model-cost control, go hermes-agent. The combination of 200+ models + 6 messaging platforms is the strongest in the category.

6.5. Enterprise + stateful agents → Letta

Large-scale agent operation, many stateful agent instances, an environment capable of operating enterprise infrastructure like Postgres and a vector DB. Letta's runtime lock-in is a burden, but in an enterprise setting the lock-in is controllable. That said, if dependency reasoning is a core domain (project management, relational data), be conscious of the Cascade 3% · Absence 1% limit of Letta's self-edit that the MEME paper proved.

6.6. Research/RL training → hermes-agent

Atropos RL environments + batch trajectory generation. hermes-agent's place as a training-data generator is clearly different from the other three.

References

Category index + evaluation papers

Same topic