Multi-agent operating model

Three agents in a ring,
one architect at the centre.

The peer-ring is a small society of long-lived AI agents that run alongside Charlie — the human Lead Solution Architect — on an ongoing, multi-phase Microsoft × Haleon engagement. Each agent has one cognitive job, a shared memory, and strict boundaries that keep them from stepping on each other. This site documents how they think, how they talk, and what they actually produce.

3 long-lived peers + 5 reader scouts 1 shared Postgres brain · 52 DAB entities Human sign-off on every outbound Self-healing via rotation

The problem

Why a ring, and not one big agent?

A senior architect on a large engagement drowns in signal — 200+ daily pings from the customer, from Microsoft, and from the backlog — while simultaneously needing to do slow, careful architecture thinking one decision at a time. Those two modes fight each other inside a single context window.

The fix is cognitive separation. Split the work across agents that are each tuned for one mode, give them a shared database so they don't lose the thread, and add a third agent whose only job is to keep the other two healthy over a long-running, multi-phase program.

The two modes that fight

  • Broad & shallow — scan everything, hold nothing deep, never miss a signal. Chief of Staff
  • Deep & narrow — one architecture decision at a time, slow, adversarially reviewed. Solution Architect
  • Meta — watch the watchers; rotate any agent whose context is degrading. Steward

No single agent does all three well. So we don't ask one to.

The system at a glance

The peer-ring architecture

Three long-lived agent sessions sit around Charlie. They never message each other directly — they coordinate through a shared Postgres database (exposed via a data-API layer). The Steward only ever reads metadata about the other two; it never sees their actual work.

Peer-ring system architecture Charlie, the human operator, sits at the centre. Three agents — Chief of Staff, Solution Architect, and Steward — surround him. All three connect to a shared Postgres database. Chief of Staff and Solution Architect coordinate through the database using routing flags. The Steward reads only metadata from the database and can spawn replacements for the other two. haleon-aiac-db shared Postgres · ~29 base tables · 52 DAB entities · the single brain Charlie Lead SA (human) Chief of Staff broad & shallow signal triage · briefs · outbound Solution Architect deep & narrow ADRs · compliance · reuse Steward meta · governance health-watch · rotation routing flags (via DB, never direct) Steward spawns replacements
Solid lines = human conversation. Dashed lines = reads/writes to the shared database. The rose arc is the only peer-to-peer channel, and it runs through the database as routing flags — never a direct message. (Design note: peer routing is now persisted as data on decisions — decision_class, owning_peer, adr_id and narrative (ISS-14); the specific per-handoff flag values shown elsewhere are illustrative shorthand over those columns.)

Meet the ring

Three agents, three jobs

📡CoS

Chief of Staff

Metabolises 200+ daily signals into a twice-daily 5-3-2-1 brief, an outbound queue, and a Quiet Watch list — so Charlie spends his brain on architecture, not triage.

  • Mode: broad & shallow
  • Writes: briefs, comms drafts, prep docs
  • Never: makes architecture calls
🧭SA

Solution Architect

Owns the technical posture one ADR at a time — slow, careful, adversarially reviewed, with mandatory compliance gates on anything touching regulated surfaces.

  • Mode: deep & narrow (max 3 ADRs)
  • Writes: ADRs, compliance state
  • Never: self-approves a decision
⚖️Steward

Steward

The meta role. Watches the ring's health via metadata only and rotates any peer whose context is degrading — keeping the ring sustainable across an open-ended engagement.

  • Mode: meta / governance
  • Writes: agent_runs audit + rotation_log + agent_snapshots
  • Never: reads a peer's actual work; never spawns its own successor (Operator does that)

Go deeper on each agent →

Plus the scout fleet

Five reader scouts spawned per sweep

Beyond the three long-lived peers, CoS spawns up to five short-lived tier_0_reader scouts during each scout-sweep tick: Signal Scout (M365 inbox / Teams / transcripts), Backlog Sentinel (ADO work-item revisions), Pipeline Watcher (MSX Dataverse opportunities), Reuse Scout (configured GitHub org commits + PRs), Intake Triage (configured intake channels). Each scout writes only to signals + its own agent_runs audit row; none may fan out. All five are caged behind the 3-greens DB gate, a shared scout_lease, dual cost circuit-breakers, a 5-minute wall-clock budget, and watermark-bounded scans. Signal Scout is proven (Unit J, 30 May 2026); the other four are built but pending per-scout manual prove and Charlie's posture-flag flip. The recurring schedule itself is OFF — invoked on demand only.

See the scout fleet →

Two rules that hold it together

Human sign-off is mandatory on every outbound. No agent ever sends a message to the customer on its own. Drafts sit at awaiting_signoff until Charlie approves them. Tone is shaped by a shared voice skill, but approval is always human.
Role bleed is the enemy. Each brief carries a hard "do not do" list. The Chief of Staff never ratifies architecture; the Solution Architect never touches the inbox; the Steward never reads delivery content. Separation is the whole point.