Statewave Makes Agent Memory Reproducible: A Self-Hosted Alternative to Mem0 and Zep

An agent that says “I deployed the last known-good revision” needs to answer a harder question than an agent that merely remembers a preference: which facts did it use, and can an operator reproduce that answer? A vector search that returns a useful snippet is valuable. It is not, by itself, an audit trail.

That distinction is why Statewave is interesting. It is an Apache-2.0, self-hosted memory runtime backed by Postgres and pgvector, but it is not trying to be a generic chat-history dump or a drop-in replacement for every memory product. Its repository describes an append-only event layer, a compilation step that creates typed memories, and token-bounded context bundles that carry provenance back to source episodes.

The practical answer for a deploy-from-chat platform is equally specific: run durable agent memory as a tenant-owned service beside the PaaS control plane, not inside the control plane. That preserves a useful boundary. The platform remains authoritative for authorization and the current deployment state; the memory service supplies attributable context to an agent. Here is the architectural trade-off in one view.

The table is a boundary map, not a leaderboard. A team choosing among these systems should first decide whether its difficult question is “what context is most relevant now?”, “how has a fact changed over time?”, or “what exact evidence was supplied to a privileged agent?” Statewave is most directly aimed at the last of those.

What Statewave changes: compile context before the deploy conversation​

Consider an agent investigating a failed production deploy for tenant:acme:

1. A deploy tool records an episode: commit 8f3c, build failed at 14:03 UTC, with a source link to the build log.
2. A rollback tool records a second episode: revision 8e11 was promoted at 14:08 UTC by an approved actor.
3. An incident command records that the database migration was intentionally skipped during the rollback.
4. Statewave compiles those source events into typed durable memories for the subject and creates a bounded context bundle for the task, “Explain the current release state and whether a retry is safe.”

The difference is more than a naming convention. Statewave’s documented flow is ingest, compile, retrieve, and govern. Rather than asking a model to freshly summarize an arbitrary pile of matching records on every request, the compilation stage creates a reusable representation after subject changes. The bundle can include source episode IDs; its receipt is intended to record the memories and policies that affected assembly.

That gives an operator a clean investigation path: the agent’s sentence links to the compiled memory, which links to the event, which links to the build or rollout record. It does not prove that the agent took the right action, and it must not replace a real authorization decision. It does make a disputed answer inspectable in a way that “the retriever found something similar” usually is not.

pgvector still has a role here, but it is not the entire mechanism. The extension puts vector similarity search in Postgres, with exact and approximate nearest-neighbor search available alongside ordinary relational data. Statewave can use that substrate when ranking or selecting memory. The source-of-truth operational story remains episodes, compiled memories, retention rules, and receipts—not an HNSW index alone. That distinction matters when someone asks why a fact appeared in an agent’s context.

Self-hosting it means owning the boring, important parts​

“Runs on Postgres” is a useful deployment property, not an outsourcing of operations. A small production design has at least five explicit boundaries:

Postgres gives the service familiar primitives: transactions, backups, replication, row-oriented inspection, and—through pgvector—vector search. It also gives the operator responsibilities: index memory, migration discipline, disaster recovery tests, and a clear answer to whether backups are encrypted and how long they live. A multi-tenant PaaS should not quietly inherit those decisions from a library default.

The least surprising deployment is therefore a separate service and database per environment, with PaaS workloads reaching it through an internal authenticated endpoint. A tenant may choose a dedicated database or a carefully enforced shared deployment, but the data boundary should be visible in the API and operations model either way.

Keep memory next to the control plane, not inside it​

A deploy agent needs three distinct kinds of state. Blending them is the mistake to avoid.

• Control-plane truth is current service configuration, revision state, logs, and rollout status. It belongs to the PaaS API and its authoritative database.
• Authorization and immutable audit history answer who was allowed to deploy, approve, or roll back. They belong to the identity and audit systems, with durable server-side enforcement.
• Agent memory is derived context: prior investigations, a decision’s rationale, an incident timeline, or a repository convention. It should be helpful but never the source of permission.

For an MCP-enabled workflow, this can be made concrete. get_deploy_status and rollback_service should be idempotent, tenant-scoped tools that check the caller’s authority against the PaaS. After a tool completes, an event publisher can send a minimal, scrubbed episode to the tenant’s memory service. Before a diagnosis, the agent asks Statewave for a bounded context bundle for a subject such as tenant:acme/service:billing and a narrowly stated task. The tool result—not the bundle—remains the final authority on whether a rollback happened.

That shape also supports a useful subject scheme:

tenant:acme
tenant:acme/service:billing
tenant:acme/service:billing/release:8f3c
tenant:acme/incident:2026-08-29-payment-timeouts

Subjects make retention and deletion decisions legible. A tenant can ask for memory about an incident to expire while retaining approved operational runbooks, and the platform can prevent cross-tenant context from ever being assembled. It is much harder to reason about those promises if a global PaaS database silently contains every agent’s long-term memory.

Mem0 and Zep answer adjacent questions, not the same one​

Mem0’s own documentation distinguishes between its self-hostable open-source offering and its managed Platform. Its graph-memory material describes extracting entities and relationships alongside embeddings, while the Platform overview emphasizes managed vector, graph, and reranking infrastructure. That makes Mem0 a sensible fit when an application wants memory extraction and recall with a deployment model it can choose. It does not make every Mem0 use case equivalent to a compiled, replayable context bundle.

Zep emphasizes a temporal Context Graph: it ingests conversations and business data, models entities and changing relationships, then returns engineered context. That is attractive when an agent must answer questions like “what did this customer believe before the contract changed?” or connect facts across many sessions. A deployment investigation may benefit from that temporal model too. The question is whether graph reasoning is the central requirement, or whether a platform first needs a defensible record of the inputs supplied to a privileged operational agent.

There is a valid fourth option: do not add durable memory yet. A short-lived deploy assistant that only reports authoritative live state may be safer and cheaper without it. Durable memory earns its operational cost when users need continuity across incidents or shifts, and when the team has a concrete way to govern its data.

A four-step pilot that keeps the boundary intact​

Start with a limited pilot instead of making agent memory a PaaS feature promise.

1. Pick one read-only investigation. Use build-failure triage or release-status explanation—not deploy approval—as the first task.
2. Ingest narrow events. Send release IDs, timestamps, status transitions, and scrubbed diagnostic references. Exclude tokens, environment variables, and raw customer payloads.
3. Test the receipt path. Have an operator trace one agent answer back through its bundle to its source episodes, then delete a test subject and verify the documented deletion path.
4. Measure usefulness and risk. Track whether context improved the investigation, how often it was stale, what it cost to operate, and whether the team could explain every data flow.

If those tests pass, the integration can expand to incident handoffs and repository-aware operational guidance. If they do not, the PaaS has lost nothing: its deploy API, permissions, and audit trail never depended on memory being embedded in the control plane.

Statewave’s model is compelling precisely because it treats agent context as an artifact with a lifecycle, not an invisible prompt embellishment. For a self-hosted platform, that is a useful option to expose beside an MCP surface—one a tenant can operate on infrastructure it controls—while keeping deploy authority where it belongs.

Bex.co is an open-source, AI-native Render alternative: push a git repository and run an HTTPS service on machines you own. Its Render-compatible API and agent-oriented control surface make this kind of explicit integration boundary more useful than a hidden platform-specific memory feature. Explore the project on GitHub.

Sources​

• Statewave repository and architecture
• Statewave design-partner guide
• Mem0 open-source graph-memory documentation
• Mem0 Platform overview
• Zep key concepts and temporal Context Graph
• pgvector documentation