Continuum

Agentic memory on CockroachDB — proven to survive losing an entire cloud region, not just claimed to.

Comment

Inspiration

Most agent memory today is either nothing — every session starts blank — or one undifferentiated vector store where everything gets dumped in as "semantic" and recency stops mattering. Neither matches how memory actually needs to work. A support agent needs to remember what happened this turn, what happened last week, and a durable fact about the user, and those three things have genuinely different retention and recall needs. And none of it matters if a region outage wipes the data out the moment someone actually relies on it. We wanted to build memory that's provably production-grade, not just plausible in a demo.

What it does

Continuum gives any MCP-compatible AI agent persistent memory across three tiers — working (short-lived, TTL-based), episodic (a durable, recency-ordered log), and semantic (long-term facts, recalled by embedding similarity) — exposed as four MCP tools: store_memory, recall_memory, list_episodes, forget_memory. It runs on a single CockroachDB cluster spread across three AWS regions, explicitly configured for CockroachDB's REGION survival goal, so losing an entire region still leaves the database serving reads and writes.

How we built it

The database side uses CockroachDB's Distributed Vector Indexing for the semantic tier (VECTOR(1024), cosine distance) and the Cloud Managed MCP Server to inspect and verify the live deployment directly — cluster topology, schema, and the multi-region configuration — rather than only through a raw SQL connection. Semantic-tier embeddings come from Amazon Bedrock (amazon.titan-embed-text-v2:0). The MCP server itself is Python, built against the official MCP SDK, and runs as a container — originally targeting AWS Lambda, actually deployed on Fly.io once real AWS account access didn't come through in time.

Challenges we ran into

Several real bugs only showed up by actually building and deploying, not by writing the design first:

  • A vector index built without an explicit operator class defaults to vector_l2_ops; querying with <=> (cosine) silently falls back to a full table scan instead of erroring.
  • A database on a multi-region cluster stays single-region until ALTER DATABASE ... SURVIVE REGION FAILURE is explicitly run — nothing warns if this step is skipped.
  • The schema originally declared VECTOR(1536) (OpenAI's dimension), not Titan's actual 1024, caught before any real embeddings were written.
  • Real AWS account access for the hackathon never arrived, so the reference agent runs on a local harness instead of real Bedrock Agents, and Lambda was never actually deployed — Bedrock itself is the one AWS service we could genuinely verify end to end.
  • Deploying the real MCP server to Fly.io (once Lambda access didn't come through) surfaced a live bug: the MCP SDK auto-restricts accepted Host headers to localhost, which any real reverse proxy breaks with a 421 — invisible if we'd only ever tested locally.

Accomplishments that we're proud of

Cross-session recall is proven against the live cluster, not simulated: a second session, sharing nothing but an actor ID, recalls what a first session stored, before the agent responds. The multi-region configuration is proven the same way — SHOW SURVIVAL GOAL FROM DATABASE defaultdb returns region on the deployed cluster, confirmed independently through both a direct SQL connection and the Cloud Managed MCP Server's own tools.

What we learned

A doc or a test suite that reads as complete isn't the same as one that's verified. Late in the build we found test names in our own documentation that didn't correspond to any real test in the codebase, and claims about tool usage that had gone stale after a scope decision changed elsewhere. Checking every claim against the actual filesystem, test collection, and live cluster — not just re-reading prose for tone — caught real gaps that would otherwise have shipped.

What's next

Real AWS Lambda deployment and Bedrock Agents integration are both fully specified (Terraform exists, the swap-in path is documented) and just waiting on account access — nothing about the underlying tool contracts needs to change either way.

Built With

Share this project:

Updates