DEV Community: Statewave

8 Open Source Tools for Building AI Agents with Memory

Statewave — Thu, 03 Sep 2026 14:09:06 +0000

An agent that remembers needs four things: somewhere to put raw events, something that turns them into facts, a way to retrieve those facts under a token budget, and a framework to run the loop. No single tool does all four well, which is why this list is eight tools and not one.

We build Statewave, an open-source memory runtime, so treat the entry about us accordingly. Everything below is Apache-2.0, MIT, or the PostgreSQL License, verified from the LICENSE file rather than the badge, checked on 1 September 2026. MCP is mid-transition from MIT to Apache-2.0.

Grouping below is by what each tool owns, because the most common mistake in this category is picking two tools that own the same layer and none that own the missing one.

The memory layer

1. Statewave

A memory runtime that sits behind your agents over HTTP. You send raw events as episodes; it compiles them into typed memories with confidence scores and validity windows, and you request a ranked, token-bounded bundle when you need context.

from statewave import StatewaveClient

with StatewaveClient("http://localhost:8100") as sw: sw.create_episode(subject_id="user-42", source="chat", type="message", payload={"text": "Alice asked about pricing tiers"}) sw.compile_memories("user-42") print(sw.get_context("user-42", task="answer pricing", max_tokens=1000).assembled_context)

What it owns: storage, consolidation, ranked retrieval, conflict resolution, provenance. What it deliberately does not own: your agent loop. Storage is Postgres with pgvector and no separate vector service. npx @statewavedev/statewave boots the API, admin console, and Postgres locally. The server defaults to demo mode with stub hash-based embeddings and the heuristic compiler, which means no real semantic search but a working loop.

Determinism is the property we care most about. The same subject, task, and token budget return the same bytes, which is what makes retrieval regression-testable.

Where it costs you: cross-subject retrieval is two calls, and the default compiler is heuristic regex. Switch to STATEWAVE_COMPILER_TYPE=llm for better extraction from messy conversation, or keep the heuristic compiler deliberately if no customer text may leave your network.

2. Mem0

Mem0 is the shortest path from nothing to an assistant that remembers a user. Its API is four calls wide: add, search, update, delete. Apache-2.0 for the library, with a managed platform sold separately.

Pick it when time to first working result matters more than being able to explain a specific retrieval later. Composition of its vector store, graph layer, and reranker is not broken down in public docs, so auditability means reading source.

3. Graphiti

Graphiti is a temporal knowledge graph that tracks when a fact became valid and when it stopped being true. That is a real answer to stale memory, which most fact stores handle by overwriting and hoping.

A note that saves evaluation time: many lists point to getzep/zep for this project. That repo’s README describes itself as examples for the managed Zep Cloud rather than the product, checked 1 September 2026. Graphiti is the self-hostable piece.

4. Cognee

Cognee builds a self-hosted knowledge graph with ontology grounding, combining embeddings with graph reasoning. Apache-2.0.

Reach for it when the relationships between entities carry the meaning, not just the facts about each one. It is more machinery than a preference store needs.

The orchestration layer

5. LangGraph

LangGraph models agents as state machines with explicit nodes and edges, which makes multi-step flows debuggable in a way that a while-loop over tool calls is not. MIT.

Its checkpointer handles per-thread state well. Worth being precise about the boundary: thread-level persistence is not the same as cross-session, cross-agent memory, and conflating them is how teams end up with an agent that remembers a conversation but not a customer.

6. Letta

Letta carries the MemGPT lineage and is a stateful agent runtime rather than a memory layer. It owns the reasoning loop, tool calls, and context management. Apache-2.0.

Check what you are adopting before you commit to it. letta-ai/letta now describes itself as a landing page for the project, with the retired Letta V1 server preserved on an archive branch and marked unsupported and not for production use. The current path is the hosted platform and the Letta Agent SDK, so Letta is no longer the self-hostable “one decision instead of four” it used to be.

The protocol and storage layers

7. Model Context Protocol

