Memory in Clawboo: Shared and Private Tiers Explained

Clawboo gives your team two kinds of memory. There is one shared store — a searchable database of facts and procedures that every runtime on a team can read and write. And there is each runtime’s own private native memory — a Hermes agent’s MEMORY.md, a Claude Code agent’s project memory, a native agent’s session store — which Clawboo preserves across runs but never reads or modifies. A fact saved by one agent is available to every teammate, regardless of which runtime they run on. Private memory is each runtime’s own cognitive scratch space; teammates cannot see it. The model decides what to promote from private to shared by explicitly calling memory_save.

​

The shared memory tier

The shared store holds two kinds of entries:

• Facts — declarative knowledge: “the staging deploy command is pnpm deploy:staging”, “the user prefers concise responses”, “the API rate limit is 100 req/min.”
• Procedures — versioned how-to instructions kept separately from facts so they stay findable.

Every runtime reaches the shared store through the Memory MCP server, which exposes three tools: You can also browse and manage the shared store from the Memory Browser in the dashboard — useful for auditing what your team has learned, deleting stale facts, or seeding knowledge before a team starts a new project.

​

Memory scopes and namespaces

Every fact carries an optional team scope and agent scope. The visibility rules are inclusive: a query scoped to team T and agent A returns facts tagged with team T, facts tagged with agent A, and global (untagged) facts — but never another team’s facts or another agent’s private facts. When an agent auto-saves a team fact during a run, it is tagged with the team only (no agent tag) — so every teammate on every runtime can recall it. Tagging an auto-save with a specific agent ID would hide it from teammates and defeat the purpose of a shared store.

​

Auto-injection at run start

You do not need to call memory_search at the start of every run to load relevant context. When a task run begins, Clawboo automatically searches the shared store using the task’s title and description as a query, retrieves the top matching facts (up to 5 by default, within a ~1500-character budget), and injects them into the prompt as a bounded <auto-memory> block. This means your agents start each task already aware of what the team has learned — deploy commands, user preferences, project conventions — without an explicit tool call.

​

Search: full-text and semantic

The shared store supports three search modes: Embedding support is pluggable: Clawboo prefers a local Ollama instance, falls back to OpenAI when a key is present, and otherwise uses full-text search. A fresh install with no embedding provider still gets working memory recall through full-text search.

​

The private memory tier

Each runtime’s native memory is preserved by Clawboo but never modified: The private tier is part of what makes each runtime valuable. A Hermes agent that has built a rich MEMORY.md over many runs carries that knowledge forward. Clawboo’s job is to preserve that state, not flatten it.

​

Security: scrub-on-write and sanitize-before-inject

The shared store is a single write choke point, which makes it the right place to remove secrets before they become durable. Every save — whether through the MCP tool, the REST API, or a future writer — passes through a secret redactor before storage. A credential that an agent tries to memorialize is stored as [REDACTED], never as the live value. Before a fact reaches an agent’s prompt through auto-injection, two additional guards run:

1. Injection scan — a fact containing potential prompt-injection content is dropped before it reaches another agent’s context.
2. Re-scrub — facts are scrubbed again on the read path as a defense-in-depth measure, in case a fact predates the scrubber or was written by an older code path.

Using the Memory Browser in the dashboard

Open the Memory Browser from the dashboard sidebar to see all facts and procedures stored for your team. You can:

• Filter by team, agent, or global scope
• Search using the same full-text or semantic search your agents use
• Delete stale or incorrect facts
• Seed facts manually before starting a new project

Changes in the Memory Browser take effect immediately — your agents will see updated facts on their next run.