Ask a Mem0 or Zep deployment the same question about the same user twice, and you can get two different answers. Not because the underlying facts changed — because both systems retrieve memory at query time, and query-time retrieval over embeddings is a ranking problem, not a lookup. Rerank thresholds shift, nearest-neighbor ties break differently, an LLM summarizer paraphrases the same facts two different ways. For a chatbot that's mostly harmless. For an agent making decisions you'll later have to explain — to an auditor, a regulator, or your own on-call engineer at 3 a.m. — it's a real problem.
Statewave showed up on Product Hunt this month with a narrow, almost stubborn answer to that problem: stop retrieving memory at query time. Compile it once, deterministically, and hand agents the same bytes every time they ask the same question about the same subject at the same point in time. It's open source (Apache-2.0), self-hosted on Postgres with pgvector, and — unusually for a 2026 dev-tool launch — it isn't trying to sell you a hosted plan. There's no SaaS tier. If you want it, you run it.
That's the actual story here, and it's more interesting than "another memory layer for AI agents." Let's get into what it does, how it's built, and whether the determinism bet is one you should care about.
What happened
Statewave launched on Product Hunt as an open-source "memory runtime" for AI agents — the project's own framing, not marketing filler, since the code backs it up. It sits in the same conceptual slot as Mem0 and Zep: give an LLM-based agent persistent, structured memory across sessions instead of stuffing raw chat history into the context window. At the time of writing the GitHub repo (smaramwbc/statewave) has 214 stars — small, pre-hype, the kind of project that hasn't yet had its positioning smoothed out by a marketing team. That's part of why it's worth a close read now rather than after it's been reframed for a Series A pitch deck.
What it actually does
Statewave organizes memory around subjects — a user, an account, an agent, a repo, whatever entity your application needs durable context about. Everything that happens to a subject is logged as an episode: a raw event, like a support ticket message, a code review comment, a tool call result. Episodes on their own aren't memory yet — they're the raw material.
The system then compiles episodes into typed memories with confidence scores, on subject change rather than on every query. When your application needs context for a prompt, it calls /v1/context and gets back a ranked, token-bounded bundle of the most relevant compiled memories for that subject — sized to fit your prompt budget, not a raw dump of everything ever recorded.
The pitch, in the project's own words: "Most memory layers store isolated facts and retrieve them per query… Statewave compiles the context once per subject change, with provenance — which is what buys the higher multi-hop accuracy." Whether that specific accuracy claim holds up under independent benchmarking is untested territory — the project doesn't publish third-party eval numbers — but the architectural claim (compile-once vs. retrieve-per-query) is real and verifiable in the code.
How it works
The pipeline is a clean three-stage design:
- Ingest — raw events land as episodes tied to a subject.
-
Compile — episodes get processed into typed memories with confidence scores, either by a heuristic compiler or an LLM-backed one (
STATEWAVE_COMPILER_TYPE=heuristic|llm). - Assemble — a context bundle is built on demand: ranked, token-bounded, and provenance-tagged.
The determinism guarantee comes from that middle step happening once per subject change rather than once per query. Because the compiled memory state is fixed until the next change, the same /v1/context call against the same subject at the same point in time produces the same bytes — no sampling noise from re-embedding, re-ranking, or re-summarizing.
Provenance is the other half of the pitch. Every bundle ships with a content-hashed, ULID-addressable receipt showing exactly which source episodes contributed to it, HMAC-SHA256-signed, with the policy snapshot that was active at assembly time embedded in the receipt. That's a genuinely useful primitive if you need to answer "why did the agent say that" after the fact — you're not reverse-engineering a vector search, you're reading a signed manifest.
Under the hood it's a fairly ordinary self-hosted stack:
- Database: PostgreSQL 14+ with pgvector ≥ 0.4.2 for the vector side
- Server: Python 3.11+
-
SDKs: Python (
pip install statewave) and TypeScript (@statewavedev/sdkvia npm) - LLM abstraction: LiteLLM, so the LLM-backed compiler can point at OpenAI, Anthropic, Bedrock, Ollama, or 100+ other providers by config
-
Deployment: Docker, Docker Compose, and a Helm chart for Kubernetes; images for
linux/amd64andlinux/arm64
Getting it running is genuinely one command for a demo. There are two supported paths, depending on whether you want a managed local process or full control over the stack:
# Quick local install
npx @statewavedev/statewave
# or
curl -fsSL https://www.statewave.ai/install | sh
# Self-hosted with Docker Compose
git clone https://github.com/smaramwbc/statewave && cd statewave
docker compose up -d
The Compose path boots Postgres-with-pgvector plus the API on localhost:8100, migrations included, in "demo mode" using stub embeddings — meaning you can kick the tires without an API key. To get real semantic retrieval you point STATEWAVE_EMBEDDING_PROVIDER at litellm (or leave it none if you're relying purely on the heuristic compiler) and supply provider credentials. It's a reasonable on-ramp, though worth flagging clearly: the zero-config demo experience is not the same product as a properly embedded, LLM-compiled deployment, and the gap between them is where most of the real setup work lives — configuring a real embedding provider, choosing heuristic vs. LLM compilation, tuning token budgets for your prompt sizes, and deciding when recompilation should trigger for your specific write patterns.
Configuration follows a consistent STATEWAVE_-prefixed environment variable scheme, which is a small but telling detail: it reads like software meant to be dropped into an existing ops toolchain (config-as-env-vars, Helm-chart-ready, Docker-first) rather than software designed around a hosted console. That consistency matters more than it sounds like it should — a memory layer that only exposes its knobs through a dashboard is a memory layer you can't version-control or reproduce in CI, and reproducibility is the entire point of this project.
The connector ecosystem — GitHub, Slack, Discord, Notion, Zendesk, Gmail — is worth a second look too, because it defines where episodes actually come from in a real deployment. Without connectors, "ingest an episode" means your application code has to explicitly call the ingestion API every time something worth remembering happens, which is fine for a purpose-built agent but tedious for retrofitting memory onto an existing product. Connectors turn that into configuration: point one at a Slack workspace or a GitHub org, and support tickets, PR comments, or customer conversations start flowing in as episodes without custom glue code. It's the same shape as how Zapier or Segment turn third-party events into a normalized stream — unglamorous, but it's usually the difference between a memory layer that gets adopted and one that stays a demo.
Beyond the core loop, v0.9 adds multi-tenant support with per-tenant policy bundles and region pinning — relevant if you're building a product on top of this rather than running it for a single internal agent — plus a policy engine with sensitivity labels for tagging PII, financial data, or secrets, and a connector ecosystem covering GitHub, Slack, Discord, Notion, Zendesk, and Gmail for pulling episodes in from where the actual events happen.
What changed vs. the incumbents
The AI-agent-memory space in 2026 has effectively two dominant hosted players, and Statewave is positioned as the deliberate opposite of both.
Mem0 combines a vector store with an optional knowledge graph and retrieves per query. It's hosted-first: a free tier that now covers real prototyping (10,000 memories, not just a toy demo), then paid tiers around $19, $79, and $249 a month as usage scales. Compliance certifications sit behind the Pro tier. The value proposition is speed to "agent that remembers things" with minimal ops.
Zep builds on Graphiti, a temporal knowledge graph where time is a first-class dimension — it's built to answer "what did we know, and when did that change" rather than just "what do we know." Zep Cloud handles the Neo4j operations for you and carries SOC 2 Type 2 and HIPAA attestations, which matters a lot if you're in a regulated vertical and don't want to own that compliance surface yourself. Its Flex plan runs around $125/month for the full temporal-graph engine — worth noting because a $25 figure circulates online that's actually a credit top-up, not the plan price, so check current pricing directly before budgeting.
Statewave doesn't compete on either axis. There's no managed hosting to offload ops to, and there's no temporal knowledge graph — it doesn't claim to reason over how facts evolved through time the way Graphiti does. What it offers instead is determinism and auditability as first-class properties, plus a genuinely permissive license (Apache-2.0, explicit patent grant, usable in proprietary or hosted products without a separate agreement) and a support model that's "run it yourself" with enterprise licensing available by email for teams that want a support contract without wanting a SaaS dependency.
That's a real strategic difference, not just a feature checklist difference: Mem0 and Zep are selling you an operations team. Statewave is selling you a specification and a reference implementation.
Why developers should actually care
Cost. No usage-based markup — you pay for Postgres compute and storage (and optionally LLM calls if you use the LLM compiler), full stop. For a memory layer sitting in the hot path of every agent turn, that can matter a lot at scale, though it also means you're now capacity-planning a stateful database yourself instead of a vendor doing it behind an API meter.
Latency and staleness, not the same thing. Compiling once per subject change means most /v1/context calls are reading pre-computed state rather than re-running retrieval and re-ranking — that should be fast. But it also means memory freshness is bounded by when the last compile ran. If an episode lands and nothing triggers recompilation before an agent asks for context, the agent gets the previous, stale bundle. Mem0 and Zep's query-time approach is slower per call but always reflects the latest ingested state. This is a real tradeoff, not a strict improvement — pick based on whether your agent needs "fast and slightly behind" or "consistent-cost and always current."
Lock-in. Apache-2.0 plus self-hosted plus a REST API means essentially zero lock-in — you can fork it, audit it, or migrate off it without anyone's permission. That cuts against the managed convenience of Mem0/Zep, where migrating means re-exporting embeddings and re-architecting your retrieval calls against a new API surface.
Security and compliance. This is where Statewave's design earns its keep. Signed, content-hashed provenance receipts with embedded policy snapshots are exactly the kind of artifact a compliance team wants when an agent's decision gets questioned — "show me what it knew and where that came from" becomes a database read instead of an investigation. Sensitivity labels and a policy engine for PII/financial/secret data add governance controls upstream of retrieval rather than bolted on after. None of this comes with a SOC 2 or HIPAA badge, though — that attestation burden moves entirely onto you, the operator, which is a meaningfully different cost than paying Zep for theirs.
Maintainability. You're running Postgres with pgvector, migrations, and (if you want real semantics) an LLM compiler pipeline. That's ordinary infrastructure for most backend teams already running Postgres, and materially less exotic than Zep's Neo4j-backed graph engine. It is, however, one more stateful service to keep healthy, back up, and scale — a cost Mem0 and Zep Cloud absorb for you.
Practical use cases
- Regulated-industry support or advisory agents (healthcare, finance, legal) where you need to reconstruct exactly what an agent knew when it gave an answer, with a cryptographically signed trail — not a best-effort log.
- Agent eval and CI pipelines where reproducibility is the whole point: you want the same test inputs to produce the same context bundle every run, so a regression in agent behavior is attributable to a model or prompt change, not retrieval noise.
- Multi-tenant SaaS products embedding agent memory per customer, using the v0.9 per-tenant policy bundles and region pinning for data residency requirements — a genuinely awkward thing to bolt onto a hosted third-party memory API after the fact.
- Internal coding agents that need durable memory of a repo or team's conventions across sessions, where you'd rather not send that context to a third-party hosted memory service at all.
- Incident and postmortem tooling where an agent's compiled memory of an on-call channel or a Slack incident thread needs to be reconstructable months later, with a receipt proving exactly which messages informed a given summary — closer to an audit log than a chat transcript.
- Cost-sensitive, high-volume agent products where per-query retrieval pricing from a hosted vendor doesn't scale economically, and you'd rather pay for Postgres capacity you control than a per-memory or per-call meter.
It's also worth situating this against the rest of the field, since Mem0 and Zep aren't the only names in agent memory. Letta (formerly MemGPT) takes a different approach again, treating memory management as something the agent itself edits via function calls rather than an external compiler. LangChain's LangMem library offers a lighter-weight, framework-native layer for teams already standardized on LangChain/LangGraph. None of these compete directly with Statewave's specific claim — deterministic, provenance-signed compilation — which remains the project's most differentiated ground in a field that otherwise clusters around query-time retrieval in one form or another.
Limitations the launch material doesn't dwell on
- No hosted tier means the ops burden is entirely yours — running Postgres reliably, sizing pgvector indexes, handling backups and failover. That's a real cost the Mem0/Zep pricing pages implicitly hide for you.
- 214 GitHub stars is early. This is a young project without a long production track record; treat the architecture as promising and audit the actual behavior yourself before trusting it with anything regulated.
- The determinism/freshness tradeoff cuts both ways — recompilation timing becomes something you now have to reason about and tune, whereas query-time retrieval systems never have a "stale until recompiled" state by design.
- Demo mode uses stub embeddings. The one-command Docker experience is not evidence of retrieval quality — that only gets tested once you wire up a real embedding provider and, ideally, run your own eval set against it.
- No independent benchmark data for the "higher multi-hop accuracy" claim versus retrieval-based systems. It's a plausible architectural argument, not (yet) a demonstrated result.
- No compliance certifications of its own — the tooling for audit trails is there, but SOC 2/HIPAA attestation is work you'd have to do, not something you inherit by adopting the project.
Competitive read
| Statewave | Mem0 | Zep | |
|---|---|---|---|
| Hosting | Self-hosted only | Hosted (+ self-host option) | Hosted (Zep Cloud) |
| License / pricing | Apache-2.0, infra cost only | Free tier + $19/$79/$249/mo | ~$125/mo Flex plan |
| Core mechanism | Compile-once, deterministic bundles | Vector store + optional graph, query-time | Temporal knowledge graph (Graphiti) |
| Temporal reasoning | Not a design goal | Limited | Core strength |
| Provenance/audit | Signed receipts, built-in | Not a core feature | Not a core feature |
| Compliance certs | None (self-managed) | Pro tier | SOC 2 Type 2, HIPAA |
| Ops burden | High (you run Postgres) | Low (managed) | Low (managed) |
Reading across that table, the honest conclusion is that these three aren't really competing for the same buyer. Mem0 is the fast on-ramp for "agent needs to remember things, ship it this week." Zep is the pick when your product genuinely needs to reason about how facts changed over time and you want someone else owning the graph database and the compliance paperwork. Statewave is the pick when reproducibility and auditability of what the agent knew are non-negotiable, you're comfortable running Postgres, and you'd rather own the whole stack than depend on a vendor's uptime and roadmap.
Independent read
The determinism bet is legitimate engineering, not a marketing wrapper — compiling memory once per subject change and shipping signed provenance with every bundle is a real, verifiable architectural choice, and it solves a problem that genuinely exists: query-time retrieval systems are nondeterministic in ways that are hard to explain to a compliance officer. That's worth taking seriously.
What I'm less convinced of is how large the addressable audience is right now. Most teams building agent memory today are debugging wrong retrieval, not inconsistent retrieval — the failure mode they actually hit is "the agent forgot something relevant," not "the agent answered the same question two different ways." Determinism-as-a-feature is the kind of thing that matters enormously once you have it and almost not at all until the day you desperately need it — which makes it a hard sell to a team that hasn't been burned yet. Shipping without any hosted option, in a category where the two incumbents compete partly by offloading ops, is also a real adoption tax: it filters the audience down to teams that specifically want to self-host, which is a smaller circle than "teams that need agent memory."
None of that makes the project wrong. It makes it early and narrowly aimed — which, for a 214-star repo a week off Product Hunt, is exactly what you'd expect from a team building for a specific pain (compliance, audit, reproducible eval) rather than chasing the broadest possible market.
Who should try it, wait, or skip it
Try it now if you're building agent workflows in a regulated space and need to answer "what did the agent know and when" with something more rigorous than log lines — or if you run agent evals and reproducibility of context is currently a source of flaky results you can't explain.
Wait if you just need an agent to remember user preferences across sessions and want the fastest path there — start with Mem0's free tier, and only look at Statewave once you hit a concrete need for provenance or determinism that the hosted option can't give you.
Skip it if your actual requirement is temporal reasoning over evolving facts — "what did we believe about this entity last month vs. now" — since that's Graphiti's specific strength and not something Statewave's compile-once model is built to do, or if you have no appetite for operating another stateful Postgres service in production.
Given how early this is, the most useful thing you can do if the architecture interests you is read the compiler code yourself rather than take the accuracy claims on faith — it's a small enough project that a real audit is a weekend, not a quarter.
If you've built or evaluated an agent memory layer in production: has nondeterministic retrieval actually bitten you badly enough to justify trading it for a self-hosted, compile-once architecture — or has "wrong" memory always been the bigger problem than "inconsistent" memory on your team?
Sources:
Top comments (0)