DEV Community: Statewave

Your dedup marker expires. The fact it created does not.

Statewave — Mon, 14 Sep 2026 12:04:13 +0000

Here is a bug that raises no error anywhere and shows up as a memory store slowly filling with the same fact twice.

You process an event, write a dedup marker, and set a 24-hour TTL on it so the marker table does not grow forever. Every guide tells you to do this, and for delivery-level idempotency it is correct advice. Then a backfill re-reads a ticket from last year. The marker expired months ago, so the ingest layer has no memory of it. But the fact derived from that event is still in the store, because derived facts do not expire on a schedule.

Now you have it twice. Nothing failed.

I went through the papers, talks and practitioner write-ups we had collected on this, and the word "idempotent" carried four incompatible meanings across them. Every source recommending a dedup marker also recommended a TTL on it. None discussed the interaction between an expiring marker and a non-expiring derived fact.

Four definitions sharing one word

Request-level. Repeating the same request leaves state unchanged after the first. The HTTP version is familiar, and RFC 9110 defines it in section 9.2.2: GET and DELETE are naturally idempotent, POST is not, and PATCH depends entirely on what it does. A PATCH setting a name to "DJ" is idempotent. A PATCH incrementing a counter is not. Same verb, opposite guarantee.

Delivery-level. The same event arriving twice gets acted on once. Most event-driven systems mean this, and enforce it with a marker.

Merge-level. The merge function is itself idempotent, plus associative and commutative, so replicas converge regardless of arrival order or repetition. This is the CRDT property.

Derivation-level. Re-running a derivation over the same inputs produces no new derived records. This is the one that matters for agent memory, and the one almost nobody names.

Satisfying any of those tells you nothing about the other three. A system can be fully delivery-idempotent and still accumulate duplicate facts, by exactly the mechanism above.

Why memory pipelines re-read on purpose

Retries are the obvious source. Even a broker promising exactly-once delivery cannot stop an upstream service publishing the same logical event twice under two different event IDs, which is why ID checks usually get paired with a business-key check on something like an order number.

What is specific to memory systems is that re-syncs are not failures. A connector pulling GitHub issues, Slack threads or support tickets runs on a schedule and re-reads overlapping windows every time, by design. A backfill re-reads everything. Neither is an error condition, so treating duplicate suppression as error handling puts the check in the wrong place.

Derive the key, never expire it

Stop generating keys and start deriving them from the event's logical identity. A derived key costs nothing to keep forever, because it is a property of the record rather than a row in a growing side table.

github:acme:api-server:issue:4471:opened

Source, org, repo, record type, issue number, event kind. Re-sync that issue a thousand times and you get one episode. No UUID, no timestamp, no TTL.

One file over in the same connector suite, the IDE companion uses the opposite rule: idempotency is content-addressable, so re-running an unchanged workspace scan maps to the same key and a changed workspace yields a new memory.

Two opposite policies in one codebase, and both are right. A GitHub issue has a stable identity independent of its text, so keying on identity is correct and an edited title should not create a second episode. A workspace scan has no identity apart from its contents, so keying on a content hash is correct and a changed workspace should produce a new one.

Your key encodes a definition of "the same event," and that definition is a per-source decision. Wrong in one direction floods the store. Wrong in the other silently drops real updates.

Compilation has to set, not append

Ingest dedup only covers ingest. The compile step needs its own guarantee, and it comes from one design choice: a compile pass that derives current state from the full episode log behaves like a set. A pass that appends whatever it found this run behaves like an increment, and increments are never idempotent.

That single property is what makes a compile endpoint safe to call from a retry loop, a cron job and a webhook handler at the same time. It is also what lets you batch compilation off the request path instead of running it inline after every turn.

Test for it in one line:

def test_recompile_is_a_noop(client, subject_id):
    first = client.post("/v1/memories/compile", json={"subject_id": subject_id})
    assert first.json()["memories_created"] > 0

    second = client.post("/v1/memories/compile", json={"subject_id": subject_id})
    assert second.json()["memories_created"] == 0

