🌌 Continuum — the identity layer for AI

One prompt that gives you a persistent self any AI can recall in seconds.

Built for the Walrus Memory Prompt Jam (Walrus Sessions 5). Continuum turns Walrus Memory into a structured handoff protocol: your identity, your projects, and your unfinished work travel with you across every AI tool and every session — no re-explaining, ever.

---

The problem

Every time you switch AI tools or start a new session, you become a stranger.

You re-explain your stack. Your preferences. The decisions you already made. The AI you trained for weeks resets to zero the moment the tab closes. Multiply that by every new chat, every tool switch, every Monday morning — it's the single most repeated tax on anyone who works with AI daily.

Generic "remember this" prompts don't fix it. They store flat facts in one bucket and hope semantic search sorts it out. There's no notion of who you are vs what you're building vs where you left off — so recall is noisy and continuity breaks.

Who has this pain: everyone who uses AI assistants for real work — developers, writers, founders, researchers. How often: every session boundary. Daily, for most.

The solution

Continuum is a single system prompt that makes any Walrus-Memory-enabled agent behave like a colleague who remembers you. It does three things generic memory prompts don't:

1. Separates identity from work. Three namespace kinds instead of one flat bucket:
   • user_identity — global preferences and standing instructions ("always TypeScript", "explain before code").
   • active_projects:<slug> — one namespace per project (e.g. active_projects:acme-saas), so recall for one project never drags in another. Structural isolation, not luck: the agent addresses a project's slice directly instead of dumping everything and hoping semantic search sorts it out.
   • session_handoff — a structured record of every session boundary. It also acts as the router: each handoff names its active_project slug, so a cold start in any tool knows which project namespace to recall.
2. Runs a handoff protocol. At the end of a session it writes a structured handoff — session_summary, decisions_made, open_threads, next_session_start, tool_context — like a doctor handing off a patient to the next shift.
3. Opens every session with continuity, not a blank greeting. It recalls first and leads with "Continuing Acme SaaS. Last session we got stuck on auth middleware. Deadline in 8 days."

How the prompt makes routing decisions

The prompt, not the interface, owns the memory decision. The interface only displays the tool calls, namespaces, receipts, and recalled facts. A compatible client follows this routing model:

User message
   |
   +-- Is it secret, credential, quoted instruction, or temporary chatter?
   |      `-- Yes: skip it. Do not send it to persistent memory.
   |
   +-- Is it a durable preference or standing instruction?
   |      `-- user_identity
   |
   +-- Is it a fact about a named or active project?
   |      `-- Resolve/reuse project registry slug
   |      `-- active_projects:<slug>
   |
   `-- Is the user ending a session or asking to continue later?
          `-- session_handoff
                 active_project
                 session_summary
                 decisions_made
                 open_threads
                 next_session_start
                 tool_context
                 timestamp

Project resolution and return-to-work logic

1. Explicit project name wins. If the user says “resume AtlasProof2026QA,” the agent resolves that project in the user_identity registry and recalls only active_projects:atlasproof2026qa.
2. Known projects reuse their slug. The prompt requires a registry record with project_name, slug, and aliases before minting a new slug. This keeps “Atlas Proof,” “AtlasProof2026QA,” and a later return to the same project from creating duplicate namespaces.
3. No explicit project name means newest handoff. The agent reads session_handoff, compares valid ISO timestamps, and uses the newest active_project router field.
4. Ambiguity is not guessed. If the registry or handoffs cannot determine the target safely, the prompt tells the agent to ask which project to resume.
5. Targeted recall remains isolated. After choosing a slug, the client recalls active_projects:<slug> rather than dumping every project namespace.

What proves a memory write

The chat response is not proof. In strict proof mode, the UI displays a write only after Walrus *AndWait returns a confirmed blob_id. The Console pairs that ID with a SHA-256 hash of the exact text sent for storage. Pending jobs, job IDs, and synthetic 0x... values are not presented as evidence.

Why it uses Walrus Memory well

• Per-project namespaces — active_projects:<slug> gives each project its own isolated slice, so recall stays precise even with a dozen projects on one account. Verified structural (see the isolation scenario in scripts/test_prompt_multiagent.py and scripts/derisk_namespace_test.mjs): a recall scoped to one project never returns another's facts.
• Router pattern — session_handoff names the active project slug + timestamp, so a cold start discovers which project namespace to recall before touching it.
• Bulk writes — a project brief becomes one memwal_remember_bulk call into the project's namespace.
• memwal_analyze — long messages get decomposed into discrete durable facts automatically.
• memwal_restore — a freshly written namespace may not be recallable until its index rebuilds; the start-of-session ritual restores then re-recalls, so identity survives a cold index.
• Portable & verifiable — because memory lives in Walrus (not a platform DB), the same identity works in Claude, Cursor, ChatGPT, or any MCP client. That cross-tool portability is Walrus's killer feature.

