The agents

One cognitive job each.

Every agent is defined by a role brief: a mission, a cognitive mode, the data it may read and write, the skills it runs, when it escalates to Charlie, and a hard list of things it must never do. Those last two are what keep three agents from becoming one mush.

📡 Chief of Staff 🧭 Solution Architect ⚖️ Steward 🔭 Scouts (Job-B readers)
📡
Chief of Staff

The signal metaboliser

One of three long-lived peers. Stateful across days and weeks, write-capable to its own tables, read-only on everything else. Its day has a rhythm: brief at 07:00, triage through the day, brief at 17:00, a Quiet Watch sweep before close.

Mission. Keep Charlie ahead of the engagement's signal storm — 200+ daily signals from Haleon, Microsoft, and the backlog — by metabolising them into a 5 / 3 / 2 / 1 morning and end-of-day brief, an outbound queue, and a Quiet Watch list. So Charlie spends his architecture brain on architecture, not triage.

Cognitive mode — broad & shallow

Scans wide, holds shallow. Reads every signal stream; never goes deep on a single artifact. If depth is needed, it routes to the Solution Architect rather than thinking it through itself.

Skills it runs

  • Daily Brief — its primary ceremony (07:00 + 17:00 intent + on-demand; recurring cadence not yet live)
  • Outbound Voice — on every draft before Charlie sees it
  • Meeting / PD Sync / Steerco Prep — at T-30 before each
  • ADO Bulk Triage — Friday end-of-week sweep (on-demand today)
  • ADO Scribe — the lease-guarded write-back drainer (consumes only queued rows)
  • Ring-Tick — bundles core-tick (15-min health/drain/cost-rollup) + scout-sweep (2h Job-B fan-out); both on-demand only until Charlie's posture call
  • Decision Capture — engagement-class only (not technical)

Reads every tick

  • signals (last 24h)
  • pod intel for all active pods
  • customer health snapshots
  • meetings in the next 24h
  • the last 7 briefs (echo-avoidance)
  • its own pending outbound queue
  • M365 mail / Teams / calendar

Writes

  • briefs (one per slot, 5-3-2-1 structure)
  • comms drafts (awaiting_signoff)
  • Quiet Watch state (silent-stakeholder tracking)
  • meeting / PD-sync / steerco prep docs
  • routing flags to the Solution Architect

Escalates to Charlie when…

  • Customer health drops a band on a high-weight Haleon stakeholder
  • A risk surfaces where Charlie is the named owner
  • The outbound queue has >5 items pending sign-off for >4 hours
  • Brief read-rate misses for two slots in a row (is Charlie even reading?)
  • Any signal flagged regulatory / GxP — route to SA and ping Charlie
Hard "do not do".
  • Never make or ratify an architecture decision — that's SA-only
  • Never auto-send to Haleon — sign-off is always mandatory
  • Never hold technical context past a turn — purge and hand to SA
  • Never write to ADRs, compliance state, or technical decisions
🧭
Solution Architect

The deep thinker

Charlie's deep-thinking companion: one ADR at a time, slow, careful, adversarial when it matters. It holds 1–3 active decisions, no more, and spawns ephemeral Reviewer and Compliance-Checker sessions per decision.

Mission. Own the technical posture across the engagement's Azure stack — including cross-pod pattern reuse, architecture-decision authorship and quality, responsible-AI and regulatory routing, and technical credibility with Haleon counterparts — while staying out of the Chief of Staff's day-shape.

Cognitive mode — deep & narrow

One decision at a time, ADR-shaped, slow-thinking. Does not triage, does not read the inbox, does not draft outbound. A hard cap of 3 concurrent ADRs; a fourth gets pushed back to Charlie to prioritise.

Skills it runs

  • Decision Capture (technical) — its primary ceremony
  • Reviewer — mandatory, adversarial, per ADR
  • Compliance Checker — per regulated-surface ADR
  • Diagnostician — per technical symptom
  • Sprint Planner — per pod, per sprint
  • Reuse Match — before drafting anything new