MCP is the piece people skip, then rebuild badly. It is an open protocol for exposing tools and data to LLM clients, built on JSON-RPC.

Why it belongs on a memory list: if four agents in three frameworks need the same memory, a protocol endpoint is what stops you writing three adapters. We expose Statewave over MCP for exactly this, so a Claude custom connector and a Python agent hit one memory service without either knowing about the other.

8. pgvector

pgvector adds vector types and distance operators to Postgres. Not glamorous, and it removes an entire moving part from your architecture.

One detail worth knowing: use an HNSW index rather than IVFFlat for anything that grows. IVFFlat recall depends on lists and probes matching your row count, so a corpus that outgrows its tuning quietly returns worse neighbors. We migrated for that reason and wrote up the details in the Postgres post.

How to assemble these

Stacks that work: pair one tool per layer:

● Fast prototype: LangGraph plus Mem0. Two decisions, working today.

● Self-hosted with audit requirements: your framework plus Statewave on Postgres and pgvector, exposed over MCP.

● Relationship-heavy domains: Graphiti or Cognee for memory, LangGraph for orchestration.

A common anti-pattern is picking Letta and Mem0 together, or LangGraph checkpointers and expecting cross-session memory. Both are two tools fighting over one layer while a different layer stays empty.

If you want the working code rather than the list, we keep three runnable demos: multi-agent memory with conflicting sources and automatic supersession, multi-agent shared context where a planner and coder stop contradicting each other, and a personal assistant that boots in five minutes without an LLM key.

No neutral, third-party benchmark compares these on the same task with the same corpus. Ours covers a subset and we ran it, which is exactly why it is not the one to settle your decision. Run the eval on your own data before committing to any of them.

7 Postgres Tools Every AI Engineer Should Know

Statewave — Thu, 03 Sep 2026 13:59:42 +0000

Most AI stacks add a vector database on day one and a second datastore to keep in sync forever after. A short list of Postgres extensions removes that decision for a large class of workloads.

We build Statewave, an open-source memory runtime for AI agents that runs on Postgres and nothing else. No separate vector service. That constraint forced us to learn which extensions genuinely carry AI workloads and which are resume padding. Below are seven, ordered by how often they earn their install.

Our own dependency list is one extension long, which is the first useful signal in this post: vector is the only one we require. Two entries below are not extensions at all, full-text search ships in Postgres core, and PgBouncer is a connection pooler, but both earn their place on an AI workload, so they are here.

1. pgvector

pgvector is what makes the rest of the argument possible. It adds a vector column type plus distance operators for cosine, L2, and inner product.

CREATE EXTENSION IF NOT EXISTS vector; ALTER TABLE memories ALTER COLUMN embedding TYPE vector(1536);

Index choice is the part worth internalizing, because we shipped the wrong one first. Our initial migration built an IVFFlat index:

CREATE INDEX ON memories USING ivfflat (embedding vector_cosine_ops);

IVFFlat partitions vectors into lists and probes a subset at query time. It builds fast and uses little memory. Recall, though, depends on lists and probes being tuned against your actual row count, and a corpus that grows past what you tuned for silently returns worse neighbors. Nothing errors. Results just get quietly less relevant.

We moved to HNSW:

CREATE INDEX ix_memories_embedding ON memories USING hnsw (embedding vector_cosine_ops);

HNSW builds a navigable graph. Better recall at the same latency, stable as the corpus grows, and no list-count tuning. Cost is real: build time and memory. On a small corpus the migration finishes in under a second, but HNSW build is the slow step at scale, so our migration sets statement_timeout = '20min' to survive large tables.

Use IVFFlat when your corpus is static and you need a fast build. Use HNSW for anything that grows. If you inherited an IVFFlat index and nobody has retuned lists since the table doubled, that is worth checking today.

2. Built-in tsvector and GIN (no extension required)

Semantic search alone fails on exact tokens. A user asking for error code SW-4021 needs lexical matching, and embeddings will happily return five semantically adjacent errors instead.

Postgres ships full-text search in core. A generated column plus a GIN index gives you lexical retrieval with zero dependencies:

