Memory for every AI tool, on a runtime that doesn't lose work.
Continuum is a context platform: one memory, behind one interface, that every tool, model and agent reads and writes. It spans Postgres, Qdrant, FalkorDB and ClickHouse, recalls the way ACT-R and Soar model memory, and runs every model call on a durable workflow. Self-hosted, deployed as one unit.
UPDATED 2026-09-24 · VERSION 0.2
A context platform
Every AI tool you use starts from zero. Open a new chat, or move from your editor to a PR review, and the context you built up is gone. Continuum keeps it: what your tools and agents learn goes into one memory, recall brings back what the task in front of them needs, and it says so when it doesn't know.
Claude Code, Copilot, Cursor and any other MCP client read and write that same memory, and your own integrations reach it over HTTP. The whole team shares it, so what one engineer's assistant learns is there for everyone else's. Underneath, every model call runs on a durable workflow, so a crash costs a retry instead of the answer. It is self-hosted, and deploys as one unit wherever you run it.
The system
Clients hand work off, and workers carry it.
Continuum is seven hosts, five stores and Temporal, composed by one .NET Aspire AppHost. Each app calls the host it needs directly: the Gateway for inference, Chat for conversations, Cortex for context. Temporal turns the long-running work into workflows, and a swarm of workers runs every workflow and the model calls inside it. The Relay tells clients when their work is done.
Postgres holds the truth and Redis carries the streams. Qdrant and FalkorDB are projections of Postgres, rebuilt from it, and ClickHouse keeps the timeline of what happened. The inference path runs on three rules: the Gateway never calls a model, workers never call clients, and clients never connect to Redis.
What runs where
| Host | Runs |
|---|---|
gateway | Sessions, inference submission, output retrieval and system health |
chat | Threads and messages, and the token stream to the Dashboard |
cortex | The context API: entries, search, document ingest, the knowledge graph and quick completions |
relay | Tells clients a run finished (inference, extraction, projection or agent) over SignalR and raw WebSocket |
identity | The authenticated user's profile |
swarm-worker | Every Temporal workflow, and the model calls inside them. Add workers to add capacity |
apphost | Declares and starts every store and host |
| App | For |
dashboard | A person: chat, the reasoning panel, ingest, and the context and graph views |
console | The operator: inference demos, the model runtime and the evaluation harnesses |
mcp | Other agents: context tools over the Model Context Protocol |
terminal | The command line: seeding, ingest and search |
Durable inference
A worker can die mid-answer, and the answer still arrives.
The Gateway reads the request body once and writes it twice: into a Redis stream
keyed {userId}:input:{messageId}, and into Postgres as the user's
message beside an empty assistant reply. It starts a Temporal workflow named
inference-{messageId} and answers 202 Accepted with the
thread and message ids. The client is free before the model has seen a token.
POST /v1/sessions/{sessionId}/infer
(the prompt, streamed as the request body)
HTTP/1.1 202 Accepted
{ "threadId": "…", "messageId": "…" }
# later, pushed by the Relay over SignalR or a raw WebSocket
ServerInferenceCompleted messageId: …
GET /v1/inference/{messageId}/output
A worker takes the activity from the task queue. Each attempt starts by deleting
whatever output an earlier attempt left behind, reads the prompt back out of the
input stream, and streams the model's tokens into
{userId}:output:{messageId}. The prompt stays in Redis until an
attempt succeeds, so a retry reads exactly what the first attempt read.
If the worker dies, Temporal still holds the workflow's history, and schedules the next attempt on whichever worker is free. Each attempt gets five minutes. Retries back off from five seconds to two minutes and keep coming for thirty minutes, with no cap on the count, because a provider that rejects a request outright stops them at once.
When the answer is written, the worker tells the Relay, and the Relay pushes
ServerInferenceCompleted to the session. The client fetches the output
through the Gateway, which reads the stream and falls back to the completed message
in Postgres.
The alternative was a queue with a retry loop around the model call. That works until the process holding the loop dies, and then the retry logic needs durable state of its own, a dead-letter queue, and something to reconcile the two. Temporal is that durable state. It is heavier to run than RabbitMQ, and M0 measured what it costs a request: 3.5% latency at p99.
The pattern behind it is written up in When call three fails, you pay for six →
The context store
Postgres holds the truth, and the graph and the vectors are rebuilt from it.
PostgreSQL 🔗
Append-only chronological truth. Every decision, pattern, and observation recorded with confidence scores and typed relationships.
FalkorDB 🔗
Knowledge connected through typed edges. Cypher traversal for spreading activation - retrieval that works like human associative memory.
Qdrant 🔗
Vector embeddings for natural language queries. The entry point to the knowledge graph - ask a question, walk the neighborhood.
A context entry is written to Postgres first, every time. Cortex then starts a projection workflow for it, and a worker embeds the entry through the model runtime, upserts the vector into Qdrant and the node into FalkorDB. Qdrant answers what is like this, and FalkorDB answers what connects to this.
A reconcile sweep runs on a schedule and re-projects any entry that is missing or stale in either projection. A Postgres commit and a workflow start can't share a transaction, so the sweep is what makes the projections converge on the truth.
Ingest is idempotent. Each source has a manifest identity, so feeding the same document twice changes nothing, and feeding a new revision supersedes its old entries instead of duplicating them. A model pass then reads each section and pulls out claims, the unit that recall ranks. Every claim records who asserted it, and a model is an author too: its claims name the model and the configuration it ran under.
ClickHouse is the fourth plane, an append-only timeline of what happened to each entry and when. Every time-decayed term in recall reads from it, and it is the one store nothing else can rebuild. A use is recorded when a reply cites an entry, by the enrichment pass that reads the reply. What retrieval merely returned is never recorded, because logging it would feed the retriever's ranking back into itself.
The alternative was to make the vector index the memory, as most AI memory does. Changing the embedding model then means re-ingesting everything from wherever it came from, assuming you kept it. Here it means re-projecting from Postgres.
Total Recall
Recall ranks the way memory does, with forty years of cognitive science behind it.
Retrieval ranks by the activation equation from ACT-R, John Anderson's cognitive architecture from Carnegie Mellon, fitted against human reaction times across hundreds of experiments. Candidates come from full-text search, semantic search and the graph neighbourhood at once, and one scoring pass over Postgres ranks them, reading each candidate's history of use from the event plane.
- Base-level learning. Every past use of a claim, each faded by
its own age and summed on a log scale, puts frequency and recency in one term.
It decays as a power law with
d = 0.5, the same law FSRS found independently, decades later, in tens of millions of flashcard reviews. - Spreading activation. What is being discussed lends strength to what it connects to, several hops out through the graph, decaying with each hop. The multi-hop form is Soar's, from John Laird's architecture at Michigan. A vague cue lends less than a precise one, which is the fan effect.
- A retrieval threshold. A memory below it doesn't come back at all, so the answer can be I don't know.
- Graceful forgetting. Knowledge nobody uses sinks below the threshold without being removed, and a strong enough cue brings it back.
- An authority ceiling. However often a claim is recalled, it rises no higher than its evidence allows. The ceiling is a cap and never a weight, so repetition can't buy standing.
Scores are computed at query time and never written back. Every result decomposes its score term by term, and why wasn't this retrieved has an answer. The inference activity assembles that context into the prompt before the model call.
The science is written up as a five-part series, starting with Activation →
Correctable
The context store protects the way it gets corrected.
A ranking that weights by authority can be captured, and whoever operates it is best placed to capture it. So Continuum protects the process by which it gets corrected, with four laws in order of precedence.
- Preservation. Nothing is destroyed, only superseded.
- Reachability. Nothing is made permanently unreachable.
- Contestability. A contradiction is always surfaced, and a correction competes on at least equal footing with what it corrects.
- Accountability. Every claim says who asserted it, where, how and when.
Where the laws are silent, one rule governs: do not misrepresent what you hold. The operator is assumed to be a possible adversary, so no safeguard depends on a model behaving.
Every tool
The team and every tool it uses share one memory.
The MCP server exposes the context API to any client that speaks the Model Context Protocol: Claude Code, Claude Desktop, Copilot in VS Code, Cursor, or an agent you wrote yourself. It runs over stdio for a client on your machine, or over HTTP as a server the whole team connects to. Through it, an agent searches context, creates and updates entries, ingests documents and assembles context for a task.
A custom integration doesn't need MCP at all. The context API is plain HTTP on
Cortex, and ICortexClient, the .NET client that the MCP server, the
Dashboard and the Terminal are built on, is there for a CI job, a chat bot or an
internal service to use the same way. The Terminal seeds a project and ingests
documents from the command line.
The memory the runtime uses is the memory your editor uses, and your coworkers' editors too. One engineer's caching decision reaches another engineer's latency investigation three weeks later, without either of them knowing the other exists, and a new hire's assistant starts on day one with the team's weighted history. Every claim names who asserted it, so a colleague's decision arrives with their name on it, and anyone's correction competes on at least equal footing with what it corrects.
Why it's built this way
Most AI memory is a search box with a long attention span.
| Typical AI memory | Continuum | |
|---|---|---|
| Where it lives | Per tool: a chat history, a rules file, a vector index | One memory, behind one interface, that the whole team and every tool it uses read and write |
| What comes back | The nearest neighbours by cosine | What would come to mind: use, recency and association |
| What counts as use | Whatever retrieval returned | Only what a reply cites |
| When nothing fits | The top k anyway | Nothing, below the retrieval threshold |
| Old knowledge | Kept at full strength, or deleted | Fades from recall and is never deleted |
| Contradictions | The latest write wins | Both surfaced; the correction competes on equal footing |
| Repetition | Raises rank | Capped by evidence |
| A worker dies mid-answer | The request is lost | Temporal schedules another attempt |
| Where it runs | A managed service | Your hardware, deployed as one unit |
That is a lot of machinery for remembering things. Each piece is there because a failure needed it: Temporal because a model call can outlive its process, Postgres because projections drift, and ClickHouse because a term that decays with time needs evidence of time. Aspire keeps it one command to start.
Where it's going
Each layer is built once the layer beneath it can carry it.
- M0 Durable inference Every model call on a durable workflow, first, because everything later runs on it.
- M1 A place to keep context The context store and the Dashboard, because nothing can be recalled that was never kept.
- M2 Recall Activation over the context store and the event plane beneath it, because lookup is not memory.
- M3 Every tool The same memory opened to other agents, last, because a contract is worth publishing once the ranking behind it can be defended.
Demo B proves the arc end to end: seed a corpus, embed it, graph it, assemble context and infer, with the assembled context measurably better than none, and attributably so.