Skip to content

Stigmergic delivery

In plain terms: instead of agents talking to each other over a shared chat channel, they leave small signals in the workspace as they finish work — like notes that pile up where attention is needed. You read where the work is accumulating and what to look at next. “Stigmergic” is just the name for this coordinate-by-environment pattern (it is how ants coordinate via trails).

Stigmergic delivery answers one operator question: what is accumulating in the workspace, where is pressure building, and what should I inspect next — without opening a shared chat channel? Agents and workflows leave bounded signals after work completes; operators and tools read zone pressure, manifests, triage queues, and causal explain packets through the same getters whether you ask from the CLI, TUI, agent tools, or MCP. HTTP exports the status read model only; explain and triage use the other surfaces.

It is BMO’s indirect coordination loop — substrate-time accumulated decisions rather than synchronous request/response between actors. Three nouns recur throughout this page:

  • Feature — Stigmergic delivery (the operator-facing capability)
  • Read model — shared status, zone pressure, explain, and triage packets
  • Envelope — the rendered posture (RenderStigmergyDeliveryStatus) and parity JSON across surfaces modulo captured_at

In the public docs taxonomy, Stigmergic Delivery is a core concept rather than just another feature. It is the grounding page for signal-shaped coordination; see Concept Map for the surrounding families.

Availability: At least one of options.workspace_markers.enabled or options.signal_fabric.enabled must be on. bmo config show-stigmergy-delivery renders a clear disabled posture when both are off. Recommendation and triage packets are read-only; accept, dismiss, prune, reinforce, and kill remain separate explicit commands.

Hand-drawn sketch: DEPOSIT through COMPOUND loop with operators reading the same getters

  • You need a single read-only posture for workspace markers and signal fabric without tailing logs.
  • Zone pressure is climbing and you want the ranked triage queue before accepting manifests or spawning follow-on work.
  • You need a causal drill-down for one zone — recommendation packet, capability-fit guidance, cited evidence, and explicit next command.
  • You want the same JSON from TUI, CLI, HTTP, native agent tools, or MCP for operator scripts or in-process agents.
  • You are pairing stigmergy.firedstigmergy.action events in logs and want the status ring to corroborate.

Use Workspace trail when the question is aggregate trail and marker inventory, not delivery-loop pressure and recommendations. Use Fleet runtime observability when the question is fleet-regulation loop health, not workspace stigmergy.

Stigmergic delivery is organized as a feedback loop. Each stage has a distinct runtime role; together they let multi-agent work compound across sessions and restarts without a central chat bus.

StageOne-line roleOperator surfaces
DEPOSITLeave markers and typed signals after work completesWorkflow bridges, nanite completion, leave_marker, leave_signal
GRADIENTRead markers to influence routing and rank hot zones/signal-zones, bmo signal zones, zone pressure in workspace_snapshot
REACTSpawn or recommend inspection when conditions are met/stigmergy_triage, bmo stigmergy triage, automation rules
AMPLIFYReinforce success; decay failure over timeMesh niche scores, adaptive-context pheromone
COMPOUNDCombine outputs from multiple agentsConvergence executors, fabric-native induction manifests
flowchart LR
    deposit[DEPOSIT markers and signals]
    gradient[GRADIENT zone pressure]
    react[REACT triage and rules]
    amplify[AMPLIFY niche and pheromone]
    compound[COMPOUND convergence]
    deposit --> gradient --> react --> amplify --> compound
    compound --> deposit
GatePurpose
options.workspace_markers.enabledDEPOSIT paths (markers, workflow bridges)
options.signal_fabric.enabledGRADIENT / zone pressure readouts

At least one must be enabled. When both are off, the status family reports disabled with explicit next surfaces once you enable a gate.

Stigmergic delivery posture
Live BMO TUI: `/stigmergy` and `/stigmergy-status` open the Stigmergic Delivery hub — gates, ready/degraded posture, metadata-only recent ring, and next surfaces — the same envelope as `bmo config show-stigmergy-delivery` and the agent/HTTP status tools.