ALTER TABLE memories ADD COLUMN content_tsvector tsvector GENERATED ALWAYS AS (to_tsvector('english', content)) STORED; CREATE INDEX ix_memories_content_tsvector ON memories USING gin (content_tsvector);

GENERATED ALWAYS AS ... STORED means Postgres maintains the column on every write. No trigger to forget, no backfill job to schedule.

We run this alongside vector search and fuse the two, which is what "hybrid retrieval" means in practice. Including it here because half the teams that install a vector database do so to solve a problem that lexical search solves better.

3. pgcrypto

Small but load-bearing. pgcrypto supplies gen_random_uuid() for primary keys generated server-side, so you are not round-tripping to the application for an ID.

CREATE EXTENSION IF NOT EXISTS pgcrypto;

On Postgres 13 and newer, gen_random_uuid() is in core and you may not need the extension at all. Check your version before adding it. Its digest and encryption functions matter separately if you are storing anything sensitive in a memory layer, which for agent memory you usually are.

4. pg_trgm

pg_trgm does trigram matching for fuzzy string comparison. Entity resolution is the AI-specific use: deciding that "Acme Corp", "ACME Corporation", and "acme corp." are the same subject before you write three separate memory rows about them.

CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX ON subjects USING gin (name gin_trgm_ops); SELECT name, similarity(name, 'acme corp') AS score FROM subjects WHERE name % 'acme corp' ORDER BY score DESC;

Embeddings are the wrong tool here. Two spellings of the same company name are lexically close and semantically identical, so cosine similarity gives you no separation between the right match and every other company in your table.

5. pg_stat_statements

pg_stat_statements tells you why your agent feels slow.

CREATE EXTENSION IF NOT EXISTS pg_stat_statements; SELECT query, calls, mean_exec_time, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

AI workloads have a specific failure shape: one vector query looks fine at 40ms, then you discover the agent issues it eleven times per turn. Mean latency stays healthy while total time balloons. total_exec_time catches that; a p99 dashboard does not.

6. pg_cron

pg_cron covers the background work agent memory needs. Compiling raw events into typed facts, expiring memories past their validity window, and recomputing scores are all jobs that should not run on the request path.

CREATE EXTENSION IF NOT EXISTS pg_cron; SELECT cron.schedule('expire-memories', '0 * * * *', $$UPDATE memories SET status='expired' WHERE valid_until < now() AND status='active'$$);

We run compilation as durable jobs in the application layer rather than in pg_cron, because our jobs call an LLM and need retry semantics Postgres should not own. Honest rule: pg_cron is right for deterministic SQL maintenance and wrong for anything that makes a network call.

7. PgBouncer (a pooler, not an extension)

Included deliberately, because the thing that breaks first when you scale an AI service is not the vector index. It is connection count.

Each API replica holds a pool. Ten replicas at fifteen connections each is 150 logical connections crowding max_connections, and Postgres connection overhead is not free. Raising max_connections postpones the problem and makes it worse.

PgBouncer in transaction mode decouples logical client connections from physical backends: a pool of 30 to 60 backend connections comfortably serves 5 to 15 replicas. Transaction mode is the right setting when sessions are short. If you use prepared statements, PgBouncer 1.21 and later support them in transaction mode via max_prepared_statements; on older versions, avoid holding them across transactions.

One thing to know before you switch: pg_stat_activity then shows PgBouncer's identity rather than your replicas. Use SHOW POOLS and SHOW CLIENTS for the per-replica picture.

What we would actually install

For a new AI service on Postgres, in order:

vector with an HNSW index. Non-negotiable.
Built-in tsvector plus GIN. Free, and it fixes the exact-token failures embeddings cannot.
pg_stat_statements. Install before you need it, because the query pattern you need to diagnose is one you have to catch in the act.
pg_trgm once you have real user-entered entity names.
PgBouncer at the point where replica count times pool size approaches max_connections.

pgcrypto and pg_cron are situational. Check your Postgres version for the first and your job semantics for the second.

