Skip to main content
Sideband detection is the asynchronous half of Mnemom’s Safe House. While the gateway intervenes same-turn at the four checkpoints on each agent request, the observer runs a parallel sweep across teams of agents and writes operator-actionable findings — it never touches an agent’s request or response. Four detector axes share this surface: All four write to governance_signals — the operator-actionable observation surface — surfaced via the dashboard, webhook, REST, and CLI. Sideband findings are never injected into an agent’s prompt. That boundary is structural, not a convention: the database rejects any write to the agent-facing advisory table with a sideband source. See governance signals for the full operator workflow.

​
Why sideband

Some signals only emerge across time, across sessions, or across the team — not on any single request. A single trace might pass every gate. The pattern of dozens of traces, across half the fleet, can still be telling you the agents are drifting apart on transparency or that one agent has quietly stopped escalating high-stakes decisions. The runtime gateway can’t see those patterns — it sees one request, one agent, one moment. The observer has the wider lens: it reads the team’s alignment cards on a configurable cadence, runs the detectors, and writes findings to governance_signals.
Sideband never intervenes on the request that triggered it and never touches an agent’s context. It observes on its own schedule and produces a record for an operator to see and act on — a dashboard entry, a webhook delivery, a row in GET /v1/teams/:id/governance/signals. There is no mechanism, at any layer, that carries a sideband finding into an agent’s prompt.

​
How the detectors are wired

The observer’s cron tick follows a five-step loop per active team:
  1. Enumerate active teams via an internal RPC. Filters: not archived, ≥2 non-deleted member agents.
  2. Fetch the team’s effective Trust Posture via GET /v1/teams/:id/effective-posture. The composer folds Platform → Org → Team with strictest-wins semantics per axis.
  3. Fetch member agents and their alignment cards via the canonical card store.
  4. Run the three pure-synchronous detectors (computeTeamCoherence, analyzeFaultLines, checkFleetCoherence) against the posture body’s per-axis thresholds. Each axis runs only if it’s enabled and the team’s per-axis cadence has elapsed.
  5. Fan out signals per the posture’s fan_out.rule. The default — and only v1 value — is per_named_affected_agent: one row per agent named in the finding.
Each sweep also writes a row to sideband_sweep_log (upserted by team_id × axis × day) — proof-of-coverage evidence for SOC 2 / EU AI Act control mappings, even when no findings are produced. Read it via GET /v1/teams/:id/sideband-coverage.

​
The Posture is the policy surface

Detectors don’t carry their own thresholds. Every per-source firing rule lives in the team’s effective Trust Posture and composes with strictest-wins per layer: If you want a detector tuned tighter for a banking team, you tighten the posture — never the detector code. See the how-to: Tuning sideband detection via Trust Posture.

​
Per-pattern emission for the fleet axis

The fleet axis can fire on three independent patterns: outliers, min_pair_score, and cluster_partition. When more than one fires on the same sweep, the observer emits one row per pattern with a distinct source_ref.pattern_type — one detection event per (rule, target, time-window), not aggregated.
Downstream consumers (dashboard, webhook subscribers) treat each row independently. Dedupe at presentation time if needed; the storage layer keeps detection events distinct — though the schema’s open-signal uniqueness (per scope, scope_id, source, pattern_type) also means a repeated firing of the same condition refreshes the existing open row rather than stacking duplicates. See Governance signals.

​
Multi-team agents

An agent that is a member of N teams is swept under N independent effective postures — each team’s posture composition is its own fold, and strictest-wins does not cross team boundaries. A finding that names the same agent under two different teams produces two independent governance_signals rows, scoped to their respective teams.

​
Webhook events

Each sideband firing emits a <source>.fired webhook event so external subscribers (SIEM, ticketing, alerting) can react:
  • sideband.coherence.fired
  • sideband.fault_line.fired
  • sideband.fleet.fired
  • sideband.drift.fired — emitted when a stored integrity checkpoint crosses the per-agent drift threshold, not by the per-team sweep; see Drift Detection
Subscribe via Webhooks; see the webhook contract for the delivery guarantees these events carry.

​
Compliance evidence — proof-of-coverage

Operations security buyers expect two artifacts:
  1. Findings — what fired, when, on which agent. Read via GET /v1/teams/:id/governance/signals or GET /v1/agents/:id/governance/signals, filtered to sideband.* sources.
  2. Coverage proof — even when nothing fired, evidence that the detector ran during the reporting window. GET /v1/teams/:id/sideband-coverage returns a per-axis 30-day rollup from sideband_sweep_log.
SOC 2 / EU AI Act / HIPAA control mappings can answer “show evidence that team X had its coherence detector swept N times during the audit window” from the coverage endpoint alone, without needing a finding to exist.

​
Sideband and AEGIS

Sideband findings are a signal to operators, never a runtime instruction to the agent. AEGIS does not inject sideband observations into agent prompts.

​
See also