Adaptive orchestration parity

Adaptive orchestration has one control-plane authority: the coordinator’s session snapshot. HTTP and MCP surfaces serialize that snapshot; they do not re-run classifier or monitor merge logic.

Canonical fields

All parity surfaces use this vocabulary:

• session_id
• action
• posture
• classification_source
• effective_genome
• last_reshape_reason
• last_reshape_signal_id
• hint_sources (optional; comma-separated coarse hint plane tags when monitor v2 consumed arena/eval-shadow aggregates)
• runtime_apply_status
• runtime_apply_error

action is updated when a snapshot is present and cleared when adaptive state was removed or is no longer available for the session. Monitor-only payloads use monitor_evaluation; no-evidence payloads use unknown.

posture.state is the operator contract shared by CLI, TUI, HTTP, MCP, and native agent readouts:

• disabled
• unavailable
• enabled-idle
• active
• pending-apply
• applied
• degraded
• unknown

The posture object contains metadata-only booleans for implemented, configured, available, active, pending/apply, applied, degraded, bounded reason text, decision-trace availability, and efficacy verdict when present. It does not carry raw prompts, tool bodies, model responses, or full regulatory digests.

runtime_apply_status matches prompt trace semantics:

• applied
• pending

runtime_apply_error is present only when the last apply attempt recorded an error.

HTTP SSE events

Session SSE (GET /v1/sessions/{id}/events) carries adaptive parity events and, when configured, a separate health follow-on telemetry event on the same stream (see below). The same stream also carries provider_recovery.changed when TPM recovery crosses a provider boundary so external session clients can surface the active hop without parsing status prose.

Method	Path	Purpose
GET	/v1/sessions/{id}/events	Stream session events, including adaptive orchestration parity and optional health follow-on telemetry

Optional query include_snapshot: pass 1, true, yes, or on so the server emits one initial adaptive-orchestration resync event from the current coordinator parity snapshot immediately after the connected event (before replaying buffered events). Useful on reconnect alongside Last-Event-ID so clients refresh genome state without waiting for a new live event.

Adaptive events:

• adaptive_orchestration.changed Compatibility event. Payload stays refresh-only: {"type":"adaptive_orchestration.changed","session_id":"...","action":"updated"}
• adaptive_orchestration.genome Full machine-readable snapshot for the current effective genome.
• adaptive_orchestration.monitor_evaluation Emitted when the monitor records an evaluation but there is no current effective genome snapshot for the session.
• adaptive_orchestration.reshape Emitted only when the change is reshape-related. Adds reshape_action with one of: recorded, queued, applied, blocked, cleared

Example adaptive_orchestration.genome payload:

{
  "type": "adaptive_orchestration.genome",
  "session_id": "sess-123",
  "action": "updated",
  "posture": {
    "state": "pending-apply",
    "reason": "boundary",
    "implemented": true,
    "configured": true,
    "available": true,
    "active": true,
    "pending_apply": true,
    "decision_trace_available": true
  },
  "classification_source": "heuristic",
  "effective_genome": {
    "schema_version": 1,
    "choreography_preset": "modal",
    "topology": "fan_out"
  },
  "last_reshape_reason": "merge_conflict",
  "last_reshape_signal_id": "sig-1",
  "hint_sources": "arena:monitor,eval_shadow:monitor",
  "runtime_apply_status": "pending",
  "runtime_apply_pending_since": "2026-03-31T03:04:05Z",
  "runtime_apply_pending_reason": "boundary",
  "last_monitor_evaluation": {
    "cadence": "finalize",
    "decision": "recorded",
    "reason": "merge_conflict",
    "signal_id": "sig-1"
  }
}

Example adaptive_orchestration.monitor_evaluation payload:

{
  "type": "adaptive_orchestration.monitor_evaluation",
  "session_id": "sess-123",
  "action": "monitor_evaluation",
  "posture": {
    "state": "active",
    "implemented": true,
    "configured": true,
    "available": true,
    "active": true
  },
  "last_monitor_evaluation": {
    "cadence": "finalize",
    "decision": "skipped",
    "skip_reason": "cooldown_active",
    "reason": "monitor_token_pressure",
    "signal_id": "sig-9"
  }
}

When options.adaptive_orchestration.monitor.regulatory_history_max_events is greater than zero, parity JSON (native get_adaptive_orchestration, MCP bmo_get_adaptive_orchestration, and HTTP session event payloads that embed the same structure) may include an optional regulatory_history array: newest-first bounded episodes with event_kind (eval_skipped, eval_recorded, reshape_applied), at, evaluation (same shape as last_monitor_evaluation), and optional previous_genome_fingerprint / next_genome_fingerprint. Transport caps at 32 events per response even if the in-memory ring is larger. 0 disables the feature and omits the field.

