Write, Retrieve, Govern: What Statewave's Memory Model Gets Right, and What a Hosted Layer Adds

Your scheduled agent finishes a run, and the next run starts as if nothing happened. The customer it helped yesterday is a stranger again, the decision it recorded last week is gone, and the brief you gave it on Monday has to be given again. That is not a bug in your prompt. It is how the model works: the model itself is stateless, and everything that feels like memory is something your application wrote down and fetched back before the call.

Fixing that gap means building, or connecting, a layer outside the model. Two approaches show the choice clearly. Statewave builds a governed memory runtime you run yourself, organized around three verbs: write, retrieve, govern. Vilix AI offers a hosted memory layer you connect over MCP, built around full conversation history that follows you across tools. Both answer the same question. They answer it for different teams.

The session boundary is the whole problem

A context window is working memory, not storage. When the session ends, the window clears. Nothing carries over unless something outside the model saved it, and saving it is only half the job. The saved material also has to come back in the right slice, at the right time, inside a token budget that leaves room for the actual task.

Statewave's own guide makes the cost of getting this wrong concrete. On the deep memory retrieval benchmark in the MemGPT paper, GPT-4 scored 32.1% working from a summarized history and 92.5% with a memory architecture in front of it. Same model, same questions, a gap of about 60 points from the plumbing alone. A longer prompt does not close that gap. The right stored context, retrieved well, does.

Statewave: write, retrieve, govern

Statewave's model has three stages, and each one earns its place.

Write first. Raw events go in append-only and are never edited, which is what makes provenance possible later. You post episodes keyed to a subject, such as a customer, a repo, or an account. The raw record stays intact even as the conclusions drawn from it change.

Retrieve second. Episodes are compiled into typed facts with confidence scores, in an explicit compile step, rather than at query time. Because compilation happens before the query, the same query against the same subject at the same point in time returns the same bytes. Retrieval is a ranked, token-bounded bundle, not an open-ended dump of everything ever stored.

Govern third, and this is where Statewave is most distinct. When two agents assert different values for the same fact, the compiler resolves on structured claim keys, not text similarity. The older memory is marked superseded with a time interval, so it stays on the timeline and you can still answer what the agent believed last Tuesday. Statewave's guide uses a plan change as the test case: a customer is on the Pro plan in January and downgrades in April. A plain vector store holds both facts and lets similarity decide which one the agent sees. A governed store supersedes the January fact, so the April fact is the one that reaches the next run.

The token budget is explicit, too. A context request takes an optional max_tokens between 1 and 128,000, the server default is 4,000, and the reference client sets 800 so the rest of the prompt keeps room. A bundle is sized to your prompt, not to your corpus, so a growing memory store does not grow the prompt with it.

What running Statewave yourself involves

Statewave is self-hosted only, and its guide is upfront about that: there is no managed cloud, so events live on infrastructure you control. The local boot is one command, npx @statewavedev/statewave, which starts the API, the admin console, and Postgres on localhost:8100, with no account. The core runtime is Apache 2.0, and it runs on Postgres with the pgvector extension, so memory sits under the same backup and access control as the rest of your data.

The default boot is demo mode, with stub hash-based embeddings and a heuristic compiler. That gives you a working loop but no real semantic search. For real semantic search, you set the LLM compiler and an embedding provider, then check the readiness endpoint. The guide also names failure modes to design for from the start: a fact invented at write time is hard to undo, so keep the raw episode, and a correct but stale fact can still produce a bad answer.

For a team that needs audit receipts, supersession timelines, and claim-key conflict resolution, that work buys exactly the control it needs.

Vilix AI: the hosted layer for scheduled agents

Vilix AI takes a different approach to the same question. It is a cloud-hosted memory layer, so there is zero infrastructure to provision, back up, or maintain. You connect once, and the same memory follows you across tools over MCP: your phone apps, your laptop, and every AI tool you use, all reading the same memory.

Where Statewave compiles events into typed facts, Vilix AI stores full conversation history, not just extracted facts, alongside projects, tasks, and rules. That distinction matters for scheduled agents. When the question is what was agreed, what was corrected, and what was said around a decision, the full conversation answers it in a way a compiled fact alone cannot. Retrieval is semantic as well as keyword-based, so an agent finds relevant context even when the wording differs from the original turn.

For a scheduled agent, the practical effect is direct. The agent that runs on Tuesday reads what the Monday run learned, including the correction that came after the first attempt. It does not re-brief from scratch or act on a plan, address, or preference that changed since the last run. Your data stays portable: export everything or delete it anytime. The free plan is free forever, with a 7-day Pro trial and no credit card.

How to choose, and how to test either one

Pick the governed, self-hosted model if you run your own infrastructure, need audit receipts and supersession timelines, and want conflict resolution decided by structured claims rather than by whichever model answered last. Budget the real work: Postgres with pgvector, the compile step, and the governance configuration before production data arrives.

Pick a hosted layer if you need memory that works today across every tool you already use, with full conversation history plus projects, tasks, and rules, and nothing to provision or maintain. That is the shape that fits most automation operators: the agent is one of many tools in a workflow, and memory should be a connection, not another system to operate.

Whatever you pick, run the same test before you trust it with real customers. Take a test subject, save a fact, change that fact, and check which version the next run retrieves. Then delete the subject and verify the derived records are gone. A memory layer that passes that test is one your scheduled agents can build on.