Broader point: a memory layer for AI agents can run on Postgres with one extension and no separate vector service. We wrote up the storage decisions in more detail, and the IVFFlat-to-HNSW migration is readable in the repo linked at the top if you would rather check it than take our word for it.

What did we miss? If you are running something in production that earned its place on an AI workload, name it below.

6 Ways to Add Observability to Your AI Agent Pipeline

Statewave — Thu, 03 Sep 2026 13:57:44 +0000

When an agent gives a wrong answer, the prompt log tells you what it was asked and what it said. It does not tell you which stored facts reached the prompt, which were filtered out, or which were stale. That gap is where agent debugging actually lives.

We build Statewave, a memory runtime for AI agents, so most of what follows comes from instrumenting the retrieval side of that problem. Six layers, ordered from the one everyone already has to the one almost nobody does.

1. Request tracing across the hop boundary

Start here because it is cheap and everything else attaches to it. An agent turn is rarely one process: the framework calls a model, the model requests a tool, the tool calls a memory service, the memory service queries Postgres.

Propagate a request ID across every hop and log it at each. Without it you have four logs and no way to join them, which turns a five-minute investigation into an afternoon.

OpenTelemetry is the standard worth adopting rather than inventing a correlation header. The span boundaries that matter for agents are: turn, model call, tool call, retrieval.

2. Deterministic retrieval, so runs are comparable

This one is a design decision rather than a tool, and it gates the usefulness of everything after it.

If your memory layer searches at query time and samples differently per call, two identical requests return different context. You cannot compare a good run against a bad one because the inputs were never the same. Non-determinism does not just make debugging harder; it makes A/B comparison meaningless.

Our approach is to move the expensive work off the query path: episodes compile into typed memories once per subject change, then context assembly ranks those compiled memories by kind priority, recency, task relevance, temporal validity, and semantic similarity. Same inputs, same bytes.

Whatever memory layer you use, find out whether it guarantees this. If it does not, your first observability investment is making retrieval reproducible, not adding another dashboard.

3. Retrieval receipts

This is the layer that answers "why did the agent say that?"

A receipt is an immutable record of one context assembly: which memories and episodes were selected, the content hash of the assembled bundle, and the policy snapshot in force at the time. Ours are ULID-keyed, which gives chronological sorting at the database level without a separate index.

{ "receipt_id": "01J8XKQ2M7...", "subject_id": "user-42", "selected_entries": ["mem_881", "mem_902", "ep_1204"], "context_hash": "sha256:9f2c...", "canonicalization_version": 3, "policy_snapshot": {"bundle_hash": "sha256:41ab..."} }

One detail worth stealing: the canonicalization_version field. Hashing an assembled context is only useful if you can tell later whether a hash mismatch means the content changed or the hashing routine changed. Version the canonicalization and historical hashes stay verifiable.

Prompt logs cannot do this job. A prompt log shows the final string; a receipt shows the decisions that produced it, including which memories were considered and rejected.

4. Replay, with honest semantics

Receipts let you re-run an assembly. What replay means, precisely, matters more than having it.

Ours re-runs against current memories using the original policy bundle captured in the receipt. That is deliberately not byte-for-byte historical reproduction, and the difference is worth stating plainly:

● Memories may have been added, tombstoned, or superseded since. Those appear in the diff as added or removed entries.

● New episodes ingested since will show up in scope.

● Scoring code runs at whatever version is deployed now, so a changed heuristic shows up as a context hash change.

True point-in-time reproduction needs memory snapshots, which we have not built. If you are designing this yourself, decide which semantic you need before building, because retrofitting snapshots is much harder than including them.

5. Health scoring on the subject, not just the service

Service health tells you Postgres is up. It does not tell you that one customer's memory has quietly degraded.

Subject-level health scoring is the agent-specific version of an SLO. Ours computes a deterministic 0 to 100 score from signals already in the data: unresolved sessions, repeated issue patterns, urgency markers, idle open issues, and SLA breaches. Every factor returns its own contribution, so the score is explainable rather than a number nobody trusts.