That whole test is the second number. If it is not zero, you have an append where you need a derivation, and no amount of ingest deduplication will save you.

Duplicates and conflicts are different problems

A duplicate is two records saying the same thing, and the fix is to keep one. A conflict is two records saying different things, both legitimately written, and there is no version of "keep one" that is obviously right.

Idempotency does nothing for the second case. Martin Kleppmann's taxonomy of conflict handling is still the cleanest: let a human resolve it, pick a winner automatically, or merge automatically. On the middle option he is precise about the cost, noting that some systems choose one version as the winner and throw away the others.

Throwing away the loser is the default in most agent memory stacks, and it is where the damage lands. You do not just lose the old value. You lose the evidence that a disagreement existed at all.

Recency-wins is near-universal as the automatic rule, and it is fine for state that genuinely changes, like which database a team runs. It is wrong for a stable attribute that a bad extraction re-asserts incorrectly. And it is wrong for facts that only look contradictory: "I am in Berlin this week" does not contradict "this user lives in Lisbon," and a system that supersedes the second with the first has made the memory worse.

Supersede, because the loser is evidence

Mark the older fact superseded, filter it out at read time, keep it in the record with provenance links to both sides. Three states cover it: active, superseded, tombstoned.

A worked example I can point at: three agents read three source documents concurrently and write to one shared subject. One commits Stripe's pre-reversal processing rate, another commits the corrected rate. Where the two memories carry a registered single-valued claim key, the compiler compares claims directly. Otherwise it falls back to Jaccard word overlap between the compiled memories, and at 0.6 or above it marks the older one superseded and records the decision with links to both source episodes.

Downstream, the synthesis agent's bundle contains only the winner. The audit trail contains both, plus the similarity score that triggered the call, 0.72 in the shipped run.

Treat 0.6 as a dial rather than a constant. Set it lower and unrelated facts collide, producing false-positive supersession that deletes true information from the read path. Set it higher and genuine contradictions both survive into the bundle, so you pay tokens to hand the model two incompatible answers.

Where this still fails

Word overlap is a fallback, not the mechanism. Jaccard catches "Stripe charges 3.5% + 35c" against "Stripe charges 2.9% + 30c." It will occasionally fire on unrelated facts sharing common words, and it misses contradictions expressed in entirely different vocabulary.

Idempotent is not deterministic. Run an LLM compiler and the extraction step can produce different facts from the same episodes on different runs. Idempotent compilation means a second pass over already-processed episodes adds nothing. It does not mean the first pass is reproducible. A regex-based heuristic compiler is.

Some conflicts should not be resolved. Two high-confidence claims that contradict each other may mean the boundary conditions differ. If being wrong is expensive in your domain, flag them and abstain instead of auto-resolving.

None of this fixes bad extraction. Deduplicating, superseding and auditing low-quality facts gives you a clean, well-audited store of low-quality facts.

The ten-minute check

Run your compile step twice in a row and look at the second number. If it created anything, that is the bug to fix before any of the rest.

If you would rather not build the key derivation, compile markers and supersession logic, the runtime behind the examples here is Apache-2.0 on GitHub and runs on your own Postgres. The full version of this post covers the per-kind conflict policy table and the replay boundary I skipped.

Quadrupling my agent's context budget bought 3x the facts, not 4x

Statewave — Mon, 14 Sep 2026 11:57:56 +0000

I ran one subject through a context assembler at three different token budgets and wrote down what came back. 200 tokens returned 2 memories. 500 returned 4. 800 returned 6.

That is a 4x spend for 3x the facts. It is the most useful number I have for sizing an agent's memory budget, and I almost never see it published.

Budget requested	Tokens returned	Utilization	Memories returned	Marginal cost per new memory
200	178	89.0%	2	89 tokens
500	443	88.6%	4	133 tokens
800	761	95.1%	6	159 tokens

