Coordination status

Coordination status answers one operator question: which coordination surfaces are active or degraded right now, and where should I inspect next? It composes the multi-agent coordination family into one read-only packet: subagent spawning, mesh, teams, arena, choreography, adaptive orchestration, fleet runtime observability, task execution, stigmergic delivery, and signal fabric.

The status is intentionally not a controller. It does not heal a subsystem, reroute work, or block ordinary chat. It is a routing readout: when the sidebar or /coordination says a row is degraded, continue normal single-agent work if needed, then open the row-specific inspector named in the report.

Coordination status routes a degraded row

Live BMO TUI on Claude Fable 5 (Bedrock): after a provider-backed coordination inspection turn, `/coordination` names the degraded Fleet runtime row and points the operator at `/fleet-metabolism` or `bmo config show-fleet-metabolism` while ordinary chat can continue.

When to use it

Use /coordination when you need a compact health read across coordination surfaces before splitting work, opening a team, debugging parallel execution, or explaining why a sidebar says a coordination surface is degraded.

Good moments to check it:

• before assigning multi-agent or team work from a long-running session;
• when a sidebar chip reports a named degraded coordination surface;
• after provider or task-execution issues, before assuming every coordination path is unhealthy;
• when an integration needs the same bounded packet through CLI, HTTP, agent, or MCP.

How to read it

Every row has one of four states.

State	Meaning	Operator response
active	Work is in flight right now on that surface.	Inspect the row only if the active work is surprising.
default	The surface is readable and idle — including enabled but doing nothing.	No action. Enablement is shown in the row detail, not the state.
degraded	The surface has a bounded fault signal.	Open the row-specific inspector shown in the next action.
unavailable	The live runtime is not observable from this surface.	Recheck from an attached runtime or the named CLI/HTTP surface.

Degraded and active are mutually exclusive. A degraded row is not counted as an active row, even when work is in flight on it.

active reports observed work, not configuration. A configured, healthy, fully-wired subsystem with nothing running reads default — so a low active count on a busy-looking config is the expected reading, not a bug. Whether a feature is switched on is answered by its row detail (enabled=true) and by bmo config show-<feature>.

When a row cannot see its own liveness

Not every coordination feature exposes a point-in-time “work in flight” gauge. Some only expose a process-lifetime event ring, which never returns to idle once anything has happened, so it cannot answer whether work is happening now.

Those rows read default and additionally:

• carry liveness=unobservable in their row detail,
• set liveness_unobservable on the row,
• are counted in liveness_unobservable_count,
• are named in a packet warning,
• and are disclosed by the sidebar as idle (N unobserved).

Three related cases are reported the same way, because all are absence of evidence rather than evidence of absence:

• A row whose activity marker lives in persisted state — arena’s running candidates and choreography’s advanced sessions are stored on disk, so a killed run leaves a marker that never clears. Those figures are reported as persisted_running_* / bound_sessions metadata, never as active.
• A row that is on but unasked. Adaptive orchestration answers per session, and this packet is process-global, so it reports scope=session_only. It is not switched off; nobody asked it. Use the per-session surface for a real answer. Its pending_apply / failed_apply figures are a stuck-apply signal, not an activity signal — see below.
• A detached projection (bmo config show-coordination with no runtime attached), which observed nothing at all. It reports idle (detached).

Each row also reports feature_enabled separately from its state, because the state alone cannot distinguish “idle because it is off” from “idle while switched on” — both are default. Read enablement from that field, never from the detail prose.

This distinction is deliberate: active_count: 0 with no unobserved rows and an attached runtime means nothing is running, while active_count: 0 alongside unobserved rows means nothing observable is running, and some rows cannot tell you. Never read the second as proof of the first.

A stuck adaptation is a fault, not activity

The adaptive orchestration row reports two extra figures when a live runtime answers: pending_apply and failed_apply.

A monitor reshape is applied at the next root run, so pending_apply is normally non-zero for the gap between a recommendation and the operator’s next turn. That is an ordinary boundary and reads default. When an apply fails to persist, it stays pending across turns — failed_apply becomes non-zero and the row reads degraded, because an adaptation that can never land is a bounded fault.

pending_apply is deliberately not an activity signal, and a zero must not be read as “no adaptation is happening.” It only responds to reshapes that change the choreography preset or model; reshapes touching topology, isolation, coordinator style, conflict strategy, or edit-tool preference never set it. That is why the row still declares its liveness unobservable even while reporting these figures. tracked_sessions is an absolute count, never a denominator.

Counters that look like conditions

Several coordination features expose cumulative lifetime counters — arena’s orphan finalizes, the task bus’s rejected registrations, the mesh and stigmergy event rings. These only ever rise within a process, so a status surface keyed on counter > 0 reports its condition forever after a single event.

Coordination rows therefore never treat a lifetime counter as a current condition. Where a current answer is needed, the feature exposes a windowed gauge that returns to zero once the pressure passes (the task bus’s saturation issue works this way), and the lifetime figure is retained as telemetry only.

Degraded does not mean stop

The compact sidebar no longer says only degraded; it names the affected surface, such as Fleet metabolism degraded or 2 degraded: Fleet metabolism +1. In the full /coordination report, the operator summary says what is degraded and gives the inspector route.

Expected behavior:

1. Keep using ordinary chat or single-agent work when the degraded row is not needed for the current task.
2. Open the named inspector before relying on that coordination surface.
3. Use the row’s CLI fallback when the TUI process is not the runtime you need to inspect.

For example, Fleet metabolism degraded points at /fleet-metabolism or bmo config show-fleet-metabolism. It does not mean teams, mesh, task bus, or ordinary chat are necessarily broken.

Row routes

Coordination row	TUI inspector	CLI fallback
Agent spawning	/spawn-status	bmo config show-spawning
Agent mesh	/mesh	bmo config show-mesh
Teams	/teams	bmo config show-teams
Arena	/arena	bmo arena status
Choreography	/choreography	bmo config show-choreography
Adaptive orchestration	/adaptive-orch	bmo config show-adaptive-orchestration
Fleet runtime observability	/fleet-metabolism	bmo config show-fleet-metabolism
Task bus	/task-bus	bmo config show-task-execution
Stigmergic delivery	/stigmergy-status	bmo config show-stigmergy-delivery
Signal fabric	/signal-fabric	bmo config show-signal-fabric

Surfaces

The same coordination packet is available through:

Surface	Entry
TUI	/coordination
CLI	bmo config show-coordination
Native agent tool	get_coordination_status
MCP	bmo_get_coordination_status
HTTP	GET /v1/coordination

The packet is metadata-only. Row details carry bounded enum states, counts, and posture flags; they do not expose prompts, raw provider payloads, team member messages, worktree paths, signal bodies, or validation output.

Related pages

• Agents: kinds & coordination explains how coordination surfaces differ from agent roles.
• Multi-Agent Workflows shows the common fan-out, team, and workspace-claim paths.
• Fleet runtime observability is the row-specific inspector for fleet-regulation loop health.
• Stigmergic delivery covers indirect workspace-signal coordination.