MODULE 7  ·  DAY 2

The Multi-Agent Incident Crew

One agent grows into a crew of four — sharing one model

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

Why a crew, when one agent is enough, and the two ways to build one.

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

One agent doing everything gets unfocused

Cram triage, retrieval, fixing and safety into one prompt and roles blur.

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·03

A hospital, not a superhero

No single doctor greets, diagnoses, prescribes, and signs their own order.

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

Three things a single agent can't replicate

The properties that earn 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·05

When is a single agent enough?

Multi-agent adds real overhead. Don't reach for it 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·06

The Incident Crew pipeline

A sequential pipeline with a relevance gate that can short-circuit.

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

Two paths to multi-agent

Declarative profiles by default; a framework when you need more control.

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·08

Swap the orchestrator, not the tools

Skills, MCP tools, and guardrails are the same layer under every crew.

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

One model, four agents

Agents are cheap Python calls. The model is expensive — and 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·10

Wire the crew with the Compose Spec

Each agent a lightweight service, all sharing one endpoint and memory.

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·11

The Reviewer — human-in-the-loop proxy

It doesn't decide to fix; it decides if the fix is safe to show a human.

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

TO THE LAB

Swap the orchestrator, keep the crew

Read the four profiles, 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·13