# every penalty is named and capped, so a score decomposes _UNRESOLVED_ISSUE_PENALTY = 15 # per open session, capped at 45 _REPEATED_ISSUE_PENALTY = 20 # 2+ sessions sharing a pattern _ESCALATION_PENALTY = 10 # per episode with urgency markers, capped at 20 _IDLE_OPEN_PENALTY = 15 # open issue, no activity in 7+ days _SLA_BREACH_PENALTY = 10 # per breaching session, capped at 20

No ML, no stored state, computed on demand. Determinism is the constraint that keeps it useful: the same data always produces the same score, so a change in the number always means a change in the data.

6. Alert on state transitions, not thresholds

Threshold alerts on a score that moves every request produce noise until someone mutes the channel.

Alert on transitions between named states instead. Ours emits subject.health_degraded when a subject moves healthy to watch, watch to at_risk, or healthy to at_risk, and subject.health_improved on the way back. Unchanged states emit nothing, because the deduplication compares against the last cached state.

That single rule, transitions rather than levels, is the difference between an alert channel people read and one they filter.

Where to start

If you have none of this today, the order that pays fastest:

Request IDs across hops. One afternoon, and it makes every later layer joinable.
Make retrieval deterministic. Nothing downstream is trustworthy without it.
Receipts on retrieval. The single highest-value artifact for debugging agents, and the one most stacks lack.
Transition-based alerts. Cheap once you have a state model.

Replay and subject health are worth building when you have compliance requirements or a support workflow, and skippable if you do not.

Our implementations of the above are Apache-2.0 and readable in the repo if you want the receipt schema or the health scoring rather than the summary. The provenance and audit trail write-up covers the reasoning behind layer three in more depth.

What does your agent observability stack look like? Particularly curious whether anyone has solved true point-in-time replay without snapshotting the whole store.

Best Open-Source AI Agent Memory Tools (Ranked by What They Guarantee)

Statewave — Mon, 17 Aug 2026 06:37:25 +0000

The best open-source AI agent memory tool is the one that guarantees the properties your system depends on: a self-hostable runtime, deterministic retrieval, provenance back to source events, and a permissive license. Ranked on those four, Statewave leads, ahead of Cognee, Mem0, Graphiti, and Letta.

We checked the LICENSE file and README of every project below, reading the repository rather than the landing page. That produced the finding this post is built on: two of the four alternatives most often listed as self-hostable memory servers do not ship that from the repo people link to.

This post ranks by capability, not by adoption. Adoption tells you what other teams picked last year. Capability tells you what will hold when your agent is in production.

Disclosure: we build Statewave. Every claim below about another project is quoted from or linked to that project's public repository, so you can check each one yourself.

What makes an agent memory tool "best"?

Four properties separate a memory runtime from a fact store with a vector index bolted on. Every ranking below is scored against these.

Self-hostable as the actual product. Not a client library that calls someone else's cloud. When data cannot leave your infrastructure, this is the first filter, and it eliminates more tools than teams expect.

Deterministic retrieval. The same subject, task, and token budget returns the same context. Without this, you cannot regression-test memory, and you cannot explain why two identical requests produced different answers.

Provenance. Every compiled fact traces back to the raw event that produced it. When someone asks why the agent said something about their account, that has to be a query rather than an investigation.

Permissive license. Apache-2.0 or MIT, with no source-disclosure obligation and no seat-count trap. All five here pass this one.

Which open-source memory tools are worth shortlisting?

	Self-hosted product	Deterministic retrieval	Provenance	License
Statewave	Yes, single service	Yes, documented contract	Yes, per memory	Apache-2.0
Cognee	Yes	Not advertised	Graph lineage	Apache-2.0
Mem0	Library and self-hosted server; managed platform separate	Not advertised	Not surfaced in public docs	Apache-2.0
Graphiti	Yes, library plus a REST/MCP server	Not advertised	Edge validity dates	Apache-2.0
Letta	Agent runtime, not a memory layer	Not advertised	Not surfaced in public docs	Apache-2.0

