Best AI Agent Memory API Providers in 2026

Someone on your team has been asked to give the agents memory. Every vendor describes persistent memory for AI agents, and the API shapes look alike. You add something, then you search for it later. The differences sit underneath, in what each provider does to a conversation between the add call and the search call. Some extract durable facts. Some build a graph that remembers when a fact stopped being true. Some hand the decision to the agent. Some hand it to you.

This comparison starts with the option most teams running coding agents should evaluate first, then orders six memory APIs by how much of that work the provider does for you, and sets out what to test before you commit to any of them. Dosu comes first for a specific reason. If the agents in question are Claude Code, Cursor, or Codex, and what they keep forgetting is the repository, a conversational memory API is not the missing piece, and picking one before fixing that spends the budget on the wrong problem.

Memory APIs differ in what happens before storage

Dosu is not a conversational memory API. It maintains engineering knowledge and serves it to coding agents, which is why it sits apart from the six options below. Mem0 extracts facts from messages. Zep builds temporal graph data. Supermemory combines extraction, profiles, and document retrieval. Letta gives the agent tools to rewrite its own memory. LangMem packages similar tools as a library. Redis Agent Memory adds background extraction and promotion, while a Postgres build with pgvector leaves that behavior to your code. The list moves from more provider-managed interpretation toward more implementation control, but it is not a strict ranking.

Published benchmarks will not settle the choice. LongMemEval and LoCoMo score question answering over long conversation histories, and every reported number depends on the generation model, the embedding model, the extraction prompts, and the retrieval settings the vendor picked. The LightMem paper makes this visible by reporting separate results for GPT and Qwen backbones, with different gains for each. Mem0 and Zep have publicly disputed each other's published results. Nothing we reviewed runs every provider under one controlled setup, so treat vendor scores as claims to reproduce on your own traces.

Coding agents add a second problem the benchmarks never touch. Dialogue recall does not measure whether an agent still knows your repository's structure, the decision in last month's pull request, or the convention your team adopted after an incident.

What to test before you read a benchmark

Recall on your own traces. Replay real conversations, ask questions that depend on older details, and score whether the API returns the right evidence.

Conflict and temporal handling. Store a fact, replace it, then ask for the current value and for what was true before. Check whether both answers survive.

Tenant isolation. Write near-identical facts under two tenants and confirm that search, deletion, and admin tooling never cross the boundary.

Deletion and auditability. Delete one user and confirm that derived memories, embeddings, and graph records go with it, and that a record of who did it remains.

Latency and token overhead. Measure write and retrieval latency at your expected concurrency, then count every token the memory layer adds to a prompt and every background model call it makes.

Self-hosting portability. Deploy the self-hosted version, export what it stored, and list every managed feature you would lose by leaving.

Dosu for the repository context coding agents keep losing

Most memory APIs in this article focus on what a user or agent said and what should carry into later sessions. Coding agents need to answer another question. What is true about this repository right now? The architecture decision from last month's pull request, the convention your team adopted after an incident, or the reason your team renamed a service may never appear in the current conversation. That context lives in the work.

That is what Dosu maintains. You connect Sources to a Library, which today means GitHub repositories, Slack workspaces and Notion pages on paid plans, and the web at query time. Dosu drafts Documents from that activity. When a pull request opens, Dosu flags the published Documents the change may affect, and when it merges, Dosu proposes updates with a link back to what changed. Those proposals go through Review, where a person accepts, edits, or declines them, unless the Library is set to auto-accept. Dosu also generates and maintains agent-facing files such as AGENTS.md, skills, and specs from the code and the decisions around it.

Coding agents reach that knowledge over MCP. The Dosu CLI sets up the MCP server for the agents already on your machine. The current server gives agents four tools, read_knowledge, write_knowledge, review_knowledge, and finalize_session_knowledge. Agents use them to retrieve team knowledge, save durable notes, and review pending changes. Each agent retrieves knowledge only from its assigned Library, so a repository agent and a Slack agent each see their own Sources rather than the whole organization. Dosu is SOC 2 Type II, does not train on customer data, and offers self-hosting for large enterprise deployments. The free plan covers public repositories. Pro costs $16 a month with annual billing or $20 month to month for private repositories.

Dosu is not a conversational memory API, and the six providers below are not substitutes for it. If your application also needs to remember users across sessions, run Dosu alongside whichever of them you pick. They remember the user. Dosu keeps the repository context current.

Mem0 for the smallest integration

Mem0 does the most extraction behind the simplest interface. Your application sends conversation messages to an add operation, Mem0 decides which facts are worth keeping, and a later search returns the relevant ones. Memories carry user, agent, and run identifiers, which is how you scope tenants at the API level. You can use the managed platform or run the Apache 2.0 project yourself as a library or a Docker stack.

