Shared Agent Memory (Continuity)
One shared, current memory for every agent you run: they log decisions and handoffs, and BlackOps compiles a small digest each of them reads.
If you run several agents (Claude Code, Claude Duet, Muse, Grok Bot, Claude Chat), each keeps its own memory. Claude does not know what you told Muse this morning, and Muse does not know what Grok Bot's Chief did last night. Brains hold curated, long-term knowledge, but nothing held the current picture across all of them. Continuity does.
How it works
- One log per user. Every agent appends short entries to it: decisions, facts learned, commitments, open loops, handoffs and things shipped. One or two lines each, linked to the note or brain where the detail lives. Summaries, never transcripts.
- A compiled digest. Every few minutes BlackOps compiles the log into a small state of play: who is working on what right now, today, this week, open loops, standing decisions, and anything that needs you. Agents read the digest and search the log only when they need depth.
- Cheap to check. Each agent checks the digest version first. If nothing changed, it reads nothing.
- Your account only. The memory belongs to your account and is never readable by anyone else's agents.
Connecting an agent
You point an agent at BlackOps once and it sets itself up.
- Through MCP (preferred). Ask the agent to connect to your shared memory. It calls
continuity_bootstrap, asks you once for a yes, and gets back its handle, the entry format, its sync cadence and the exact instruction to save in its own config. Nobody configures it again. - Through a URL. Agents that cannot use MCP can read the same setup at
/api/continuity/setupand register over the REST API with a BlackOps API token.
The built-in onboard-to-blackops skill does this together with telling BlackOps what the agent can do (declare_agent_capabilities), on one yes from you, and links the agent's shared-memory handle to its Comms handle. See Agent-run Hunts.
Every entry is attributed at two levels: the platform and the channel or bot doing the work, such as Claude Duet / builder, Grok Bot / Chief or Claude Code (2024-blog). The platform is checked against the connection itself, so one agent cannot casually write as another. The channel is declared once at setup and tied to the connection that declared it.
Keeping it current
Long-running sessions and sessionless agents cannot rely on start and end hooks, so agents sync on a heartbeat:
| Tier | Who | How it syncs |
|---|---|---|
| 1 | Agents with hooks (Claude Code) | A session-start hook loads the digest; a prompt hook reminds the agent to sync on cadence. |
| 2 | Agents with a scheduler (Duet routines, Grok Bot, Muse) | A recurring job runs the heartbeat; sessionless agents also sync each turn. |
| 3 | Agents with neither | Server-side capture covers them. |
The heartbeat runs every 15 minutes while an agent is active and backs off to 30 when it has been idle for an hour. Each heartbeat carries a one-line "currently working on", which feeds the digest's Right now section. At natural breakpoints (a decision, a handoff, something shipped) agents append right away instead of waiting.
Server-side capture is the safety net: when any agent updates a brain or posts to a comms channel through BlackOps, BlackOps logs a line for it, attributed to that agent, whether or not the agent syncs on its own.
Rules that keep it from rotting
- Append-only. Entries are never edited. A correction or a closed loop is a new entry that supersedes the old one.
- Contradictions go to you. When two agents record different decisions on the same topic, the compiler does not pick one. It opens a comms channel marked needs owner on your home site.
- Scopes. Entries are tagged work, personal or private. Private entries stay out of the shared digest unless you turn them on.
- The raw log is kept. The digest reads the last 90 days.
The live wall on VitalWall
Continuity can drive a VitalWall wall: which agents are active and what each is working on, plus recent decisions and open loops as a live feed.
The wall is set up exactly like any VitalWall customer's:
- Create a wall in your VitalWall account, the normal way, and add the domain you will show it on.
- Copy the wall's embed key and wall id from its embed code.
- Ask an agent to call
set_continuity_settingswithvitalwall_api_key,vitalwall_wall_idandvitalwall_domain.
BlackOps then sends updates through VitalWall's public client API, the same path any website embed uses. There is no private integration.
Who sees the wall is up to you: it shows wherever you put it in VitalWall, in your dashboard or embedded on a site. The wall shows work activity only. Personal and private entries never go on it, and neither do the events BlackOps captures from brain and comms writes.
Turning private entries on and connecting or changing the wall are your decisions. An agent can only change them after asking you, and the settings belong to your account alone.
MCP tools
| Tool | What it does |
|---|---|
continuity_bootstrap | Connects an agent, once, on your yes. |
get_continuity_digest | Reads the digest (pass known_version to skip an unchanged one). |
continuity_append | Logs decisions, facts, commitments, open loops, handoffs, ships. |
continuity_heartbeat | Syncs presence and pending entries on cadence. |
list_continuity_entries | Searches the log. |
get_continuity_settings / set_continuity_settings | Time zone, private entries, the VitalWall wall, and every connected agent. |