1. Statewave

Statewave is a memory runtime rather than a memory library. It records raw events as append-only episodes, compiles them into typed memories with confidence scores and validity windows, then assembles a ranked, token-bounded context bundle on demand. Start the server first with npx @statewavedev/statewave, then talk to it from the Python SDK (pip install statewave), which is a client rather than the runtime:

from statewave import StatewaveClient

with StatewaveClient("http://localhost:8100") as sw: sw.create_episode(subject_id="user-42", source="chat", type="message", payload={"text": "Alice asked about pricing tiers"}) sw.compile_memories("user-42") print(sw.get_context("user-42", task="answer pricing", max_tokens=1000).assembled_context)

It leads on all four criteria for one architectural reason: the expensive work happens at compile time, not query time. The same (subject_id, task, max_tokens) returns the same bytes against the same compiled state, which is what makes retrieval regression-testable. Every memory returns source_episode_ids, so provenance is a field rather than a feature request. Storage is Postgres with pgvector and nothing else, so self-hosting is one command rather than an infrastructure project: npx @statewavedev/statewave, or git clone plus docker compose up -d if you want the compose file in your own tree.

Where it costs you: compiled bundles are denser than plain fact-store lookups, so a single-hop query spends more tokens than it would against a flat key-value store. For workloads that are all single-hop and cost-sensitive, that trade is not worth it.

Best for: teams that must self-host and must be able to prove why a fact surfaced. Read the ranked retrieval and provenance model for how the audit chain works.

2. Cognee

Cognee builds a self-hosted knowledge graph with ontology grounding, combining vector embeddings with graph reasoning. It ranks second because it genuinely self-hosts and the graph gives you real lineage between entities.

It ranks below Statewave on determinism, which is not advertised as a contract, and on retrieval shape: graph traversal answers "how is Alice connected to Acme" better than "what is the ranked context for Alice under a 1,000-token budget."

Fits domains where the relationships between entities are the product.

3. Mem0

Mem0 offers the shortest path from zero to an assistant that remembers a user, with an add / search / update / delete surface that is four calls wide. The open-source library is Apache-2.0.

It ranks third on our criteria rather than on quality, and not because it is library-only, which it no longer is: the repository ships a self-hosted Docker server with a dashboard, per-user API keys and a request audit log alongside the pip-installable library. The split that remains is between that open-source stack and the managed platform, and the README is explicit that its published scores "reflect Mem0's managed platform, which includes proprietary optimizations not available in the open-source SDK." The load-bearing gap for our criteria is retrieval composition: the public documentation still does not break down how the vector store, graph layer and reranker compose at retrieval time. If you need to explain a specific retrieval to an auditor, you will be reading source.

Fits consumer-facing personalization where speed to first result matters more than explainability.

4. Graphiti

Graphiti is a temporal context graph engine that tracks when facts became valid and invalid, which is a real answer to the stale-memory problem.

The ranking note here is the one that surprised us. The repository most lists point to for this project is getzep/zep, and its own README states it is not the product: it holds example code and integrations for Zep Cloud, which is managed. Graphiti is the self-hostable open-source component, and it is more than a library: the repository ships a FastAPI REST service under server/ and an MCP server under mcp_server/, with a prebuilt zepai/graphiti image published on each graphiti-core release. A team whose requirement is "runs in our VPC" does not have to write that service. What it still writes is the retrieval contract, because what Graphiti returns is graph queries rather than a ranked, token-bounded, deterministic bundle.

Fits teams that want temporal graph semantics and are willing to build the retrieval contract themselves.

5. Letta

Letta carries the MemGPT lineage and is the most capable system here at the thing it actually does, which is running agents. It ranks last only because it is answering a different question: it is an agent runtime that owns the reasoning loop, the tool calls and the context management.

The second repository note: that README states the repo is the legacy server and active development has moved to the Letta Agent repo. Adopting Letta means replacing your orchestration, not adding memory to it.

Fits teams with no agent stack yet who want the whole thing in one decision.

