Design a Multi-Agent System Architecture That Scales in Production

A production multi-agent system architecture has five layers: the task decomposition layer (converts user goals into agent-specific subtasks), the semantic blueprint layer (structures instructions for each agent invocation), the MCP orchestration layer (coordinates typed communication between agents), the knowledge layer (RAG pipeline and memory management), and the Glass-Box observability layer (logs every decision across all layers). This workshop designs and builds all five layers in Python during the live session.

The right number of specialised agents is determined by the distinct capability domains your system requires, not by arbitrary decomposition. Start by identifying the fundamental capabilities needed: retrieval, synthesis, validation, moderation, and any domain-specific processing. Each distinct capability becomes one specialised agent with its own MCP server. Avoid splitting capabilities that naturally belong together and avoid combining capabilities that have different expertise requirements.

Hub-and-spoke architecture uses a central orchestrator agent that coordinates all other specialised agents: it decomposes tasks, dispatches to agents, collects results, and synthesises the final output. Peer-to-peer architecture has agents communicating directly with each other without a central coordinator. The workshop advocates hub-and-spoke for production systems because it is significantly easier to debug, monitor, and modify: all coordination decisions flow through one observable component.

Context isolation is an architectural principle that prevents context pollution: each agent receives only the context its semantic blueprint specifies, not the accumulated state of the entire multi-agent interaction. In the MCP orchestration layer, context isolation is implemented by the context router that assembles agent-specific context packages from the available context pool. Without architectural context isolation, multi-agent systems degrade as agents accumulate irrelevant context from other agents.

The architecture taught in this workshop is extensible by design: new specialised agents are added as MCP servers with typed tool interfaces, the orchestrator discovers new capabilities through MCP's capability negotiation protocol, and the semantic blueprint generator automatically learns to route tasks to new agents based on their tool descriptions. This plug-and-play extensibility means new capabilities can be added without modifying the core orchestration architecture.

The RAG pipeline is a specialised component of the multi-agent architecture, typically implemented as a dedicated RAG agent server exposed through MCP. The architectural relationship is: the orchestrator directs queries to the RAG agent, the RAG agent returns cited knowledge packages, and those packages flow to synthesis agents through the context routing layer. Designing the RAG agent as a first-class architectural component rather than a shared utility prevents the access conflicts and citation loss that occur when RAG is implemented as a shared function.