Most multi-agent demos work on happy-path examples with unlimited budgets. Production requires: deterministic-enough behavior (stakeholders need predictability), cost controls (token budgets per task), latency SLAs (users won’t wait 5 minutes), graceful degradation (fallback when agents fail), and ops tooling (deploy, rollback, canary). The gap is not intelligence — it is engineering discipline.

At scale, orchestration moves from in-process function calls to distributed systems: message queues (Kafka, SQS) between agents, DAG runners (Temporal, Airflow) for workflow state, and service meshes for routing and retry. The orchestrator becomes a lightweight router that reads task state from a store and dispatches to the right agent service. This decouples scaling: you can run 10 coder agents and 2 reviewer agents independently.

Multi-agent systems can burn tokens fast: N agents × M turns × context length. Cost engineering strategies: smaller models for simple roles (use GPT-4 class for planning, GPT-3.5 class for formatting), context pruning (summarize history instead of passing full transcripts), caching (identical tool calls return cached results), early termination (stop when confidence is high), and budget alerts that pause tasks before overspend. Track cost per task, per agent, per customer.

Users perceive multi-agent latency as wall-clock time, not total compute. Reduce it with: parallel agent calls where the DAG allows, streaming partial results to the user while agents work, pre-computing common subtasks (warm caches, pre-fetched context), and speculative execution (start likely next steps before the current one finishes). Monitor critical path latency — the longest sequential chain of agent calls determines your floor.

A multi-agent system has many moving parts: model versions, prompt versions, tool implementations, and orchestration logic. Version everything and deploy with canary releases: route a small percentage of traffic to the new version, compare metrics, and promote or rollback. Use feature flags to toggle individual agent behaviors. Store the full configuration snapshot (model + prompt + tools + orchestration) for each deployment so you can reproduce any past behavior exactly.

Multi-agent systems cross traditional team boundaries: ML engineers own models, platform engineers own infra, product owns UX, and security owns guardrails. Successful teams use a platform model: a shared MAS platform team provides orchestration, observability, and guardrail primitives; product teams compose agents on top. Define ownership per agent (who is on-call?), SLOs per workflow, and incident response procedures that span teams.

Self-improving agents that learn from task outcomes and update their own prompts or tool usage. Agent marketplaces where specialized agents are published, discovered, and composed dynamically. Formal verification of agent protocols using model checking. Embodied multi-agent systems bridging software agents and robotics. Regulation: as MAS make consequential decisions, expect auditing requirements similar to financial systems. The field is moving fast — invest in patterns and principles that outlast any single framework.

You’ve traveled from what agents are (Ch 1) through architectures, communication, coordination, planning, game theory, LLM frameworks, evaluation, safety, and now production. The core lesson: multi-agent systems are distributed systems with language interfaces. Apply the same rigor you’d bring to any distributed system — observability, testing, failure handling, and incremental rollout — and you’ll build systems that actually work.