Method, so you can repeat it: these are the published outputs of the budget command in the statewave-personal-assistant reference app, which calls the context API three times at three budgets against the same subject. I read them on 3 August 2026 and derived the marginal column myself.

The cheap facts get spent first

Marginal cost per fact rose 79% across that range, from 89 tokens to 159.

The assembler is not distributing effort evenly. It sorts by score and fills from the top, so the first two items are the densest, highest-priority things it holds. By the fifth and sixth it has worked down into longer, lower-scoring material.

So if you are choosing between 400 and 800 tokens, you are not choosing between four and eight facts. You are deciding whether to pay roughly double for two more items that already scored worse than everything in the bundle.

Utilization is the other column worth reading. It landed at 89.0%, 88.6% and 95.1%, and it never crossed 100%, because items are admitted whole. A memory that would overshoot the ceiling by one token gets dropped rather than truncated mid-sentence. Headroom across those runs was 11.0%, 11.4% and 4.9%. Plan for 5 to 11% of slack instead of assuming you get the number you asked for.

The stop rule is three lines, and that is the point

selected, used = [], 0
for memory in sorted(candidates, key=score, reverse=True):
    if used + memory.token_count > budget:
        break
    selected.append(memory)
    used += memory.token_count

A greedy knapsack fill. RCR-Router, a multi-agent routing paper, publishes essentially this as its Algorithm 1: sort by importance, accumulate, break on overflow. Nothing in it is stochastic, which is the property everything below depends on.

Compare it against the two patterns it replaces. Full history replay re-sends everything each turn, so cost grows with session lifetime and a throwaway comment carries the same weight as a production incident. Top-K vector retrieval returns the K nearest chunks, but K is a count and not a token budget, so your actual prompt size drifts with chunk length.

And no, a bigger window does not make this go away. Liu et al. tested position directly in Lost in the Middle and found accuracy follows a U-shaped curve against where the relevant passage sits: best at the start and end, worst in the middle, and that held even for models built for long context. Padding a 128K window with 100K tokens of history hands the model a large middle.

Scoring is where your opinions live

The fill is trivial. Ranking is where the design decisions sit. Four signals carry most of the ordering in the implementation those numbers came from:

Signal	Range	What it encodes
Kind priority	3 to 10	`profile_fact` 10, `procedure` 8, `episode_summary` 5, `raw_episode` 3
Recency	0 to 5	Linear, the newest memory takes the maximum
Task relevance	0 to 8	Word overlap contributes up to 5, cosine similarity up to 8
Temporal validity	-4 to +3	Currently valid adds 3, expired subtracts 4

Read that as a set of opinions rather than a spec. A stable profile fact outranks a raw conversation turn by 7 points on kind alone, before any other signal applies, which is why identity survives budget pressure and chatter does not. An expired fact carries a 7-point swing against it. Cosine similarity is in there, but as one input among four rather than the whole ranking.

What makes small budgets viable at all is compilation: a pass over raw episodes producing typed facts with confidence scores and provenance back to the source events. Two hundred conversation turns become one profile_fact. Rank raw turns instead and you are sorting a bad unit, low density and high token count with no confidence signal attached.

Determinism matters more than the compression

A 73% token reduction is the headline here, from roughly 2,800 tokens of raw history down to 761. I care more that it is the same 761 tokens every time.

Researchers at Penn State measured the alternative. Their work on parallel context compaction reports that as context grows, both the volume a model produces and the information it retains vary run to run. Prompt instructions asking for a specific summary length get largely ignored.

Which means: if your compaction step is an LLM call, your retrieval layer is non-deterministic, and every eval you run afterwards measures two things at once.

Deterministic assembly means same subject, same task string, same budget, same point in time, same bytes. When an answer changes, you know the change came from the model or the prompt, because the context did not move.

There is a real cost attached. Compile-then-use bundles are denser per answer than a plain fact-store lookup. If your queries are mostly single-hop and cost-sensitive, a lighter store may be the better call.