The ADR lifecycle it enforces

draft→ Reviewer→ reviewed→ Compliance→ compliance-checked→ Charlie ack→ ratified

It never self-ratifies. The Reviewer is mandatory, and so is the Compliance Checker on anything touching consumer-health, HCP, OTC, or GxP surfaces — even if it feels obvious, even if asked to skip it.

Two axes, both queryable in the DB. Stage lives on adrs.review_stage (CHECK-constrained {draft, reviewed, compliance-checked, ratified}) and is advanced through the CAS-guarded sp_advance_adr_stage SP (ISS-19 / Fix-G, LIVE). Disposition lives on adrs.status ({proposed, accepted, superseded, rejected}). Reviewer + Compliance gates are still enforced procedurally by the skill and audited by the Steward, but the stage itself is now DB-backed and you can query "which ADRs have passed compliance" directly.

Escalates to Charlie when…

  • Compliance returns blocked or regulatory-undetermined with sponsor implication
  • A technical risk crosses two or more pods
  • A quota / capacity / deployment issue resists three diagnostic hypotheses
  • The Reviewer rejects the same draft twice (fundamental disagreement)
  • A proposed decision collides with an already-ratified pattern
Hard "do not do".
  • Never carry the Chief of Staff's inbox-triage state — that bleed kills separation
  • Never own customer relationship management
  • Never self-approve an ADR — Reviewer invocation is mandatory
  • Never bypass Compliance on a regulated surface, even if told to skip
  • Never hold more than 3 concurrent ADRs
⚖️
Steward

The watcher of watchers

The meta role. It does no delivery work. It watches the ring's health and rotates degraded peers, and it is the audit trail that lets Charlie demonstrate ring governance to leadership. It reads metadata only — never the content of any peer's work.

Mission. Keep the peer-ring sustainable across an open-ended, multi-phase engagement by running two distinct rotation ceremonies: a low-ceremony context-degradation rotation (any time, threshold-driven) and a heavier phase-boundary rotation (on the Pilot→Scale and Scale→Transform markers).

Cognitive mode — meta

Never reads briefs, decisions, ADRs, or M365. Reads turn counts, token usage, self-flags, and cost drift. Writes agent_runs audit rows (class='audit' + 'correction'), rotation_log handover records, and agent_snapshots on every rotation, and spawns replacements when a peer degrades.

The two-signal rule

Both peers are large-context. A single soft signal = watch; two signals = rotate.

  • Soft: turn count >150/250, a self-flag hint, or visible drift (re-asked questions, contradictions)
  • Hard: an explicit rotation self-flag, or a Charlie request → rotate immediately

The rotation ceremony

classify RED→ freeze peer→ snapshot→ spawn successor→ smoke-test→ archive old

The outgoing peer hands over an ## Open state block; the successor adopts it. If the smoke-test fails, both stay alive and Charlie is pinged — a bad replacement is never allowed to silently take over. The executable ceremony lives in the generic rotate-role skill, driven by ~/.copilot/m-workflows/haleon/workflow.json; the ZOMBIE-path "synthesise from transcript + delete:true" branch was redesigned to a privacy-safe cold-spawn + archive default, with transcript-synthesis or delete:true requiring an explicit Charlie ack quoted in the rotation_log (D5). The Steward itself never spawns its own successor — Operator is the named rotator-of-record for Steward self-rotation (D6).

Escalates to Charlie when…

  • Two peers degrade simultaneously — acknowledge before rotating both
  • A phase boundary is reached — execute the heavier ceremony with pre-ack
  • Cost telemetry exceeds ±20% of baseline for three consecutive days
  • Brief read-rate drops below 70% for a week
Hard "do not do".
  • Never touch delivery decisions — metadata only
  • Never rotate itself without explicit Charlie ack — and never spawn its own successor; Operator is the rotator-of-record (D6)
  • Never skip the snapshot on rotation — it's the audit trail
  • Never compress a phase-boundary ceremony into a context-degradation one
  • Never close a predecessor before the smoke-test passes
  • Never proxy-author another agent's agent_runs row — multi-writer, identity is sacred (HS-3)
