Multi-Agent Systems in Practice

In Session 6 you designed multi-agent systems on paper. Today you build one.

• Recap: Three architectures from Session 6 — Pipeline, Debate, Orchestrator
• Today's build: A 2-agent pipeline (Researcher → Analyst), then extend to 3 agents (+ Editor)
• The org chart analogy: Why companies have departments. Why agent systems need specialization.
• Key question: When does adding another agent help vs. adding complexity?

How agents talk to each other — message passing, shared context, and orchestration.

• Message passing: Agent A's output becomes Agent B's input. The simplest coordination pattern.
• Shared context: All agents read from and write to a shared workspace. More flexible but harder to debug.
• Orchestration: A manager agent decides who works on what. The pattern behind Claude Code's team feature.
• Live demo: See how a simple pipeline actually works in code — it's just function calls with structured outputs.

Build a Researcher → Analyst pipeline, then extend it with an Editor agent.

• Phase 1 (15 min): Build the Researcher agent — searches for information, returns structured findings
• Phase 2 (15 min): Build the Analyst agent — receives research, identifies patterns, generates insights and recommendations
• Phase 3 (15 min): Add the Editor agent — fact-checks, improves clarity, scores quality. Run the full pipeline end-to-end.

The ethics of multi-agent systems: who's accountable when information degrades across agents?

• Ethics moment: The 'telephone game' — each agent subtly changes information. After 3 agents, is the output still accurate?
• Live experiment: Run the same question through your pipeline 3 times. Do you get the same answer? Why not?
• Accountability: If Agent C gives a wrong answer based on Agent A's research, who's responsible?
• Safeguards: Citation chains, confidence propagation, and human review gates at critical handoffs.
• Business value: Division of labor works in companies AND in agent systems — but coordination has a cost.

Multi-agent isn't always better. Learn the decision framework.

• The complexity tax: Each agent adds latency, cost, and potential failure points
• Decision framework: Use multi-agent when tasks require different expertise, when quality review is critical, or when you need adversarial checking
• Stick with single-agent when the task is straightforward, speed matters more than thoroughness, or the pipeline is linear and simple
• Real examples: Content creation (multi-agent wins), simple Q&A (single-agent wins), code review (debate pattern wins)

You've built single agents, knowledge agents, and now agent teams. Next: apply them to YOUR industry.

• The stack: Tools (S4) → Real APIs (S5) → ReAct (S6) → RAG (S7) → Multi-Agent (TODAY)
• Next session: Agents for Your Industry — pick your department, build your agent
• Homework preview: Extend your pipeline, analyze information distortion, design a domain-specific multi-agent system