Signal zones are the canonical pressure read surface. Use them when the operator question is “which zones are hot, contested, or cooling?” — not merely “are there recent deposits?”.

  • TUI: /signal-zones (aliases /signal_zones, /zones)
  • CLI: bmo signal zones with --pressure-state, --sort, --hot
  • Agent / MCP: leave_signal list actions and signal-zone readouts with pressure_states / include_threads

Signal zones are advisory. They do not accept manifests, prune rules, or mutate deposits. When zones match configured saturation specs, press e on a row to open zone explain and m for rule manifest review. An empty snapshot means no zones matched current specs yet — deposit signals or tune options.signal_fabric saturation specs before expecting ranked rows.

Signal zones pressure readout
Live BMO TUI: `/signal-zones` is the advisory GRADIENT surface — zone pressure, trend, evidence hints, and inspection recommendations without mutating deposits.

The TUI front door is a managed Stigmergic Delivery hub dialog — not a chat transcript dump. Open it from the status bar hint, /stigmergy, or /stigmergy-status (alias /stigmergy-delivery). From the hub, drill into GRADIENT signal zones (z), REACT triage (t), or explain when a zone is selected (e). Signal zones and triage also open explain on e when rows exist.

flowchart LR
  subgraph entry [Operator entry]
    SB[Status bar]
    SL["/stigmergy /stigmergy-status"]
    DISC[Discovery group]
  end

  HUB[Stigmergy Delivery hub dialog]
  ZONES["GRADIENT · Signal Zones"]
  TRIAGE["REACT · Stigmergy Triage"]
  EXPLAIN[Stigmergy Explain]

  SB --> HUB
  SL --> HUB
  DISC --> HUB
  HUB -->|z| ZONES
  HUB -->|t| TRIAGE
  ZONES -->|e| EXPLAIN
  TRIAGE -->|e| EXPLAIN

The live capture below shows the hub dialog posture readout.

Triage ranks what deserves inspection now: pending manifests, stewardship findings, suppression diagnostics, and actionable zone pressure without a direct rule item. Explain composes the causal packet for one zone after triage (or signal zones) selects it.

QuestionSurface
”What should I look at first?”bmo stigmergy triage, /stigmergy_triage, stigmergy_triage
”Why does this zone matter?”bmo stigmergy explain --zone '<glob>', /stigmergy_explain <glob>, explain_stigmergy
”What command is explicitly next?”recommendation.next_explicit_command in the explain/triage JSON

Triage supports --sort heat and --group threads on the CLI; the agent tool accepts the same sort and group fields. Explain and triage rows carry an evidence-bound recommendation packet with confidence, cited evidence, blocking evidence, and a read-only derivation ledger — agents should consume that packet instead of inferring the next step from prose.

Stigmergy triage queue
Live BMO TUI: `/stigmergy_triage` ranks manifests, stewardship findings, suppression diagnostics, and actionable zone pressure — here surfacing a pending manifest review for the saturated `internal/service/**` zone.
Stigmergy zone explain
Live BMO CLI: `bmo stigmergy explain --zone '<glob>'` composes recommendation, capability-fit, advisory slices, and tension manifest for one saturated zone — read-only guidance with an explicit mutation boundary.
Stigmergy explain dialog
Live BMO TUI: `/stigmergy_explain <zone-glob>` opens the same read-only explain dialog as triage or signal-zones `e` — recommendation, capability-fit, signal pressure, and read-only mutation boundary for one saturated zone.

The same getters flow through CLI, slash, agent tools, and MCP. HTTP currently exports the status read model only (GET /v1/stigmergy-delivery/status); explain and triage use CLI, TUI dialogs, agent tools, or MCP. Parity tests (TestStigmergyDeliveryStatusParity_AppAndAgent, TestStigmergyExplainParity_AppAndAgent, TestStigmergyTriageParity_AppAndAgent, plus MCP read-live tests) assert JSON equality modulo captured_at, preventing formatter divergence across surfaces.

sequenceDiagram
    participant Operator
    participant TUI as TUI slash and dialogs
    participant CLI as CLI stigmergy and config
    participant Agent as Agent and MCP tools
    participant HTTP as HTTP status only

    Operator->>TUI: /stigmergy or /stigmergy-status (hub)
    Operator->>TUI: /stigmergy_triage or explain via hub / zones / triage e
    Operator->>CLI: bmo config show-stigmergy-delivery
    Operator->>CLI: bmo stigmergy explain and triage
    Operator->>Agent: get_stigmergy_delivery_status
    Operator->>Agent: explain_stigmergy and stigmergy_triage
    Operator->>HTTP: GET /v1/stigmergy-delivery/status
    Note over TUI,Agent: Status on HTTP explain and triage on CLI TUI agent and MCP