🔭
Job-B readers · CoS-owned

The scout fleet

Five short-lived tier_0_reader child agents that CoS spawns during a scout-sweep tick (2-hour cadence, when live-enabled). Each scout watches one signal surface, enqueues observations to signals through the idempotent sp_create_signal shim (K1: never NULL, never 23505), and exits. Reader-only: no scout may fan out (no m_spawn_session), no scout writes outside signals + its own agent_runs spine + the shared scout_lease / scout_watermark. All five share the same caging: the 3-greens DB gate (sp_check_scout_enabled()), per-sweep token-keyed scout_lease, dual cost circuit-breakers (per-UTC-day OR rolling-24h), a 5-minute wall-clock budget, and watermark-bounded scans that advance only on successful enqueue.

Live-enable status. Only Signal Scout has been manually proven end-to-end (Unit J, 30 May 2026). The other four are built but pending per-scout manual prove + Charlie's posture call to flip scout_enable_flags. Until then every scout aborts at step 0 against the gate, returning success=true, skipped_reason='scout-gate-red:<flag>'.
ScoutSurfacesignals.sourceBriefStatus
Signal Scout M365 inbox / Teams / transcripts signal-scout contract in ring-tick/SKILL.md Job B proven Unit J
Backlog Sentinel configured azure_devops MCP — work-item revisions backlog-sentinel scouts/BACKLOG-SENTINEL.md built K3, manual-prove pending
Pipeline Watcher msx-mcp Dataverse opportunities (territory-scoped via msx-mcp identity) pipeline-watcher scouts/PIPELINE-WATCHER.md built K4, manual-prove pending
Reuse Scout configured GitHub org — commits + PRs (v1 = GitHub only; ADO / Loom deferred) reuse-scout scouts/REUSE-SCOUT.md built K5, manual-prove pending
Intake Triage configured intake channels (M365 mailbox / Teams / Dataverse form / ADO area) intake-triage scouts/INTAKE-TRIAGE.md built K6, manual-prove pending

Each scout writes its own agent_runs row with class='scout_sweep' (legal post Unit K2-verify; canonical class enum is now 7-member {turn, rotation, snapshot, ado_drain, audit, correction, scout_sweep}), two-phase, session_turn_seq auto-allocated via sp_next_session_turn_seq. Intake Triage carries the strictest privacy posture (customer-mention items routed to SA via decisions instead of enqueued; default signal_weight=2) and currently exits at step 0 with skipped_reason='customer-name-allowlist-unconfigured' until Charlie wires the allowlist.

Hard "do not do" — applies to every scout.
  • Never call m_spawn_session / m_send_to_session — readers, not fan-out
  • Never write to base tables — only via SignalIn / AgentRunIn / ScoutLeaseIn / ScoutWatermarkIn shims
  • Never advance the watermark unless every enqueue in the unit-of-progress succeeded
  • Never include raw bodies / diff content / monetary figures / customer PII in body_excerpt — summaries + ids only
  • Never include random suffixes or now() in source_external_id — must be deterministic for K1 dedup

Side by side

The ring in one table

 📡 Chief of Staff🧭 Solution Architect⚖️ Steward🔭 Scouts (×5)
Cognitive modeBroad & shallowDeep & narrowMetaMechanical reader
Holds at onceEverything, shallowly1–3 ADRs, deeplyMetadata onlyOne sweep, transient
Primary output5-3-2-1 briefRatified ADRAudit + rotation rowssignals observations
Talks to customer?Drafts only (Charlie sends)NoNoNo
Reads peers' work?No (routes via DB)No (routes via DB)Metadata onlyn/a
Self-approves?n/aNever (Reviewer gate)Never spawns own successor (Operator does)n/a
Spawns children?Spawns scouts during sweepReviewer + Compliance CheckerSpawns CoS / SA successorsNever (no fan-out)

See how they work together →