Hiding Multi-Agent Complexity
July 20, 1969. The Apollo 11 lunar module Eagle is descending toward the Sea of Tranquility. Armstrong's voice carries on the air-to-ground loop.
"Program alarm. It's a 1202."
A few seconds pass. He calls again, harder. "Give us a reading on the 1202 program alarm."
The 1202 is a computer overflow code. The guidance computer is running more tasks than it can complete in the cycle it has. The astronauts cannot diagnose it from the cockpit. They can only ask.
Cut to Building 30, Johnson Space Center. On the GUIDO (Guidance Officer) console, Steve Bales is 26 years old. He has seconds to call GO or ABORT to the Flight Director (FLIGHT). Bales punches back to the Staff Support Room (SSR), where Jack Garman, 24, is watching a hand-written cheat sheet of computer alarm codes he had written after a pre-launch simulation had triggered a landing abort weeks earlier. The cheat sheet sits under plexiglass on Garman's own desk. Garman knows the 1202 is survivable as long as it does not recur every cycle.
Garman's call comes through Bales' headset. "That's okay."
Bales relays to Gene Kranz on the loop. "We're GO on that alarm, Flight."
Kranz accepts. Capsule Communicator (CAPCOM) Charlie Duke speaks one voice outward to Eagle.
"Roger. We're GO on that alarm."
Eagle keeps descending. Minutes later, Armstrong lands.
I tell you this story because every multi-agent system I review now is built around the same decision Mission Control made that afternoon. Not in the workers behind the loop. In the loop itself. The astronauts heard one calm voice the whole way down. They never heard Bales. They never heard Garman. They never heard the Flight Director's poll. They heard CAPCOM. That single voice was a facade over four hundred competent specialists, and behind it the Flight Director was running real-time selection of which specialist answered.
This is Chapter 17 of the AOD series. Part III's fourth pattern. The Topology chapter (14) drew the four layers of an agent system, user, orchestrator, agent, capability. The Protocol Stack (15) showed how those layers talk. The Factory (16) showed what builds the agents that populate them. This chapter shows how all of that gets hidden behind one face. The Facade pattern is the contract the caller actually sees. The Strategy pattern is what lets the facade adapt without breaking that contract.
Four hundred competent specialists were not the problem. Four hundred radio channels would have been.
The Failure Isn't the Specialists
Roughly four hundred engineers, doctors, and trajectory analysts worked on Apollo 11 across Mission Control, the back rooms, the launch site, and the supplier network. Every one of them had a competent answer for the question their console was monitoring. The hardware worked. The training worked. The simulations had been run hundreds of times.
The failure mode the Flight Director's structure prevented was the one nobody talks about. A cockpit with four hundred radio channels. The astronauts having to know which specialist to call for which symptom, in milliseconds, while flying a lunar descent on a five-minute fuel reserve. The Flight Director losing the ability to compose a single GO/NO-GO answer. The program being ungovernable in real time.
This is the canonical setup for the Facade pattern in object-oriented programming. A complex subsystem of specialists works fine. Every caller has to know which specialist to call, how to call it, and how to compose the results into a coherent answer. The fix is not to remove the specialists. The fix is to wrap them in a single class that the caller sees, and let the specialists stay where they are.
The same fix lands in agentic systems. The agents and subagents (short-lived helpers spawned by an agent for a single task) behind the topology stay where they are. The capabilities, the MCP (Model Context Protocol) servers, the A2A (Agent-to-Agent) endpoints, the skills, the tools, all of it. What changes is what the caller sees. One orchestrator. One interface. One contract.
Same specialists. One doorway.
That is the move. The next section names it.
The OOP Map: Facade and Strategy
Two patterns from the Gang of Four (GoF) book, Design Patterns (1994), recast for agents. They work together, and the chapter argues you cannot have one without the other in a serious multi-agent system.
The Facade pattern. A single class wraps a complex subsystem and presents a simplified interface to the caller. The subsystem's specialists keep their independence. The caller stops needing to know the topology of what sits behind the door.
The Strategy pattern. A family of algorithms, each kept independent, swappable at runtime. The caller binds to the interface. Which algorithm runs is a runtime decision made by something other than the caller.
What changes when the products are agents instead of objects:
The Facade hides not just objects but a whole topology. Orchestrator, agents, subagents, skills, MCP servers, tools. The interface the caller sees is a request, not a method call. The implementation behind the interface is the full four-layer architecture from Chapter 14 (user, orchestrator, agent, capability).
The Strategy hides not just an algorithm but a whole agent. Which specialist runs, Backend-Python-Agent versus Backend-Node-Agent, Security-Reviewer-A versus Security-Reviewer-B, is decided at runtime by the orchestrator. Not by the caller. The caller never sees the choice.
The two patterns combine cleanly. The Facade hides that there are multiple implementations. The Strategy decides which implementation runs. The caller sees one face. The orchestrator behind that face decides which agent answers.
Polymorphism from Chapter 5 (same interface, different implementation) gave us the interface. Strategy gave us the runtime choice of which specialist behind that interface. Facade gave us the place to make that choice invisible. Three patterns the OOP world has been operating with for thirty years, with a tighter contract in the agentic case because the implementations are not just classes. They are full agents with their own context, their own memory, their own protocol stacks.
What the caller sees. What the orchestrator decides. What the agent does. Three jobs, three boundaries, one face.
The Orchestrator IS the Facade
Look at the four-layer topology from Chapter 14 again. The user only ever talks to the orchestrator. The orchestrator decides which agent answers, which subagents spawn, which skills load, which MCP servers connect, which tools execute. The user types one request. One response comes back.
This is the Facade pattern in agentic form, extended with runtime strategy selection, stateful composition, and policy enforcement the GoF version did not carry alone. The user is the caller. The orchestrator is the facade. The agents, subagents, skills, MCP servers, and tools are the subsystem.
The orchestrator does not just route. It hides several things at once.
Which agent ran. The user does not know whether the Frontend Agent or the Mobile Agent answered the question about touch handlers. Both could be right. The orchestrator picked.
Whether the agent was persistent or ephemeral. The user does not know whether the request triggered a long-lived Code Reviewer Agent that retained context from earlier sessions, or whether a one-shot Code Reviewer Subagent spawned, executed, and discarded.
What protocols moved between layers. The user does not know whether the agent used MCP to query a database, A2A to consult a peer agent, or both. The protocol stack is invisible from the front of the facade.
What the topology looked like at all. The user sees one face. The orchestrator sees the topology.
Mission Control worked because the astronauts heard one voice regardless of what was happening behind it. Back-room composition in the SSR, the Flight Director's runtime calls, the inter-console polls. All invisible to the crew. The orchestrator's job in an agent system is the same shape. One request in. One response out. The four layers stay invisible.
The face is also a trust boundary. Everything the user does not see, the orchestrator must record. Which agent ran. Whether it was persistent or ephemeral. Which protocols moved. Which tools fired. Mission Control hid the back-room voices from the crew and recorded every one of them for post-flight review. An agent facade has to do the same, or the opacity that makes the system usable also makes it un-auditable.
I have watched orchestrators break when the facade is built outward but not inward. The user gets one clean face. The team behind it cannot tell which agent ran, which subagent spawned, or which protocol moved when the wrong answer comes back.
Composition Behind One Face
When a request lands at the orchestrator, what runs behind the facade is rarely one agent. A code review request might fan out to a Style Agent, a Security Reviewer, a Test Coverage Analyst, and a Performance Subagent. The orchestrator composes the responses, resolves disagreements, picks the answer the user will see. The user gets one response back. They never see the fan-out.
This is the composition half of "Facades and Composition." The chapter title pairs them deliberately. A facade without composition is a wrapper. A facade with composition is what makes multi-agent systems usable.
I have watched fan-out coordination fail when the orchestrator surfaces every worker's voice instead of composing them. Four agents answered. The user got four answers. The facade collapsed.
The clearest historical instance of composition behind one face is the GO/NO-GO poll. Before any critical maneuver during Apollo descent, the Flight Director would go around the room and ask each specialist for a one-word answer.
"OK, all flight controllers, GO/NO-GO for powered descent."
The poll moves around the room. RETRO (retrofire). FIDO (flight dynamics). GUIDANCE. CONTROL. TELCOM (telemetry). GNC (guidance and navigation control). EECOM (electrical and environmental). SURGEON. Eight consoles, eight one-word answers, every one of them "GO."
CAPCOM relays one voice outward to the astronauts. "Eagle, Houston. You are GO for powered descent."
Eight specialists' judgments. One voice forward. The astronauts never heard the poll. They heard the composed result. The orchestrator's job in an agent system is the same.
The Governance Triad (PM Agent, Architect Agent, Team Lead Agent), which Chapter 16 placed as the persistent product set of the factory, also sits behind this face. It validates what the caller never sees, the spawned agent's identity, its scope of action, the data it is allowed to send out, the tools it is bound to. Outputs run back through the same triad before the orchestrator composes a single answer.
Strategy at Runtime
Strategy gives the orchestrator the right to choose. Two agents can both implement "code review." The orchestrator picks based on context, language detected (Python versus Rust), risk profile (security-sensitive versus routine), time budget (deep-review-mode versus fast-feedback-mode), or simply availability (one agent is currently busy).
A/B testing falls out naturally. Two implementations of the same agent role can run side by side. The orchestrator routes some requests to A, some to B. The user never knows which one answered. The team learns which implementation performs better. Same interface, different bodies behind it.
Hot-swapping is the same pattern. When a new agent implementation ships, the orchestrator can route a percentage of traffic to it. If it underperforms, the orchestrator routes back. No changes to the caller's contract. No changes to the user's mental model of the system.
Hot-swap safety depends on the strategies themselves being signed, version-pinned, or pulled from an allowlist. Without those controls, runtime selection becomes a way for any agent to inherit the caller's trust without proving it earned that trust. Strategy decouples implementation from interface, which means the interface alone cannot tell the orchestrator whether the implementation behind it is the one the team approved.
Graceful degradation is the failure-side variant. If the preferred specialist is unavailable (model timeout, MCP server down, rate limit hit), the orchestrator can route to a fallback specialist with the same interface but reduced capability. The user gets an answer, possibly a thinner one, instead of an error. From the user's perspective, this is the difference between a product that visibly degrades and one that quietly keeps working. Chapter 18 takes up the propagation path when even the fallback fails.
I have watched hot-swap go wrong when the replacement implementation is functionally clean but quietly weaker on the boring controls. Same interface, different posture behind it. The user does not see the difference. The auditor finds it eventually.
The 1202 alarm from the opening is the runtime-strategy beat in its purest form. Bales did not have time to call the entire console room. Garman had a hand-written cheat sheet under plexiglass on his SSR desk, and Bales had Garman's voice on the loop. Bales selected Garman's judgment at runtime, in seconds, out of dozens of available specialists. Kranz selected Bales. CAPCOM selected the words. The astronauts heard one calm voice on a descent clock measured in minutes.
Chapter 16's factory builds the specialists that Strategy chooses among. The factory contract decides what each implementation looks like. The orchestrator decides which one runs. Creation belongs to the factory. Selection belongs to the orchestrator. They sit on opposite sides of the facade.
Orchestration Beats Agency
The instinct in early agent systems is to push autonomy as far as it goes. Give the agent a goal, let it figure out the path. That is where the visible energy is. That is where the demos sparkle. It is also where reliability cracks.
Paweł Huryn (Product Compass) frames the practitioner reality as three autonomy levels:
| Level | Autonomy | Description |
|---|---|---|
| LLM Workflow | Zero | Deterministic orchestration calls the large language model (LLM) at specific points. No autonomy. |
| Agentic Workflow | Low | Orchestrated with detailed prompts and structured outputs. Bounded autonomy at known steps. |
| AI Agent | High | Autonomous execution against an objective. The agent decides its own path. |
Most production systems live at the lower two levels. The reasons are operational. Cheaper, faster, more reliable, more testable, more legible to the team running the system. The facade and strategy patterns make the lower levels survivable in practice because they hide the orchestration from the user. The user does not care whether the answer came from a deterministic workflow or from an autonomous agent. The user cares whether the answer is right.
Huryn's diagnostic framework for where reliability cracks show up:
- Missing facts → use retrieval-augmented generation (RAG)
- Formatting issues → consider fine-tuning the model
- Most cases (roughly 80%) → fix the prompt
This is the practitioner's "prioritize orchestration over autonomy" rule. Move deterministic logic to the orchestration layers wherever possible. Reserve autonomy for the parts where the path actually cannot be enumerated in advance. The anchor quote, worth keeping verbatim, lands the position. "Nobody cares if it's an AI agent or a simple script, as long as it works." This is the user's perspective from behind the facade. The facade pattern is what makes the quote literally true.
Anthropic's engineering team makes the same argument from the platform side. In "Building Effective Agents" (Schluntz and Zhang, Anthropic Engineering, December 2024), they distinguish workflows from agents on the same operational grounds. "Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale." Their position is sharper still. "This might mean not building agentic systems at all." Platform vendor and practitioner converge on the same point.
When the Facade Earns Its Keep
A single-agent system does not need a facade. The user talks to the agent. The agent does the work. There is no topology to hide.
A two-agent system might not need one either, if both agents have visibly different jobs and the user knows which to call. A code reviewer and a deployment agent with clear boundaries can stand side by side without a facade between them.
The facade earns its keep when one of four conditions holds.
- Multiple specialists answer the same kind of question. The user should not have to pick which one. The orchestrator picks.
- The topology is going to change. Agents will be added, swapped, deprecated. The facade insulates the user from those changes so the contract stays stable while the implementation moves.
- Governance enforcement runs behind the interface. Validation has to happen before workers run, and the validation cannot be the user's responsibility. The facade hides the enforcement.
- Strategy is in play. A/B testing, hot-swapping, graceful degradation all assume a stable interface in front of moving implementations.
This parallels Chapter 14's right-sizing argument for topology and Chapter 16's right-sizing argument for the factory. The facade earns its place by the constraint, not by the convention. I find that the pattern is overhead until the constraints arrive. Then it is structural.
Why This Matters Now
The facade and strategy patterns are not decoration. They are the layer that makes multi-agent systems usable at all. Without a facade, the user has to know the topology. With one, the user types a request and gets an answer.
The orchestrator IS the facade. The factory (Chapter 16) builds the implementations behind it. Strategy chooses which implementation runs at the moment of the request. The Governance Triad enforces the contract before workers run. The user sees one face.
Orchestration beats agency in most production cases. Not because autonomy is wrong, but because the user behind the facade does not care which it is. They care that it works. Huryn said it from the product side. Anthropic confirmed it from the platform side. Mission Control proved it operationally in 1969 with vacuum-tube radios and a hand-written cheat sheet.
If your roadmap has more than one agent and no named orchestrator owner, that is the gap to close this quarter.
The orchestrator is the face the caller sees. The topology, the factory, the protocols, the governance are the body behind it. Build the face deliberately, because the caller will only ever talk to the face.
Four hundred competent specialists were not the problem on July 20, 1969. Four hundred radio channels would have been. The same logic holds for multi-agent systems with no facade. The agents may all be competent. The composition is what makes them legible to the caller.
What's Next: When the Mask Slips
The facade I have drawn assumes the workers behind it actually do their job. Most of the time they do. Some of the time they do not. The model times out. The MCP server fails. The subagent returns a result that fails the governance check. Strategy's preferred specialist is unavailable and the fallback is not enough either.
When that happens, the facade still has to present something to the caller. The orchestrator has to decide. Retry with the same specialist. Route to a different specialist. Escalate to a human. Surface the failure with a recoverable error message. The propagation path through the topology has its own shape, and Chapter 18 takes it up.
Coming up next, I'll show what the orchestrator does when the worker behind the facade cannot deliver. The escalation chain is the load-bearing piece nobody draws on the topology diagram until they need it.