A field guide to every column, status, panel, and action on the dashboard's Broker Fleet screen — installs, statuses, fleet policy, commands, the reported-agents panel, and revoke.

The Broker Fleet screen is where you manage the brokers joined to your fleets: onboard machines, read their live status, push policy, act on a specific install, and inspect the agents each one reports. This page explains every part of it.

The installs table

Each row is one install — a broker on one machine, identified by an install UUID. The columns:

Tenant / Fleet — which tenant owns it and which fleet (if any) it joined.
Status — a live health/liveness readout (below).
Last seen — the timestamp of the most recent heartbeat (fleet-mode installs only).

Use the status filter and fleet filter to narrow large fleets; the counts at the top (Online, Offline) summarize the current page.

What each Status means

Status is computed per row from the install's mode, revocation state, and heartbeat age:

Status	Meaning
Online (green)	Fleet-mode; last heartbeat within 3 minutes.
Stale (yellow)	Fleet-mode; last heartbeat 3–15 minutes ago.
Offline (grey)	Fleet-mode; last heartbeat older than 15 minutes (or none yet — "pending").
Active (green)	Personal-mode install — registered and not revoked. Personal brokers don't heartbeat (liveness is fleet-only), so there's no online/offline to show.
Revoked (red)	The install's credential has been revoked; it can no longer talk to the cloud.

The decision order is: Revoked wins; else if in a fleet, the heartbeat-age bucket (Online / Stale / Offline); else Active.

Active ≠ actively working

Active is a registration state for a personal-mode install, not a health signal. It only means "registered, not revoked." Liveness (Online/Stale/Offline) exists only for fleet-mode brokers, which heartbeat.

Onboard a broker

The onboarding control mints a join key (single-use by default, or reusable) and shows a Copy install command you paste on the target machine. That whole flow — including macOS/Linux/Windows specifics — is covered in Onboarding a Broker.

Push fleet policy

Publishes the next policy version to a fleet. The server stamps the version and effective time; connected brokers receive it live over their policy stream (an offline broker picks it up on reconnect), with no restart. The document is JSON — you own the rules array and categorical_settings; the server owns the envelope. For example:

{
  "rules": [
    { "rule_id": "deny-secrets-writes",
      "predicate": { "field": "tool", "op": "eq", "value": "write" },
      "action": "deny", "severity": "high", "reason": "no secret writes" }
  ],
  "categorical_settings": { "auto_wire_agents": true }
}

categorical_settings.auto_wire_agents: true opts the fleet into zero-touch onboarding of newly detected-but-unconnected agents — each broker wires them on its own on the next policy apply, without a per-machine command.

Issue command

Queues a cloud command for one install and delivers it live over the policy stream (an offline broker replays it on reconnect; every command is acknowledged). The dialog has a Command type dropdown and an optional JSON payload:

Command type	What it does
`agents.rescan`	Re-detect the machine's agents, record and issue identities for wired ones. With payload `{"wire": true}` it also wires any detected-but-unconnected agent (writes its config, with backups) — the way to onboard an agent installed after the broker.
`restart` / `rotate_credential` / `flush_queue`	Reserved command types. Current brokers acknowledge these as `unsupported` (they're defined in the protocol but not yet implemented broker-side), rather than failing silently.

No results panel — check the broker

The dialog queues the command; the dashboard does not currently render the acknowledgement or outcome. To confirm what happened, look on the machine: memclaw logs shows the command received / executed / acked, and the broker's audit log records each execution. A dashboard command-history view is a planned follow-up.

The Reported agents panel

For a selected install, this panel lists the agents the broker reported on its last heartbeat — a snapshot as of last seen, not a live view. Per agent:

Agent — the agent type (claudecode, codex, cursor, gemini) and its identity UUID.
Tier — the wiring tier: full (hooks) or strong (MCP).
State — Active (identity issued, not revoked) or Tombstoned (revoked/uninstalled).
Wiring — the integration verdict for an active agent as of that heartbeat: Wired (detected with a clean config plan), Not wired (detected but drifted, or its broker config was stripped), or — (unknown — tombstoned, or the broker couldn't resolve the product).
First seen / Last reported — when the identity first appeared and the timestamp of the heartbeat that carried it.

Active is identity; Wiring is health

State: Active means the agent's identity is issued and not revoked — on its own it does not guarantee the agent is currently wired and able to route memory. The Wiring column is that health signal: if someone removes an agent's broker config it stays Active but flips to Not wired. Both are a snapshot as of the last heartbeat, not a live view — for the real-time verdict, memclaw status on the machine remains the source of truth for whether an agent is actually integrated.

Revoke install

Revokes the install's credential: the cloud hard-rejects its subsequent calls (403), and a targeted install.revoked event tells a connected broker to fail closed. Use it when a machine is decommissioned or a credential may be compromised. It also cancels the install's pending commands. The row then shows Revoked.

The Broker Fleet Screen