Six steps for setting your own number

Instrument before you tune. Log the returned token estimate and memory count on every context call. You want the utilization ratio. Running consistently below 85% means the budget is not your constraint and raising it will change nothing.
Start at 800. Aim for 5 to 8 compiled facts, which for typical fact and procedure sizes lands between 600 and 1,200 tokens.
Add the fixed costs before deciding it is too small. System prompt and tool schemas run 2,000 to 4,000 tokens on their own and get billed every call. Memory is usually the smallest line item in a well-built agent.
Watch the marginal curve, not the total. Run your own version of the three-budget test above and find where the next 200 tokens stop changing answers.
Set per-role budgets for multi-agent runs. A base budget plus a role offset. A planner needs structured plans; an executor needs less.
Keep compaction off the hot path. Compile on a schedule, every N episodes or nightly, using an async mode that hands you a job ID to poll. Raise the budget only when a named eval fails at the current one.

Two ways this still goes wrong

Bad extraction upstream. Ranking garbage precisely and fitting it exactly into 800 tokens gives you 800 tokens of well-organized garbage. The compiler sits upstream of everything here.

Prefix cache invalidation downstream. TokenPilot's authors found that mutating the prompt sequence to save tokens invalidates the KV prefix cache, and the misses can cost more than the tokens saved. Assemble a stable prefix and vary the tail.

One related trap: this is not token-level compression. The AGORA authors tested extractive token-level compressors across 17 agent configurations and reported that all 17 collapsed despite achieving real compression, because the compression broke action grammar. Dropping tokens inside a well-formed fact is a different operation from dropping a whole low-ranking fact.

Where to start

Log the token estimate and memory count on the context calls you already make. Then run one subject at three budgets and find where the answers stop changing. If your curve flattens where mine did, you have your number in an afternoon.

If you would rather not build the compilation and ranking layer, the runtime those numbers came from is Apache-2.0 and on GitHub. It boots against your own Postgres with one command. The longer version of this post carries the full signal list and the receipt model I skipped.

AI agent memory vs RAG — what's the difference?

Statewave — Fri, 11 Sep 2026 15:28:28 +0000

Most teams building on LLMs end up with two patterns in the same codebase: RAG for looking things up in a corpus, and some hand-rolled memory for remembering what the agent has done or what the user has said. The two are often confused, and the confusion costs real engineering time when one is used in place of the other.

RAG retrieves content the agent doesn't already know. Memory retrieves context the agent has already participated in.

They share a vector store but they answer different questions, store different shapes of data, and have different correctness requirements.

The shared substrate

Both patterns sit on top of an embedding store — usually pgvector or a dedicated vector database — and both use approximate-nearest-neighbour search at retrieval time. That's where the overlap ends.

RAG stores chunks of source documents (markdown pages, PDFs, support articles). Retrieval returns the most semantically similar chunks to the user's question, which are spliced into the prompt as grounding.
Memory stores typed records of what happened: episodes (raw conversation turns, tool calls, decisions) and compiled memories (typed facts derived from episodes, with provenance back to the source). Retrieval returns the most relevant prior context for this subject, ranked by recency, kind, validity, and similarity.

If you only need to ground answers in static documentation, you need RAG. If you need the agent to remember the user across sessions, you need memory.

Where RAG breaks down

RAG was designed to answer "what does our documentation say about X?" — not "what did this user tell us last month?" When teams stretch RAG to cover memory, three failure modes show up:

Embedding-nearest is not decision-relevant. A user message "I'm allergic to peanuts" and a later question "What should I order for lunch?" don't have close embeddings. Cosine similarity will surface every restaurant chunk before the allergy note. Memory ranking needs more than similarity — it needs kind priority, temporal validity, and explicit provenance.
There's no compaction. RAG indexes the corpus as-is. Memory has to summarize — turning 200 conversation turns into "user is a senior engineer at a fintech, prefers terse responses" — because the prompt budget is finite. RAG doesn't do that.
No invalidation model. If the user's job changes, the old "works at a fintech" record needs to be marked superseded, not retrieved alongside the new one. RAG's append-only chunk store has no concept of validity windows or supersession.