Mem0 also has broad coding-agent coverage. Its repository carries plugins for Claude Code, Codex, and Cursor alongside an MCP server and setup guides for more than twenty frameworks. Those plugins give a coding agent conversational memory across sessions. They do not author or maintain repository documentation, which is the job the Dosu section above describes.

The main tradeoff comes from where Mem0 runs richer behavior. Graph memory and Mem0's background consolidation feature, which it calls Dream, start on the $249 per month Pro plan on the managed platform. The Hobby plan includes 10,000 add requests and 1,000 retrieval requests each month at no cost. Starter costs $19 a month. Enterprise adds on-prem deployment, audit logs, and SSO at custom pricing. Self-hosting provides another route to graph memory, but you must run it. Mem0's trust center lists SOC 2 Type I as compliant, HIPAA as self-attested, and SOC 2 Type II and GDPR as in progress. On the managed platform, Mem0 chooses the extraction model, while custom instructions let you control which facts it keeps. Self-hosted Mem0 also lets you configure the extraction model and other components.

Zep with Graphiti for facts that expire

Zep stores entities as nodes and facts as edges, and when a new fact contradicts an old one it records the invalidation time on the old edge rather than overwriting it. That is the mechanism behind its temporal queries. You can ask what is true now or what was recorded on a given date, with provenance back to the source Episode. An Episode is any single object you send, a chat message, a JSON payload, or a block of text, and by default messages added to a user's threads land in that user's graph.

Zep Cloud is the managed product. Graphiti is the Apache 2.0 graph engine underneath it, with its own MCP server for Claude, Cursor, and other MCP clients. Zep deprecated its older Community Edition, so Graphiti is the self-hosting path, and feature parity between Graphiti and Zep Cloud is something to verify for your use case rather than assume.

Pricing is credit-based on ingestion only. One Episode up to 350 bytes costs one credit, retrieval and storage are unmetered, and the free tier includes 10,000 credits a month. Flex is $125 a month with 50,000 credits, Flex Plus is $375 with 200,000, and Enterprise is custom. Zep states that it is SOC 2 Type II certified. HIPAA business associate agreements, audit logs, and EU data processing agreements are Enterprise-only, as are the bring-your-own-keys and bring-your-own-cloud deployment options. The cost of Zep is modeling. A temporal graph gives you more structure than plain fact retrieval, and you pay for that in custom entity and edge types, which are capped at 10 on Flex and 20 above it.

Supermemory for memory, retrieval, and connectors from one vendor

Supermemory is the broadest product here. Its API bundles five layers, user profiles, a memory graph, hybrid retrieval, multimodal extractors, and connectors for Notion, Google Drive, S3, Gmail, OneDrive, and GitHub. You post content to a documents endpoint and Supermemory runs extraction and profile updates on its side. Connected sources can also write through automatic sync. The engine is MIT licensed and the repository documents a self-hosted binary that runs against cloud models or offline with Ollama.

Plans are usage-based with credits included. Free includes about $5 of usage, Pro is $19 a month, Max is $100, Scale is $399, and Enterprise is custom. SOC 2 and a HIPAA business associate agreement start at the Scale tier, and Enterprise adds air-gapped self-hosting. Supermemory reports 85.2 percent on LongMemEval and first place on LoCoMo and ConvoMem. Those are the vendor's own numbers on its own evaluation platform, and the point of the testing section above is that you reproduce them before you plan around them.

The tradeoff is scope. A team that only needs conversational fact storage may take on retrieval and connector features it will not use. Supermemory documents container tags and scoped API keys for tenant isolation, plus permanent single and bulk deletion, including deletion by container. Confirm the audit-log coverage you need with the vendor.

Letta for agents that manage their own memory

Letta is an agent runtime, not a memory endpoint, and that distinction decides whether it belongs on your shortlist. Instead of your application holding the transcript and calling a memory API, Letta holds the agent and its state, and your application sends the agent messages. Memory has three tiers. Core memory is a set of labeled blocks that stay in the context window on every turn and that the agent rewrites with its own tools. Archival memory holds facts the agent chooses to file away. Recall memory is searchable conversation history.

What triggers a write is the agent itself, or a second agent running behind it. Letta's sleep-time agent reads recent history between turns and rewrites the primary agent's memory blocks, so the user-facing agent never pays the latency of memory hygiene. Letta's sleep-time compute paper describes the technique. That background agent bills tokens on its own schedule, and Letta lets you give it a cheaper model or a lower frequency.

Letta ships as an open source server and as Letta Cloud, with Python and TypeScript SDKs and MCP server attachment. Pricing is by plan. Free supports a limited number of agents with your own API keys, Pro is $20 a month for up to 20 stateful agents, the API plan is $20 a month plus $0.10 per active agent per month and $0.00015 per second of server-side tool execution with pay-as-you-go model usage, Teams Pro is $20 per seat, and Enterprise adds role-based access control and SAML or OIDC single sign-on. Choose Letta when you want the runtime. Do not choose it to add memory to a pipeline you already have.