The prompt

The full copy-pasteable system prompt is in prompt.md. Paste it into any MCP client wired to Walrus Memory (or the demo app below) and start talking.

Using the prompt

1. Wire up Walrus Memory. Use any MCP client / app that exposes the MemWal tools (memwal_recall, memwal_remember, memwal_remember_bulk, memwal_analyze, memwal_restore) against one Walrus Memory account. Claude Desktop (MCP), Cursor, or the demo app in this repo all work.
2. Paste prompt.md as the system prompt. Nothing else to configure — the prompt defines the whole namespace model and the start/end-of-session rituals.
3. Just talk. Tell it who you are, how you like to work, and what you're building. It captures durable facts on its own and routes each to the right namespace.
4. End the session naturally ("let's continue later", "stuck on X"). It writes a structured handoff.
5. Come back in any tool. On the same Walrus account it recalls first and opens with a continuity line instead of a blank greeting. To resume a specific project, just name it ("back to work on Ferris").

What it does

• Separates identity from work: user_identity (global preferences/standing instructions) · active_projects:<slug> (one namespace per project) · session_handoff (session boundaries + router).
• Captures durable facts proactively and writes each into the one namespace it belongs to.
• Per-project isolation — recall for one project never drags in another (structural, not luck).
• Handoff protocol — a structured record at session end (summary, decisions, open threads, next action, timestamp).
• Continuity on return — recalls the newest session by timestamp and greets with where you left off.
• Portable — the same identity works across Claude, Cursor, ChatGPT, or any MCP client on the same account.

What to expect

• After you reveal something durable, it gets captured and routed to the correct namespace.
• On return it names your most recent (or explicitly requested) project and where you stopped.
• Standing instructions ("always TypeScript", "never MongoDB") are respected without reminding.
• Proof of what actually landed on-chain is the blob IDs and /api/proof, not the chat text.