You can paper over each of these in your application code. Teams that do end up with a memory runtime in everything but name.

Where memory goes beyond retrieval

A memory runtime adds three things on top of the vector store:

Compilation — a pass over raw episodes that produces typed memories — profile facts, preferences, procedures, episode summaries — with confidence scores and validity windows. This is what shrinks 200 turns into one fact.
Deterministic ranking — scoring that mixes similarity with kind priority (a procedure beats a casual mention), recency, temporal validity, and an explicit token budget. Same query → same bundle. No silent re-ordering.
Provenance — every compiled memory carries the IDs of the episodes it was derived from. When an agent answers from memory, the answer is auditable back to the raw event that produced it.

None of those are properties of "RAG" in the literature sense. They're what makes memory infrastructure rather than retrieval over chat logs.

When to reach for which

	RAG	Memory
Question shape	"What does our content say about X?"	"What does this user / agent / project need to know right now?"
Data shape	Document chunks	Episodes → compiled memories with provenance
Ranking signal	Cosine similarity	Similarity + kind priority + recency + validity + token budget
Mutability	Append-only chunks; reindex on doc update	Episodes append-only; memories supersede; compaction is idempotent
Output	Top-K chunks	Token-bounded bundle ready to drop into a prompt

Most production agents need both. The grounding corpus (docs, knowledge base) lives in RAG. The user / account / project context lives in memory.

Trying to make either pattern do the other's job is the common architecture mistake — and it's the one we built Statewave to stop people from making.

What Statewave is in this picture

Statewave is the memory layer — episodes in, ranked context bundles out, with deterministic ranking and provenance. It uses pgvector under the hood (no separate vector DB to operate) but it's not a RAG framework: there's no document loader, no chunker, no retriever interface for grounding-over-corpora. If you want RAG, plug Statewave alongside your existing RAG stack — Statewave handles the who you're talking to layer, your RAG framework handles the what does the knowledge base say layer.

The architecture page on the docs site goes deeper on the ranking signals and the compile-vs-retrieve split. The getting-started guide is a five-minute Docker Compose path if you want to try it side-by-side with your current RAG setup.

FAQ

1. What's the difference between RAG and AI agent memory?

RAG retrieves content the agent doesn't already know — document chunks ranked by cosine similarity. Memory retrieves context the agent has already participated in — episodes and compiled facts ranked by recency, kind, validity, and similarity.

2. Can I use RAG in place of a memory layer for agent memory?

You can stretch it, but three failure modes show up: embedding-nearest isn't decision-relevant (an allergy note won't be the closest embedding to a lunch question), there's no compaction of history into durable facts, and there's no invalidation model for facts that get superseded.

3. Do I need both RAG and a memory runtime?

Most production agents do. The grounding corpus — docs, knowledge base — lives in RAG. The user, account, or project context lives in memory. Trying to make either pattern do the other's job is the common architecture mistake.

4. What does a memory runtime add that a vector store alone doesn't?

Three things: compilation (turning raw episodes into typed facts with confidence and validity), deterministic ranking (the same query always returns the same bundle), and provenance (every compiled memory carries the IDs of the episodes it came from).

5. Is Statewave a RAG framework?

No. It uses pgvector under the hood but ships no document loader, chunker, or retriever for grounding over a corpus. It's the who-you're-talking-to layer, meant to run alongside your existing RAG stack rather than replace it.

6. How do I decide which one to reach for?

Look at the shape of the question. "What does our content say about X?" is RAG. "What does this user, agent, or project need to know right now?" is memory.

Originally published on the Statewave blog. Statewave is an open-source, self-hosted memory runtime for AI agents — GitHub.

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.