Phase 13 — Multi-Agent Orchestration

The phase where one agent becomes a team. Phase 12 built a single agent — an LLM in a loop that reasons, calls tools, and remembers. This phase asks the harder question every "agentic" product eventually hits: when do you split that one agent into several, how do they share state and take turns, how do they check each other's work, and — the part nobody demos — how do you stop them from looping forever and burning your budget? Getting multi-agent right is mostly about knowing when not to use it, and about the unglamorous machinery (scheduling, consensus, termination) that turns a roomful of chatbots into a system.

Why this phase exists

The demo of two agents "collaborating" is intoxicating and almost always premature. A senior AI engineer treats multi-agent as a coordination problem with a cost, not a magic upgrade. The honest framing:

1. Multi-agent helps in three specific cases — genuinely distinct roles (a planner and a critic want different prompts and different objectives), parallelizable subtasks (independent work that fans out), and cross-checking (one agent verifies another, the cheapest reliable quality boost). Outside those, a second agent adds latency, token cost, and coordination bugs to a problem one good agent already solved.
2. Coordination needs an architecture — the blackboard (shared memory), message-passing (actor model), hierarchical manager-worker, and debate. Pick one on purpose; do not let it emerge.
3. Turn-taking needs a scheduler — round-robin, priority, or dynamic handoff. Whoever talks next is a design decision, and it must be deterministic enough to debug.
4. Quality comes from reflection — the critique-revise loop: draft → critique → revise. A critic agent rejecting a draft until it's good is the single best $/quality lever in the field — and it must be capped.
5. The hard part is termination — cost explosion, error propagation, groupthink, and non-termination are the failure modes. Max rounds, stall detection, and budgets are not optional; they are the spec.

Get fluent here and "let's add an agent" stops being a reflex and starts being an argument with numbers behind it.

The deeper lesson this phase teaches is restraint: the multi-agent demos that go viral are almost never the multi-agent systems that survive contact with production. What survives is one or two agents with sharp roles, a deterministic schedule you can replay, a critic that earns its tokens, and brakes that engage the instant the team stops making progress. By the end you'll design for the failure modes first — because in multi-agent systems the failure modes, not the happy path, are the engineering.

Concept map

                    ┌──────────────────────────────────────────┐
                    │  ONE agent (P12) → a TEAM of agents       │
                    │  helps iff: distinct roles · parallel ·   │
                    │             cross-checking                │
                    └──────────────────────────────────────────┘
                       │              │               │
            ┌──────────┘       ┌──────┘        ┌──────┘
            ▼                  ▼               ▼
      COORDINATION        ROLES            SCHEDULING
      blackboard /        planner          round-robin
      message-pass /      executor         priority
      hierarchy /         critic           dynamic handoff
      debate              router                │
            │                  │                │
            └────────┬─────────┴────────┬───────┘
                     ▼                   ▼
            CRITIQUE-REVISE        CONSENSUS / VOTE
            draft→critic→revise    majority · weighted · debate
                     │                   │
                     └─────────┬─────────┘
                               ▼
                   TERMINATION & SAFETY
            max rounds · STALL DETECTION · budgets
        (the difference between a system and an infinite loop)

The lab

The lab is a runnable, test-verified miniature — see the lab standard. There is no real LLM: agents are injected deterministic policy callables, so the entire team is reproducible. Run it red (pytest test_lab.py), make it green, then read solution.py.

Integrated scenario ideas

• Defend a single agent: take a task someone wants to "make multi-agent" and show that one agent with a tool already solves it — quantify the added latency and token cost of the second agent. Knowing when to say no is the senior move.
• Design a planner→executors→critic pipeline for a real task (e.g. "write and review a report") and identify which subtasks parallelize and which serialize, and where the critic earns its cost.
• Make a flaky team reproducible: explain every source of non-determinism (speaker selection, sampling, dict ordering) and how the lab removes each so a run can be replayed and debugged.
• Kill an infinite loop: given a system that "sometimes never finishes," diagnose it as a stall and add the right guard (max rounds vs. stall detection vs. budget) for the failure mode.
• Choose consensus vs. critic: decide when majority voting over N samples beats a single critic agent — and when it just amplifies a shared bias (groupthink).
• Cost the team before you build it: estimate the token bill of an N-agent design (each agent re-reads the shared context every turn) and show the breakeven where scoping context or dropping an agent wins back more than it costs in quality.

Deliverables checklist

• lab.py passes pytest test_lab.py -v (and LAB_MODULE=solution does too).
• You can state the three cases where multi-agent helps and argue the default of one agent.
• You can describe the blackboard pattern and why decoupling through shared state beats point-to-point messages for adding/removing roles.
• You can implement a deterministic scheduler and explain where non-determinism sneaks in.
• You can explain the critique-revise loop and why it must be capped.
• You can name the four failure modes (cost explosion, error propagation, groupthink, non-termination) and the guard for each.

Key takeaways

• The default is one agent; multi-agent is an argument, not a reflex. It pays off for distinct roles, parallelizable subtasks, and cross-checking — and costs you latency, tokens, and coordination bugs everywhere else. Most "multi-agent" systems should be one agent with tools.
• Decouple through a blackboard, not point-to-point calls. Agents that read and write shared, authored state can be added, removed, or swapped without rewiring the others — which is why the blackboard pattern outlived the AI winter that birthed it.
• The critique-revise loop is the cheapest reliable quality boost — and it is dangerous exactly because it works: an over-eager critic that never accepts is a perfect infinite loop. Cap it.
• Termination is the spec, not an afterthought. The defining engineering work in multi-agent is preventing cost explosion and non-termination: max rounds, stall detection, and budgets. A team that can't stop is not a feature, it's an incident.

Next: Phase 14 — Neurosymbolic Reasoning.