Example adaptive_orchestration.reshape payload:

{
  "type": "adaptive_orchestration.reshape",
  "session_id": "sess-123",
  "action": "updated",
  "reshape_action": "queued",
  "classification_source": "heuristic",
  "effective_genome": {
    "schema_version": 1,
    "choreography_preset": "plan-execute"
  },
  "last_reshape_reason": "user_cancel_retry",
  "last_reshape_signal_id": "cancel-7",
  "runtime_apply_status": "pending"
}

health_followon.activation (optional)

Not part of the adaptive genome snapshot. Emitted when options.health_followons.enabled is true (default on when omitted), emit_declarative_events is true, health.token_pressure activations run, and options.health_followons.activation_caps.emit_activation_telemetry_sse is true, with bmo serve wiring HealthFollowonSessionPublisher into the session event log. There is no MCP mirror; use session SSE or structured logs.

Payload fields:

• type — always health_followon.activation
• session_id
• signal — e.g. token_pressure
• activation_rule_id
• outcome — dispatched (actions ran) or skipped (e.g. cap)
• actions_planned, activation_actions_run
• reason — optional (e.g. which cap blocked a run)

Example (cap skip):

{
  "type": "health_followon.activation",
  "session_id": "sess-123",
  "signal": "token_pressure",
  "activation_rule_id": "scale-out",
  "outcome": "skipped",
  "reason": "process_hour_cap",
  "actions_planned": 1,
  "activation_actions_run": 0
}

Ordering

The contract order is:

1. coordinator state mutates
2. prompt trace assembles from that committed state
3. snapshot-backed parity payload is published
4. session event replay exposes the same payloads

HTTP consumers should treat adaptive_orchestration.changed as a refresh signal only. Use adaptive_orchestration.genome and adaptive_orchestration.reshape for adaptive payload reads. health_followon.activation is monitor-adjacent activation telemetry and does not replace or extend the genome contract.

Replay and reconnect

HTTP parity events use the existing session SSE retention buffer:

• reconnect with Last-Event-ID on GET /v1/sessions/{id}/events
• use retained replay when the requested IDs are still buffered
• if replay is too old, the server emits the standard resync path from the session event log

For non-streaming inspection, use the existing parity helper:

• list_session_events tool

That tool returns the same retained buffer entries that back HTTP SSE replay. This parity surface uses the same retained-buffer and resync behavior as the main session event stream; it does not introduce a second replay model.

In-process Fantasy tool

When options.adaptive_orchestration.enabled is true, the native agent registry includes get_adaptive_orchestration. It returns the same JSON object as MCP bmo_get_adaptive_orchestration (and the same fields as HTTP genome payloads): call AdaptiveOrchestrationParityPayloadForSnapshot / monitor-evaluation fallback in internal/agent/adaptive_orchestration_parity.go. Optional session_id; defaults to the current session context (same pattern as get_operating_mode).

CLI posture

For headless operator inspection without a running session, use bmo config show-adaptive-orchestration. The command is read-only and reports effective config posture, classifier mode, monitor summary, and canonical readout surfaces. It never runs classifiers, starts monitor workers, calls providers, hydrates sessions, or prints prompt/model/tool bodies.

MCP parity

MCP parity is currently pull-only. The discoverable tool is:

• bmo_get_adaptive_orchestration

It returns the same snapshot-backed parity payload as adaptive_orchestration.genome and the in-process get_adaptive_orchestration tool.

Capability boundary:

• available when the MCP runtime has a coordinator-backed app
• exposed by the daemon MCP server
• exposed by bmo serve-mcp only when the tool is selected in options.mcp_server.exposed_tools
• no MCP push notification exists yet; native prompt trace remains the minimum parity surface when a richer MCP transport is unavailable

The tool accepts optional session_id; when omitted, it uses the current MCP-bound BMO session.

Related surfaces

• Prompt trace adaptive_orchestration segment remains the native minimum parity surface.
• TUI status and debugger read the same coordinator snapshot.
• list_session_events is the agent-readable replay path for HTTP parity (including retained health_followon.activation when emitted).
• Operator semantics for health follow-ons: health-spawn-monitor-boundaries.md.
• Adaptive orchestration — user-facing overview of the genome layer and runtime apply semantics
• How BMO thinks and acts — broader system mental model