Multi-Agent Solution Design
Design multi-agent architectures across Copilot Studio, Microsoft Foundry, M365 Copilot, and Dynamics 365 — choosing the right orchestration pattern and platform for each agent role.
One agent is rarely enough
A multi-agent system is like a well-run restaurant kitchen. You do not have one chef doing everything. You have a head chef (orchestrator) directing a sous chef, a pastry chef, and a line cook — each with their own station, tools, and expertise.
The head chef decides who works on what, in what order, and when to combine the dishes. If the pastry chef runs into trouble, the head chef re-assigns or escalates. No single chef needs to know how to do everything — they just need to do their part well and communicate clearly.
In AI terms, each agent specialises in a task, a platform hosts it, and an orchestration pattern defines how they coordinate.
Multi-agent orchestration patterns
| Feature | Orchestrator | Peer-to-Peer | Hierarchical | Event-Driven |
|---|---|---|---|---|
| How it works | Central agent routes tasks to specialists and aggregates results | Agents communicate directly without a central coordinator | Manager agents delegate to sub-agents who may delegate further | Agents react to events independently — no direct communication |
| Coordination | Centralised — orchestrator owns the workflow | Decentralised — agents negotiate | Layered — each level manages the next | Loosely coupled — events on a shared bus |
| Best for | Most business scenarios — clear control flow | Small teams of equally capable agents | Large complex systems with natural hierarchy | High-throughput systems where agents work independently |
| Scalability | Limited by orchestrator throughput | Good — no single bottleneck | Good — delegates scale independently | Excellent — agents scale independently |
| Failure handling | Orchestrator detects and reroutes | Agents must self-recover or timeout | Manager handles subordinate failures | Dead letter queues, retry policies |
| Complexity | Low to medium | Medium — coordination overhead | High — multi-level management logic | Medium — event schema design needed |
| Example | Customer complaint: triage, investigate, respond | Two research agents debating a recommendation | Regional manager agents each controlling local agents | Order placed triggers inventory, shipping, and billing agents |
Exam tip: Default to orchestrator unless there is a reason not to
The orchestrator pattern is the right default for most business scenarios because:
- It provides clear control flow and easy debugging
- It handles failures centrally
- It maps naturally to business processes (someone is in charge)
Switch to a different pattern when you see these signals:
- Peer-to-peer: Agents need to debate or negotiate (rare in business solutions)
- Hierarchical: The system spans multiple regions, divisions, or teams with local autonomy
- Event-driven: High throughput, agents are independent, real-time reactions matter more than coordinated workflows
If the exam gives a standard business workflow, orchestrator is almost always correct.
Platform selection by agent role
Not every agent belongs on the same platform. Match the agent role to the platform that best serves it:
| Agent Role | Recommended Platform | Why |
|---|---|---|
| Customer-facing chatbot | Copilot Studio | Built-in channel support (web, Teams, phone), low-code authoring, DLP policies |
| Internal knowledge assistant | M365 Copilot (extended) | Leverages Microsoft Graph for M365 data, deployed via declarative agents |
| Complex reasoning with custom models | Microsoft Foundry | Full model control, code-first orchestration, Azure-scale compute |
| Prebuilt sales/service AI | D365 Embedded | Pre-configured, no build required, native D365 data access |
| Multi-step workflow with approvals | Copilot Studio + Power Automate | Agent for reasoning, flow for deterministic steps and approvals |
| Data pipeline and analytics | Foundry + Fabric | Foundry for AI logic, Fabric for data processing and storage |
Deep dive: A2A vs MCP — agent-to-agent vs agent-to-tool
Two protocols define how agents interact with the outside world:
Agent-to-Agent (A2A) — Google-originated open protocol for agents to communicate with other agents. Each agent publishes an “agent card” describing its capabilities. The calling agent sends a task; the receiving agent processes it and returns results. Think of it as agents hiring other agents.
Model Context Protocol (MCP) — Anthropic-originated open protocol for agents to access tools and data sources. An MCP server exposes tools (functions) that any MCP-compatible agent can call. Think of it as agents using a universal toolkit.
The key distinction:
- A2A = agent talks to agent (delegation, collaboration)
- MCP = agent talks to tool (data retrieval, actions)
In practice, a multi-agent system uses both: A2A for inter-agent orchestration, MCP for each agent’s tool access. Microsoft Foundry supports both protocols. Copilot Studio agents can consume MCP tools via connectors.
Cross-D365 multi-agent scenarios
The exam emphasises solutions that span multiple Dynamics 365 apps. These are the key cross-app patterns:
| Scenario | D365 Apps Involved | Agent Architecture |
|---|---|---|
| Order-to-cash | Sales + Finance + Supply Chain | Sales agent qualifies leads and creates quotes. Finance agent validates credit. Supply chain agent checks inventory and commits delivery dates. Orchestrator manages the handoffs. |
| Customer 360 | Sales + Customer Service + Marketing | Service agent captures case details. Sales agent retrieves account history. Marketing agent checks campaign engagement. Orchestrator compiles unified customer view. |
| Demand-supply balancing | Supply Chain + Finance | Demand agent forecasts from sales signals. Supply agent checks production capacity and lead times. Finance agent validates budget. Orchestrator balances trade-offs. |
| Field service + warranty | Field Service + Customer Service + Finance | Service agent creates the work order. Field service agent dispatches a technician. Warranty agent validates coverage. Finance agent processes the claim if warranty applies. |
🤝 Natalie designs a multi-agent system for a retail chain
Natalie Torres (Partner Solutions Lead, Cloudbridge Partners) is designing a multi-agent solution for a retail client with 200 stores, D365 Commerce, D365 Supply Chain, and D365 Customer Service.
The client wants an AI system that handles customer order issues end-to-end — from complaint to resolution.
Agent decomposition:
Natalie identifies four agents:
- Complaint Triage Agent — Reads the customer message, classifies the issue type (shipping, product quality, billing, returns), and determines urgency.
- Order Investigation Agent — Looks up the order in D365 Commerce, checks shipping status in D365 Supply Chain, and pulls relevant transaction data from D365 Finance.
- Resolution Agent — Applies business rules to recommend a resolution (refund, replacement, discount, escalation). Uses a Foundry model fine-tuned on 50,000 historical resolutions.
- Communication Agent — Drafts and sends the customer response via the appropriate channel (email, chat, SMS).
Platform assignment:
| Agent | Platform | Reason |
|---|---|---|
| Complaint Triage | Copilot Studio | Customer-facing, needs channel support, low-code rules |
| Order Investigation | Foundry | Queries across three D365 apps, needs custom data retrieval logic |
| Resolution | Foundry | Custom model for resolution recommendation, complex reasoning |
| Communication | Copilot Studio | Template-based responses, channel delivery, easy to update |
Orchestration pattern: Orchestrator. Natalie uses a Foundry-hosted orchestrator agent that sequences the workflow: Triage receives the complaint, passes classification to Investigation, Investigation feeds data to Resolution, and Resolution triggers Communication. If Resolution recommends a refund over $500, the orchestrator pauses for manager approval.
Ravi Krishnan (senior dev) builds the Foundry agents. Zoe Park (project manager) manages the rollout to 10 stores first, then scales.
Key terms
Knowledge check
A manufacturing company needs an AI system where an order event automatically triggers inventory allocation, production scheduling, and shipping preparation — all happening in parallel with no central coordinator. Which orchestration pattern fits best?
Natalie is designing a multi-agent system for retail order complaints. The Resolution Agent needs a custom model trained on 50,000 historical resolutions. Which platform should host this agent?
🎬 Video coming soon
Next up: Build, Buy, or Extend — determine when to use prebuilt agents, extend M365 Copilot, build in Copilot Studio or Foundry, or train custom models.