FieldMeaning
posture: disabledBoth workspace_markers and signal_fabric gates are off
posture: readyAt least one gate is on and no recent failure-class ring events
posture: degradedGates are on but recent failure-class stigmergy events are present
recent_eventsMetadata-only ring with hashed session/zone prefixes — not raw drill-in

Status, explain, and triage packets are read-only. They name explicit next commands but never accept manifests, prune rules, or mutate deposits.

Enable at least one gate in bmo.toml:

[options.workspace_markers]
enabled = true
[options.signal_fabric]
enabled = true
# Optional: rank hot zones once deposits cross thresholds
[[options.signal_fabric.saturation_specs]]
zone_glob = "internal/**"
min_deposits = 2
min_sessions = 1
window_seconds = 3600

Signal-zone and triage readouts stay empty until deposits and saturation specs match your workspace. Use bmo signal deposit or agent leave_signal to seed pressure, then reopen /signal-zones or /stigmergy_triage. Live doc captures seed deposits against the flagship workspace fixture so screenshots show saturated zones rather than an empty snapshot.

Recommendation and triage surfaces never auto-execute the next step. They return evidence-bound packets with recommendation.next_explicit_command and a mutation boundary that states read-only guidance. Accept, dismiss, prune, reinforce, kill, and rule lifecycle changes stay on their dedicated commands.

SurfaceEntry
CLI statusbmo config show-stigmergy-delivery
CLI readoutsbmo stigmergy explain --zone '<glob>', bmo stigmergy triage
Agent toolsget_stigmergy_delivery_status, explain_stigmergy, stigmergy_triage, list_recent_stigmergy_events
MCPbmo_get_stigmergy_delivery_status, bmo_stigmergy_explain, bmo_stigmergy_triage
HTTPGET /v1/stigmergy-delivery/status
TUI/stigmergy and /stigmergy-status (hub dialog); /signal-zones, /stigmergy_triage, /stigmergy_explain <zone>; explain dialog from hub, triage, or signal-zones e; status bar Stigmergy: hint; ambient Stigmergy HUD panel (/fabric_hud)
Tracingstigmergy.fired / stigmergy.action — see tracing

The TUI hub route is /stigmergy (alias /stigmergy-status, /stigmergy-delivery). /stigmergy previously opened triage; triage is now only at /stigmergy_triage and /stigmergy-triage. Signal zones remain the GRADIENT pressure surface; explain opens from the hub, /stigmergy_explain <zone>, triage (e), signal zones (e when rows exist), or the CLI/agent tools.

Discovery aliases let /stigmergy typing surface the whole family by name: /stigmergy_zones and /stigmergy-zones resolve to /signal-zones; /stigmergy_hud and /stigmergy-hud resolve to /fabric_hud (Stigmergy HUD). Canonical commands stay the entries above; the aliases are operator-affinity for prefix completion.

  • Flagship demo: docs/demo/pages/flagship-ac-amalgam.html (workspace fixture under docs/demo/flagship/workspace-fixture/)
  • Capture check: cd bmo && task demo:stigmergy-ac:check
  • Maintainer replay: task demo:stigmergy and task demo:stigmergy-proof

Stigmergic delivery does not:

  • replace synchronous language-time analysis (see LSP integration)
  • auto-execute recommendations (read-only guidance; explicit commands mutate)
  • expose raw session or zone identifiers in the status ring (hashed prefixes only)
  • ship a hosted conformance service (maintainer sibling-spec harness only)

Stigmergic delivery topic — five-stage taxonomy, maintainer validation guidance (conformance and cross-surface parity harnesses), calibration ledger, and non-goals.

Status-family recent telemetry is metadata-only with hashed session/zone prefixes; use explain, triage, or list_recent_stigmergy_events for raw drill-in. Maintainer CI lanes are documented in docs/topics/quality/ci.md.