Which one should you pick?

Pick by the constraint that is load-bearing for you, in this order:

Data cannot leave your infrastructure. Statewave, Cognee, or Graphiti. Mem0's open-source stack qualifies; its managed platform does not.
You need to explain retrievals after the fact. Statewave. Provenance and deterministic ranking are the two properties that make this answerable.
Relationships between entities are the product. Cognee or Graphiti.
You have no agent framework yet. Letta.
You want something working this afternoon. Mem0.

One honest note on all of the above, including ours: no neutral, third-party benchmark covers all five on the same task with the same corpus. Every comparison in this category, this one included, is vendor-shaped. Run the eval on your own data before committing.

When the first two constraints are the binding ones, Statewave is Apache-2.0 and boots with one command: npx @statewavedev/statewave.

Best Memory Layer for Multi-Agent AI Systems With Shared Context

Statewave — Mon, 17 Aug 2026 06:30:06 +0000

The best memory layer for a multi-agent system is the one that keys memory to the subject rather than the agent, returns the same context to concurrent callers, enforces per-caller policy below the agents, and records which memories reached which agent. Scored on those four, Statewave leads, ahead of Mem0, LangMem, Graphiti and Letta.

We went looking for one specific primitive in each of these five projects, reading their repositories and public docs rather than their landing pages. The finding: we could not locate a documented per-caller policy primitive in any of the four alternatives. Every one of them can share memory between agents. We found no way in their public docs to say "the billing agent sees this memory and the FAQ agent does not" inside the memory layer itself.

That gap is the whole subject of this post, because it is the requirement that only appears once you have more than one agent.

Disclosure: we build Statewave. Every claim below about another project comes from that project's public repository or documentation, so you can check each one yourself.

Why does multi-agent memory need different properties?

Single-agent memory has one reader. Multi-agent memory has several readers with different privileges, arriving concurrently, contributing facts that the others will act on. Three failures follow, and none are fixed by a bigger context window.

Cross-agent amnesia. A researcher agent gathers requirements over six turns. A coder agent picks up the task with none of it, and the user re-explains.

Retrieval drift between callers. Two agents ask the same question about the same customer in the same minute and get different context, so they reach different conclusions from identical underlying facts. Now you are debugging a disagreement neither agent caused.

Uniform visibility. Every agent that can read the pool can read all of it, including the contractor's coding agent and the public-facing FAQ bot.

What are the four requirements?

Memory keyed to the subject. The unit of memory should be the entity it concerns, a customer or an account or a repository, not the agent that recorded it. Key memory by agent, and sharing becomes copying, and copies drift. Key it by session and it dies with the session.

Determinism across concurrent callers. The same subject, task and token budget returns the same bytes to every agent that asks.

Per-caller policy. A rule layer below the agents that decides, per request, whether a memory is passed, redacted, or denied based on who is asking.

Cross-agent audit. A record of which memories entered which agent's context, under which rules, at what time. A chat transcript is not this artifact.

Which memory layer handles shared context best?

	Subject-keyed	Deterministic	Per-caller policy	Cross-agent audit
Statewave	Yes, subjects are the primitive	Yes, documented contract	Yes, labels plus policy bundles	Yes, state-assembly receipts
Mem0	Yes, user and agent scoping	Not advertised	Not found in public docs	Request-level audit log, not per-memory
LangMem	Yes, store namespaces	Not advertised	Not found in public docs	Not surfaced
Graphiti	Graph-wide, not subject-scoped	Not advertised	Not found in public docs	Edge validity only
Letta	Per-agent by design	Not advertised	Not found in public docs	Not surfaced

1. Statewave

Statewave organizes everything around subjects, the entity memory is about. Four agents reading customer-8821 see one pool of episodes and compiled facts, so sharing is the default rather than a protocol you write.

Determinism comes from moving the work off the query path. Episodes compile into typed memories once per subject change, and context assembly ranks those compiled memories by kind priority, recency, task relevance, temporal validity, and semantic similarity. Same inputs, same bundle, whichever agent asks.

