MODULE 7  ·  DAY 2

The Multi-Agent Incident Crew

One agent grows into a crew of four.

Triage Investigate Fix Review each role has exactly one job. No single agent decides everything

Gourav Shah  ·  School of DevOps & AI  ·  Hands-on

M7·01

What you'll learn

What this module locks in before the lab.

12 34 Why go multi-agent — specialisation, separation, review loops When a single declarative agent is already enough Two paths: declarative profiles vs an orchestration framework Wire the Incident Crew as Compose services on one model
M7·02

1 · The analogy: a hospital, not a superhero

M7·03

One agent doing everything gets unfocused

One prompt for everything blurs every role.

One agent classify + retrieve + fix + review, all at once overloaded context · blurred roles · hard to audit tight prompt small context one clear job easy to audit
M7·04

A hospital, not a superhero

No single doctor does every step alone.

Triage nurse Doctor Pharmacist Attending routes you investigates writes remedy reviews & signs Triage Investigator Fixer Reviewer
M7·05

2 · Why multi-agent?

M7·06

Three things a single agent can't replicate

What earns the extra prompts and latency.

Specialisation Separation Review loop one tight prompt per role, small context — the small model stays reliable each agent sees only what it needs — less chance to hallucinate across lanes a dedicated role checks the fix before it ships — the safety net
M7·07

When is a single agent enough?

Don't reach for a crew by default.

Does the task produce a consequential action? NO YES Single declarative agent one use case end-to-end no separate safety review no command or deploy to sign Reach for a crew a command / deploy / API call review is a distinct job specialisation lifts reliability
M7·08

3 · The incident crew's pipeline

M7·09

The Incident Crew pipeline

A pipeline with one relevance gate.

Triage Investigate gate? Fixer Reviewer APPROVED ESCALATE NO runbook found → escalate
M7·10

4 · Two paths to multi-agent

M7·11

Two paths to multi-agent

Markdown profiles by default, a framework when needed.

Declarative (default) Four SOUL.md profiles + skills One Python pipeline, stdlib only Predictable sequential flow Change behaviour = Markdown edit The laptop-friendly 1.5B crew Framework LangGraph — supervisor graph, checkpointing, audit trails pause / inspect / resume any node CrewAI — role-based alternative agents.yaml + tasks.yaml routing for dynamic, non-sequential work
M7·12

Swap the orchestrator, not the tools

One shared layer under every orchestrator.

Declarative LangGraph CrewAI pick one — the layer below never changes the shared standards layer Skills MCP tools Guardrails
M7·13

5 · One model, four agents

M7·14

One model, four agents

Agents are cheap, the model is shared.

Ollama qwen2.5:1.5b native · ~1 GB Triage Investigator Fixer Reviewer crew container ~50 MB + ChromaDB ~200 MB ≈ 1.3 GB total
M7·15

Wire the crew with the Compose Spec

Each agent is a light service, one shared model.

compose.yaml — containers crew (Triage · Investigator · Fixer · Reviewer) ToolHive (MCP) ChromaDB memory reuses the Agentic-RAG assistant as a tool Model server Ollama — NATIVE :11434 host.docker.internal
M7·16

6 · The Reviewer as human-in-the-loop proxy

M7·17

The Reviewer, human-in-the-loop proxy

Decides if the fix is safe to show.

Reviewer when in doubt, REJECT APPROVED non-destructive + verbatim runbook REJECTED destructive · secrets · not in runbook Human decides
M7·18

TO THE LAB

Swap the orchestrator, keep the crew

Run both incidents, watch the gate work.

Triage Investigate Fix Review 503 → APPROVED Kafka → ESCALATE

Then Module 8 — harden & ship.  ·  Gourav Shah · School of DevOps & AI

M7·19