We built Statewave because we believe AI should remember.

A context window is per-call state — re-sent, re-priced, and discarded every turn. A memory runtime keeps durable facts outside the prompt and assembles only what the current task needs, packed to a token budget rather than truncated at the end. Statewave ranks candidates on four fixed signals: kind priority (profile_fact 10, procedure 8, episode_summary 5, raw_episode 3), recency, task relevance, and temporal validity (+3 while valid, −4 once expired). The same subject, task, and budget return the same bundle every run.

Every compiled memory carries the IDs of the episodes it was derived from, a confidence score, and a validity window, so any fact an agent used traces back to the raw event that produced it. Context assembly can also emit a state-assembly receipt: an immutable, ULID-addressable record carrying a SHA-256 hash of the exact bytes handed to the model, plus the content hash of the policy bundle in force. "Why did the agent say that, and under which policy?" stays answerable months later.

Storage does not: episodes, compiled memories, and their embeddings live in your own Postgres with pgvector, and ranking is a single local query. What leaves depends on two choices you make. The heuristic compiler runs entirely on your network. An LLM compiler routes through LiteLLM, which supports 100+ providers including self-hosted Ollama and vLLM, so fully local is a configuration you can verify rather than a promise you have to trust.

Teams who want a hosted SaaS — Statewave is self-hosted infrastructure with no managed cloud. Teams who only need nearest-neighbor search, where pgvector or a vector database on its own is simpler. Chatbots with no multi-session requirement, which have nothing to remember. And workloads needing verified high-throughput scale today: the multi-replica API is supported but has not been load-tested beyond 10,000 subjects, on a single Postgres with no cross-region clustering.