Continuum — Durable Mission Memory for Autonomous Agents

Continuum is a durable agent-memory platform on CockroachDB Serverless (AWS) that preserves a mission's operational knowledge so a replacement agent can inherit exactly what its predecessor knew.

Comment

Inspiration

Autonomous systems increasingly run as fleets of specialized agents that observe, disagree, decide, and hand work off to one another. Those agents aren't permanent — they crash, get suspended, exhaust budget, or get replaced by a newer version. Every time one goes away, three things tend to vanish with it: what it observed, why it acted, and what is still dangerous. The usual fallbacks — re-run from scratch, or hope the next agent re-derives the same conclusions from raw logs — are slow and risk repeating a mistake the system already paid for. We wanted continuity to be a first-class capability: memory that outlives any single agent and can be transferred to the next one, with enough integrity to be trusted for safety-relevant decisions.

What it does

Continuum records six artifact types — observations, reasoning, decisions, debates, hazards, and lessons — as immutable Memory Capsules carrying its author, importance, confidence, and time. From those capsules it:

  • Curates Mission Context — a versioned, single-current view that ranks up to 64 capsules that matter now (importance ≥ HIGH, still-open hazards/objectives/decisions, observations from the last 7 days).
  • Publishes Mission Snapshots — immutable, published projections generated at pause, handoff, or completion, with a completeness note.
  • Promotes Operational Knowledge — validated lessons are admitted into a governed Knowledge Vault and can be curated back into future context.
  • Enables handoff and replay — a replacement agent inherits the current context and resumes from a known-good state; the full capsule timeline can be scrubbed to reconstruct any point in the mission.

The deterministic 13-stage ARES-7 demo runs end-to-end over the public REST API — agent registration → observations → hazard → reasoning → debate + resolution → decision + execution → agent failure → replacement → inherited context → lesson promotion → snapshot → replay — writing real rows to CockroachDB the whole way. (The demo agents are simulated autonomous subsystems; Continuum is the memory layer beneath them, not an LLM.)

How we built it

  • SERIALIZABLE isolation is the correctness backbone. A replacement agent bets its safety on inherited Mission Context, so context curation and snapshot publication must never reflect a half-applied write — SERIALIZABLE guarantees they don't.
  • Immutable, versioned history. Memory Capsules and Snapshots are written once and never mutated; Mission Context advances by version behind a single isCurrent row, so you can prove what was known and when — not just read the latest state.
  • Retryable-conflict handling. Concurrent transactions on the same rows can abort with a retryable 40001 conflict (Prisma P2034); the Memory Engine detects these (40001 / P2034) and retries up to 5 times with linear backoff (25–125 ms), so a context build racing the UI's live polling resolves cleanly instead of failing mid-handoff.
  • Mission-scoped serialization. Context/snapshot builds for one mission touch the same current-context rows, so the engine orders them per mission id in-process — the SERIALIZABLE guarantee is unchanged; it's simply not handed avoidable work.
  • Idempotent operations. Agent registration upserts by unique handle and reuses an active assignment; snapshot generation derives deterministically from the current context — so the demo is safe to press repeatedly and any client retry is safe.

Around that: a NestJS REST API (20 endpoints across 3 controllers — 4 agent, 5 memory, 11 mission — with DTO validation and generated OpenAPI/Swagger at /docs), a Prisma schema of 31 models / 19 enums with UUID primary keys and mission-scoped indexes, a Next.js "Mission Control" operator UI with live polling and a replay slider, and a headless, REST-only simulator that drives the same scenario from a terminal (no database access). The application tier holds no durable state — the only in-process structure is a per-mission lock (Map) — so it's disposable and cloud-portable while the mission's memory stays durably on AWS. It's a pnpm + Turborepo monorepo (8 packages — 3 apps, 5 libraries) with 4 test suites (Memory Engine unit, two API integration, simulator scenario) and CI on every push.

Challenges we ran into

The hardest problem was exactly the one CockroachDB is built for. The Mission Control UI polls Mission Context every couple of seconds while the demo also builds context and snapshots — and building context is a write (it flips the current-context row and inserts a new version). Under SERIALIZABLE, those overlapping writes legitimately abort with 40001/P2034, which surfaced as intermittent snapshot failures during the live demo. We solved it in two honest layers: client-side retries — up to 5 attempts, 25–125 ms backoff, keyed on SQLSTATE 40001 / Prisma P2034 (the documented CockroachDB contract), and per-mission in-process serialization so the overlaps are ordered before they reach the database and there's rarely a conflict to abort. Neither weakens the isolation guarantee — one respects it, the other simply stops handing it avoidable work. We verified the production build by completing the full 13-stage browser demo successfully across five consecutive runs after resolving CockroachDB serialization contention.

Accomplishments that we're proud of

  • A memory model that treats the handoff, not the lookup, as the hard problem — a replacement agent inherits curated context instead of re-deriving it.
  • Honest, correct use of CockroachDB's guarantees — SERIALIZABLE, retryable-conflict handling, versioned immutable history, and idempotent writes, each tied to a real requirement rather than added for show.
  • End-to-end reproducibility — one seed, a deterministic 13-stage demo, a headless simulator that proves the API independently of the UI, generated Swagger, and 4 test suites.
  • A clean, stateless architecture where the entire system of record is the AWS-hosted database, so the app tier is disposable.

What we learned

Serialization conflicts aren't failures to be hidden — under SERIALIZABLE they're the database correctly refusing to lie, and the right response is to design for them (retry, and remove avoidable contention at the source) rather than to reach for a weaker isolation level. We also learned how much of "agent memory" is really a data-integrity problem: immutability, attribution, versioned lineage, and snapshots are what let a different agent trust inherited context — properties a similarity-search cache doesn't give you. Finally, keeping the application tier stateless and pushing all durable state into CockroachDB made the whole system simpler to reason about and portable.

What's next for Continuum — Durable Mission Memory for Autonomous Agents

  • Vector Search over Memory Capsules — the schema already carries an embeddingReference field; semantic retrieval would layer on top of the durable operational record, not replace it.
  • Multi-instance deployment — move the per-mission serialization from in-process to a database-level advisory lock so the API can scale horizontally.
  • Governance & access enforcement — classification and authority are modeled today; enforce them at action and handoff time.
  • First-class agent SDK — a reserved agents package soincluding LLM-driven ones) can read and write Continuum memory programmatically.

Built With

Share this project:

Updates

Submission history