What NOT to expect (so you don't build empty expectations)

• It is not a Q&A assistant. Its job is continuity, not answering trivia or doing the task — the host model still does the actual work. Continuum makes sure you never re-introduce yourself.
• It does not store your chat transcript. It stores durable facts and handoffs, not verbatim messages — don't expect it to quote an exact past sentence.
• Recall is semantic, not instant or perfect. A fact written seconds ago (especially in another tool) may need an index rebuild (memwal_restore) before it recalls; on a busy/shared account an older similar memory can outrank a newer one. The timestamp router mitigates this for handoffs, but it is not a guarantee of top-1 recency for every fact.
• No forgetting / expiry / confidence decay. Updated facts supersede by writing a new fact; the old one still exists on-chain. This is a memory layer, not a retention-policy engine.
• It is not a secret store. It will not (and must not) store passwords, private keys, tokens, or sensitive financial/medical data.
• Writes are not instantaneous. Real Walrus writes take time and can hit relayer rate limits (429); the demo throttles and retries, but a write is only "stored" once it returns a blob ID.
• Quality depends on the host model. A model with weak tool-calling may not invoke the memory tools correctly — the prompt assumes a competent function-calling model (proven with llama-3.3-70b and similar).

Demo

A working web demo lives in app/ — a chat UI that visualises every memory operation live: what gets recalled at session start, what gets written to which namespace, and the handoff on session end. See demo/script.md for the 3-minute walkthrough used in the submission video.

The demo app runs in simulated memory mode out of the box (no credentials needed) so reviewers can see the behaviour instantly. Add Walrus Memory + LLM credentials as environment variables to run it against real Walrus storage. See app/README.md.

Demo modes. With an LLM key configured (full real mode), the web app runs prompt.md for real: the model is given the memwal_* tools via function-calling and decides every recall / remember / analyze / handoff itself — the same mechanism proven headless by scripts/test_prompt_multiagent.py against Walrus Mainnet (see TEST_RESULTS.md). Without an LLM key (simulated / deterministic modes) a small rule-based engine mimics the routing so reviewers can see the namespace behaviour with zero setup. Relayer rate limits are handled in-request (writes are spaced and 429s retried with backoff; bulk/analyze preferred over many single writes).

Confirmed write flow

Every memory write in real mode uses the *AndWait SDK form, which returns a confirmed Walrus blob ID — not a fire-and-forget job ID. The demo Console tab shows each operation with its blob ID and content hash, so you can verify exactly what landed on-chain:

Console column	Meaning
Blob ID	Real Walrus blob ID (43 characters), returned only after *AndWait confirmation
SHA-256	64-character SHA-256 hash of the exact stored text, so the visible receipt can be matched to its content
Namespace	user_identity, active_projects:<slug>, or session_handoff
Op	remember, remember_bulk, analyze, recall, handoff

The proof UI never renders a pending or synthetic 0x... ID as storage evidence. If a write fails (relayer timeout, rate limit), the Console shows the error honestly — no fabricated blob IDs.

Secret filtering

The demo filters sensitive credentials from memory writes:

• Messages containing token, API key, secret, private key, password, seed phrase are not passed to analyze() as raw text.
• Standing instructions mentioning these words (e.g. "don't store my token") are discarded — the meta-fact about the token is itself a leak vector.
• Only safe project facts and identity preferences are written to Walrus.

Scoped recall and handoff

• Targeted recall: when resuming a project, the Console shows the exact namespace being recalled (e.g. active_projects:atlasproof2026qa), not a generic "all".
• Handoff filtering: recalled handoffs are filtered to only those matching the active project slug, preventing cross-project contamination.
• Fresh-session resume: natural phrases like "I'm back" trigger recall of the latest handoff and project context.

Multi-agent scenario

The Roundtable mode includes an auto-demo scenario where four agents (Claude, Cursor, ChatGPT, Continuum) collaborate on the same project through shared Walrus Memory:

1. Claude writes project state to active_projects:<slug>
2. Cursor performs targeted recall from the same namespace
3. ChatGPT validates the next action based on recalled context
4. Continuum writes a session handoff
5. A fresh "I'm back" message triggers scoped recall of the handoff

Repo layout

Continuum/
├── prompt.md          # the submission — copy-pasteable system prompt
├── PROBLEM.md         # problem statement (pain, who, how often)
├── demo/script.md     # 3-minute demo walkthrough
├── app/               # web demo that visualises the memory operations
└── screenshots/       # UI captures used in this README

Proof of writes (Walrus Mainnet)

Continuum's prompt was deployed via the demo app against real Walrus Memory on Mainnet (relayer relayer.memory.walrus.xyz) and has written 38+ blobs across its namespaces (live snapshot below, from /api/proof on 2026-07-10 — the count only grows as the live demo and the test harness are used; /api/proof is the source of truth):

Namespace	Blobs on-chain
user_identity	4
active_projects:ferris (per-project)	18
session_handoff	16
Total	38

• Dedicated wallet address (Sui, owns the submission): 0x6e767c35b5834bce70c13176afdb7cc34d6a6a7334adee092a0e06a3e4db504e
• Agent ID (MemWalAccount object ID on Sui): 0x265869e118b19010b9af78bf4c91ea0e050560101dad55e79be11949af0046e5
• Live demo: https://continuum-flame-three.vercel.app
• Verify live: /api/proof returns the account ID and current on-chain blob count per namespace (via restore().total). It discovers per-project namespaces through the session_handoff router, so new active_projects:<slug> blobs are counted automatically.

All project writes now go to per-project namespaces (active_projects:<slug>, e.g. active_projects:atlasproof2026qa). The legacy flat active_projects bucket is empty on the current account — per-project scoping is fully in effect.

Direct Walruscan blob verification

Fresh blobs from the latest demo session can be verified directly on Walruscan (Mainnet):

• Project write — active_projects:atlasproof2026qa: Walruscan detail
• Session handoff — session_handoff: Walruscan detail

These are direct blob detail pages, not the explorer landing page — each shows the on-chain confirmation, size, and metadata for the specific blob written during the demo.

Submission checklist (Walrus Memory Prompt Jam)

• Copy-pasteable prompt, ready for any MCP client → prompt.md
• Short problem statement → PROBLEM.md
• Proof of writes — Agent ID + 38 blobs on Walrus Mainnet (see above)
• Agent ID (MemWalAccount object ID on Sui): 0x265869e118b19010b9af78bf4c91ea0e050560101dad55e79be11949af0046e5
• Prompt verified by tests — cross-session continuity + per-project isolation, both PASS (scripts/test_prompt_multiagent.py)
• Dedicated wallet address for the submission: 0x6e767c35b5834bce70c13176afdb7cc34d6a6a7334adee092a0e06a3e4db504e
• Demo video under 3 min, uploaded to Walrus
• Post on X with #Walrus (submission requirement) : post with video

---

Built on Walrus Memory — portable, verifiable agent memory on Sui.