Per-caller policy is the piece that separates it here. Memories carry sensitivity labels such as pii, financial, and secret. Every context request carries a caller identity. A declarative YAML policy bundle, content-hashed and immutable, decides per request whether each memory is denied, redacted, or passed. Policies run in log_only mode first, recording what they would have filtered, before anyone enables enforcement.

Cross-agent audit is the state-assembly receipt: an immutable record of which memories and episodes went into one specific bundle, hashed, with the policy snapshot attached.

Where it costs you: cross-subject retrieval is not first-class. An agent needing facts about both Alice and Acme makes two calls. Subject granularity is a real design decision and getting it wrong means re-modelling later.

Fits systems where agents have different privileges or the data is sensitive.

2. Mem0

Mem0 supports user, agent and session scoping, so several agents can read one user's memory pool. It ranks second because that sharing works and the API is small enough to wire up quickly.

It ranks below Statewave on the second half of the list. Determinism is not advertised, and the composition of the vector store, graph layer and reranker is not broken down publicly, so two concurrent callers have no documented guarantee of identical context. We found no per-caller policy primitive: the self-hosted server issues per-user API keys, which authenticate a caller rather than decide which memories that caller may read, and Entity-Scoped Memory, which partitions the pool by user, agent, app or run, is marked platform-only. On audit it is closer than the rest of the field: the self-hosted stack keeps a request audit log. That is a record of calls, not a record of which memories entered which agent's context.

Fits multi-agent systems where every agent is trusted equally.

3. LangMem

LangMem gives LangGraph applications a store with namespaces, which is a clean sharing boundary when every agent lives inside LangGraph.

The constraint is the boundary itself. A LangGraph support agent, an OpenAI Agents SDK sales copilot and a custom Express service should share one memory surface, and the shared store reaches only the first. The package splits in two here, and the distinction is worth naming: LangMem's core primitives are storage-agnostic and travel into any application, while the shared memory that agents actually read is LangGraph's own long-term memory store. The portable half travels; the shared surface does not. Ranking, budgeting and provenance on top of the store are code you write.

Fits teams whose agents all run inside one framework.

4. Graphiti

Graphiti tracks when facts became valid and invalid across a temporal context graph, which handles the stale-fact problem well when several agents write to one graph.

It ranks fourth for multi-agent work because the graph is global rather than subject-scoped, so isolating one entity's context is a traversal you design. Per-caller filtering is application code above Graphiti, whether you embed the package or run its REST service.

Fits shared-context systems where entity relationships carry the meaning.

5. Letta

Letta is a stateful agent runtime with the MemGPT lineage, and it is strong at what it does. For this scorecard it ranks last because its memory model is per-agent by design: memory belongs to an agent rather than to an entity several agents share.

Multi-agent sharing in that model means passing state between runtimes rather than reading one pool.

Fits teams that want a complete agent runtime and whose agents do not need a common memory surface.

How do you choose?

Do your agents have different privileges? If yes, per-caller policy is the binding requirement and it narrows the field to one.
Do agents run in more than one framework? If yes, the memory layer has to be an HTTP service, which rules out framework-native stores.
Will anyone ask which agent saw what? If yes, you need receipts, not logs.
Are your agents symmetric and your data non-sensitive? Then requirements three and four do not bind, and Mem0 or LangMem is the faster path.

Being straight about our own gaps: tenant isolation is query-scoped at the application layer rather than Postgres row-level security, rate limiting is keyed per IP, and there is no admin-action identity yet, so label promotions record when but not who. One more, since it touches the audit argument above: receipt replay re-runs the original retrieval against today's memories using the original policy bundle, which is not byte-for-byte historical reproduction. Any of those may disqualify the approach for your compliance posture.

No neutral, third-party benchmark covers all five on the same multi-agent task, ours included. The scorecard above is a documentation review, and the honest way to use it is as a list of questions to ask each vendor.

Statewave is Apache-2.0 and self-hosted on Postgres. Many agents point at one memory service over HTTP or MCP, and your orchestration stays where you built it.