Continuum
Verifiable memory for AI coding assistants
For: Solo founders, small teams, consultants and AI-assisted builders working in Claude Code, Cursor or Claude Desktop; also product teams embedding tenant-scoped memory.
Anyone who builds software with an AI assistant knows the routine: every session starts blank, and the first part of the day goes into re-explaining what shipped, what broke and what was decided last week. Continuum ends that. It runs as a Model Context Protocol (MCP) server beside the assistant and keeps a persistent, checkpointed memory of the project.
It aggregates five sources of project truth: local documentation, observations from earlier AI sessions, human feedback, git commit history and full session transcripts. From these it produces a briefing the assistant reads before the first reply, timestamped snapshots of what was active, dormant or broken, and a live list of open commitments.
What sets it apart is a rule called verify-then-dissolve. A task in the todo pipeline is not marked complete until its verify command exits successfully. The assistant cannot simply claim it has finished; the shell has to agree.
Continuum is aimed at solo founders, small teams and consultants who ship with AI help. It installs from npm, stores data locally by default, and the same engine can be run hosted or embedded per tenant inside other products.
~2.85x
fewer retrieval tokens, measured on the repo's own history
5
sources of project truth in one memory
What it does
Session-start briefing so the assistant opens with current state, open todos and recent progress
Five-source aggregation: docs, AI memory observations, human feedback, git history and session transcripts
Verify-then-dissolve: a todo closes only when its verify command exits 0 (continuum verify)
Three-layer progressive disclosure (search index, timeline, full fetch by ID) to keep token use low
Append-only, hash-sealed state checkpoints you can query by date
Privacy filter that scrubs API keys, tokens and personal data at ingestion, before anything is written
Hook-driven capture from the AI client's lifecycle events, with no manual note-taking
Operator console with a 3D 'Brain' view of the memory and per-node dossiers
How we architected it
- TypeScript
- Node.js
- Model Context Protocol SDK
- SQLite (better-sqlite3, FTS5)
- RuVector
- Transformers.js (MiniLM embeddings)
- Express
- jose (JWT)
- Next.js
- React
- Three.js / react-force-graph-3d
- Mermaid
- Vercel AI SDK
- Anthropic Claude
- Astro Starlight
- Docker
- Fly.io
- Vercel
- 01
Monorepo of TypeScript packages: core (storage, types, checkpoint engine, privacy filter), mcp-server, cli and source adapters for docs, git, remote git and export
- 02
MCP server exposes tools, resources (continuum://…) and prompts over stdio for local use or HTTP/SSE for remote and hosted use
- 03
Ingestion is driven by AI-client lifecycle hooks (SessionStart, UserPromptSubmit, PostToolUse, Stop, SessionEnd); every input is normalised into one Observation record and passed through the privacy filter on a single write path
- 04
Storage sits behind one StorageBackend seam: SQLite with FTS5 keyword search, plus a hybrid mode adding RuVector HNSW semantic search over MiniLM embeddings
- 05
Per-tenant data plane (one SQLite file and vector index per workspace) with a planned thin Postgres control plane for directory, auth and billing
- 06
Hosted engine runs as a Docker container on Fly.io (continuum-engine) with a persistent volume; remote access is protected by a bearer token or JWT
- 07
Next.js operator console and Astro Starlight docs site deploy on Vercel; the console talks to the engine over the HTTP/SSE transport and uses Anthropic models for its ask feature
Want something built like this?
Every build runs the same five gates: spec, architect, build, review, ship. It starts with a 48-hour audit.