Broker Fleet
What the Caura broker is, how personal and fleet mode differ, and how a fleet of brokers is governed from the dashboard.
The Caura Broker (CLI memclaw, process memclawd) is a small
local daemon that runs on a developer's machine and connects their
coding agents — Claude Code, Codex, Cursor, Gemini — to Caura. It is
the enforcement point: memory reads and writes pass through it, so
policy, redaction, and a tamper-evident audit log apply before
anything leaves the machine.
A Broker Fleet is a set of Broker installs joined to one fleet and
governed together from the dashboard's Broker Fleet screen — one
place to onboard machines, push a policy to all of them, see which are
online, and act on a specific install. Two kinds of "fleet" compose
here, so this documentation always qualifies the word: a Broker
Fleet is machines and their daemons (this section); a
memory fleet is the shared
fleet_id memory scope — many agents drawing on one governed brain. A
Broker joins a memory fleet so its agents share common ground, and the
Broker Fleet screen is how you manage the Brokers that do it.
Personal mode vs fleet mode
A broker runs in one of two modes, and the mode decides what the dashboard can see and do:
| Personal mode | Fleet mode | |
|---|---|---|
| Joined to a fleet | No | Yes |
| Heartbeats to the cloud | No (privacy: liveness is fleet-only) | Yes, every 60s |
| Governed by fleet policy | No (local policy only) | Yes (fleet policy merges over local) |
| Shows in Broker Fleet screen | As Active (registered, no liveness) | As Online / Stale / Offline by heartbeat age |
| Receives cloud commands | No | Yes (over the policy stream) |
Onboarding a machine with a join URL (below) puts it in fleet mode. A broker registered without a fleet stays personal — fully functional locally, just not centrally managed.
What onboarding actually does
When you run the one-command installer from the dashboard, the broker:
- Registers with the cloud using the bootstrap key baked into the join URL (single-use by default, or reusable if minted that way), receiving its install credential (bound to your tenant).
- Joins the fleet the key was minted for.
- Wires the detected agents — writes the hook / MCP config each
agent needs to route through the broker, backing up anything it
replaces so
memclaw uninstallcan revert cleanly. - Starts the daemon and writes a boot service so it comes back on login.
- Heartbeats — the first beat carries the machine's agent inventory, which is what fills the Reported agents panel.
The Broker↔cloud API (installs/register, claim, heartbeat,
policy/stream, plus audit-log) is a frozen v1 wire contract,
enforced by breaking-change gates in CI — see
the wire contract
for what that promise means when you deploy Brokers you don't upgrade
often.
The next pages walk through onboarding a new Broker step by step, then how onboarding works — the credential model, fleets, and security — and finally every detail on the Broker Fleet screen.
Cross-tenant credentials
Read across every tenant in your org with a single credential — for admin agents, analytics, and rollups.
Onboarding a Broker
Install and join a new broker to your fleet with one command — what to run on macOS, Linux, and Windows, what each step does, and how to verify it worked.