LangMem for teams already on LangGraph

LangMem is a Python library that gives LangGraph agents two things. Memory tools the agent calls in the hot path to save and search, and a background manager that extracts and consolidates memories outside the live turn. It handles semantic memories, user profiles, and episodic memories, and it needs an LLM provider key because a model does the extraction.

LangMem's core primitives can work with any storage system, while its documented agent examples use LangGraph's store interface. The quickstart uses an in-memory store that loses data on restart, and production guidance points to AsyncPostgresStore or a similar persistent store. LangMem does not offer a standalone managed service. Teams use LangSmith Deployment, formerly LangGraph Platform, for managed deployments. It includes a managed database. LangSmith charges separately for deployment and model usage. LangMem uses the MIT license.

Choose LangMem when LangGraph is already your framework and you want memory behavior you can read and change. If you are not on LangGraph, weigh that framework coupling against standalone alternatives.

Redis or Postgres when you want to own the behavior

These are not the same option, and the difference matters. Redis Agent Memory Server, an Apache 2.0 project from Redis, is more than storage. It keeps session memory with configurable TTLs for the active conversation and, as new events land, extracts important information in the background and promotes it to long-term memory as text plus embeddings. The managed path is Redis Agent Memory inside Redis Iris on Redis Cloud, exposed through a REST API with configurable schemas and TTL lifecycle management. Public pricing for that service was not in the material we reviewed. What Redis leaves to you is policy. Schema design, conflict handling, tenant boundaries, deletion semantics, and evaluation are yours.

Postgres with pgvector is the true floor. pgvector adds vector types and similarity indexes to a database you already run. It does not extract facts, resolve contradictions, consolidate duplicates, or decide when to write. Every one of those becomes application code, and tenant isolation is row-level security or separate schemas that you maintain.

Teams take this path for good reasons. Strict data residency, an existing Redis or Postgres estate, memory requirements simple enough that extraction is one model call, or a refusal to put a vendor in the request path. The cost is that everything the providers above do out of the box is now yours to build and keep correct.

Which pick fits your situation

• Your agents are coding agents that keep forgetting the repository. Dosu, and then one of the below only if the application also needs conversational memory.
• You want the fewest lines of integration. Mem0. Expect to pay for graph memory or self-host to get it.
• Your agent must know what was true on a date. Zep. Budget modeling time for entity and edge types.
• You want memory, document retrieval, and source connectors from one API. Supermemory. Reproduce its benchmark claims on your traces first.
• You want the agent to own its memory and you can adopt a runtime. Letta.
• You are already on LangGraph. LangMem.
• You need to own every behavior, or you already run the infrastructure. Redis Agent Memory Server for extraction with your policies, or Postgres with pgvector to build it all.

FAQ

What are the main Mem0 alternatives?

Zep for temporal graphs, Supermemory for a broader managed context engine, Letta if you want an agent runtime, LangMem if you are on LangGraph, and Redis or Postgres if you want to build the behavior yourself. Pick by how much extraction and conflict handling you want the provider to own. Dosu is not a Mem0 alternative. It maintains repository context for coding agents rather than conversational memory.

What does a memory layer for AI agents do?

It stores information from agent runs and returns the relevant parts on later requests, so the application does not replay every prior conversation. Providers differ in what they store. They may keep raw messages, extracted facts, or a graph of facts with time bounds. They also differ in who decides when to write. Your code, the agent, or a background process can trigger the write.

How is agent memory different from coding-agent context?

Agent memory captures what was said and done in conversations and tool calls. Coding-agent context is what is currently true about a codebase, which changes with every merge whether or not anyone talked about it. Dosu maintains that context in Documents and agent-facing files from Sources such as GitHub, Slack, and Notion, and serves it to Claude Code, Cursor, and Codex over MCP.

Can I run a memory API and Dosu together?

Yes. They cover different failures. A memory API keeps the agent from forgetting the user. Dosu keeps the agent from working off a stale picture of the repository. Nothing in either integration depends on the other.

Find out what your coding agents keep re-learning

Before you evaluate a memory API, check which problem you have. Pick a task your team ships often and read the agent's transcript. If the agent wastes turns rereading files to reconstruct an architecture decision or convention, it lacks repository context. A general-purpose memory API can hold that context only if your team builds and maintains the workflow around it.

Dosu captures that context from pull requests and connected Sources, proposes updates when code changes, and serves the reviewed result to your coding agents over MCP. Setup runs from one command:

curl -fsSL https://cli.dosu.dev/install | sh

Connect your first repo to Dosu and give the next session the context the last one already found.