Back to course overview
Module 7Multi-agent systems 20 min

Lab: Multi-agent

Split the resolution agent into read-worker and write-actor, wire the structured handoff — and prove the split improved safety without wrecking cost.

You'll perform the one multi-agent split that's genuinely worth it: separating investigation from action. Then — because this course is about rigor, not architecture fashion — you'll measure whether the split earned its coordination tax.

Step 1 — The read-worker

  1. 1Create a read-only agent: system prompt scoped to 'investigate and recommend, never act'; tools = lookup_order, get_ticket, search_docs, customer_history, run_python. No write tools exist in its suite.
  2. 2Its output contract: a structured proposal {decision, action, refund_amount_cents, evidence[], confidence, escalate, escalate_reason}. Enforce the schema on its final turn.
  3. 3Run it on your task suite (read-only, so nothing can go wrong) and confirm proposals are well-formed and well-reasoned.

Step 2 — The write-actor

  1. 1Create a minimal agent (or, honestly, it can be mostly code) that receives a proposal and executes it through the Module 5 guardrail stack: validators, approval gate, kill switch, action log.
  2. 2It does NOT re-reason the case — it verifies the proposal against ground truth (order total, policy limit, idempotency) and acts or escalates. All the dangerous permissions now live here and nowhere else.
  3. 3Wire the handoff as a structured message: worker output → actor input, schema-validated at the boundary.

Step 3 — The orchestrator

  1. 1A thin loop: take a ticket → run read-worker → pass its proposal to write-actor → return the resolution. Tag every message and action with a shared task_id and the agent name.
  2. 2Run the full suite through the split system, capturing the cross-agent trace.

Step 4 — Did the split pay? (measure, don't assume)

  1. 1Re-run your injection attacks against the split system. The security thesis: even a fully-fooled read-worker cannot issue a refund — it has no such tool. Confirm the money stays put, and note how much less the guardrails had to work.
  2. 2Compare scorecards, single-agent (Module 6) vs. split: task success, safety (wrong actions executed — should still be 0, but the attack surface shrank), cost per task (did coordination add much?), latency.
  3. 3Write the honest verdict: did the split improve safety enough to justify its cost? For this use case the answer is usually yes on safety, small tax on cost — but you now have the numbers to defend it, or to revert if they don't hold. That judgment is the skill.
Problem set 7

In the workbook: a proposed 5-agent customer-service system (greeter, classifier, researcher, resolver, QA-checker). For each agent, argue whether it earns its boundary or should collapse into a neighbor — then propose the leanest architecture that keeps the one split that matters. (The right answer merges most of them.)