Microsoft AB-100: Multi-Agent Orchestration

Multi-agent design is explicitly part of the AB-100 architecture scope, but the exam is not asking candidates to split every workflow into a collection of agents. The real decision is whether separate responsibilities benefit from separate context, tools, permissions, knowledge, or ownership. A single agent can be easier to operate; several focused agents can be easier to secure and evolve. The architect must know when specialization creates useful boundaries and when it simply adds orchestration overhead.

Microsoft’s current Copilot Studio guidance distinguishes lightweight child or inline agents from connected agents with their own orchestration, tools, and knowledge. That distinction is a useful architectural lens because it forces a decision about how much independence a subagent actually needs. The choice affects state sharing, latency, testing, observability, deployment, and access control.

Split responsibilities only when the boundary is meaningful

Good candidates for separate agents usually have a distinct business responsibility: triage a request, retrieve policy, prepare a quote, validate compliance, or execute an approved action. The boundary should be understandable to both engineers and process owners. If two agents need the same instructions, same permissions, same tools, and the same context, separating them may create complexity without improving the design.

Specialization is valuable when it limits blast radius. A research agent can be read-only while a fulfillment agent has permission to update a system after approval. A finance-oriented agent can use different knowledge and validation rules from a customer-service agent. These boundaries make least privilege easier to express and can reduce the amount of context each agent needs to carry.

Choose inline versus connected agents deliberately

Inline or child agents work well for a focused subtask that belongs inside one larger agent. They can group instructions, tools, and knowledge without requiring a fully independent deployment. Because they share the parent context more naturally, they are useful when the main agent needs a reusable subroutine but the business process still has one clear owner.

Connected agents are better when the capability is independently useful, needs its own lifecycle, or should be owned by a different team. The cost is greater coordination: identity, version compatibility, timeout behavior, contract changes, and observability all need more attention. The architect should select independence because it solves an ownership or isolation problem, not because a multi-agent diagram looks more sophisticated.

Design orchestration around contracts and handoffs

Every handoff should define what the receiving agent needs, what it can assume, and what it returns. Passing an entire conversation transcript may be convenient, but it can leak irrelevant or sensitive context and increase token cost. A structured handoff containing the task, authorized data, key identifiers, and expected result is often easier to test and govern. When a handoff crosses product boundaries, MCP and A2A interoperability contracts must preserve those assumptions rather than conceal them.

The same principle appears in broader Power Platform architecture: workflows become easier to maintain when inputs, outputs, ownership, and failure paths are explicit. An agent handoff should be treated like any other enterprise integration contract.

Manage state without creating hidden coupling

Multi-agent systems need a clear answer to where state lives. Conversation state, business transaction state, long-running workflow state, and retrieved knowledge are not the same thing. If agents silently depend on one another’s ephemeral context, a retry or restart can produce inconsistent behavior. Durable business state should live in an appropriate system of record rather than only in model context.

The orchestrator should also know which results are authoritative. If two agents can update the same business object or offer conflicting recommendations, the architecture needs precedence rules or a reconciliation step. Otherwise the apparent modularity hides a coordination problem that will surface under concurrency or partial failure.

Use permissions to reinforce agent boundaries

Separate agents can make role-based access control easier to apply because each agent can receive only the tools and data needed for its function. A read-only knowledge agent should not inherit the same privileges as an action agent. Service identities, connector permissions, and downstream API authorization should reflect the actual task rather than the maximum capability of the platform.

Where Microsoft Entra policy is involved, Conditional Access and identity controls provide useful context for the trust boundary. AB-100 candidates should think in terms of who or what is acting, which resource is being accessed, and under what conditions. Multi-agent design does not remove identity; it increases the number of identities and interactions that may need governance.

Budget for latency, cost, and failure multiplication

Every additional agent can add model calls, retrieval, tool execution, network hops, and retries. A workflow that looks elegant on a whiteboard can become slow and expensive if five agents each perform broad reasoning before a simple action. Estimate the path length of common scenarios and reserve complex orchestration for cases where specialization creates real value.

Failure paths also compound. The distinction between high availability and fault tolerance is useful here because multi-agent reliability depends on how the whole chain behaves when one component becomes unavailable. Some tasks can fall back to a human queue or a simpler agent. High-impact actions may need to stop safely rather than continue with incomplete context.

Make observability part of the orchestration design

A production system should show which agent handled a request, what handoffs occurred, which tools were called, where latency accumulated, and why a workflow failed. Without that trace, teams see only that the final answer was poor and cannot identify whether the problem came from routing, retrieval, instructions, a tool, or a downstream service.

Adjacent operational skills in AI-300 reinforce this lifecycle mindset. AB-100 remains the architecture layer: define what must be measured and why, then choose the monitoring implementation that lets operators investigate the full multi-agent path rather than treating each agent as an isolated chatbot.

Use a simpler design when one agent is enough

A strong AB-100 answer can be to avoid multi-agent architecture. If one bounded agent can complete the task with a small set of tools and a clear policy, adding orchestration may reduce reliability. The exam rewards design judgment, not feature maximalism.

Related strategy material such as AB-731 focuses more on transformation and adoption, while AB-100 asks how the architecture delivers that strategy. In multi-agent scenarios, the best design is the one whose responsibilities, permissions, contracts, and failure modes can be explained plainly to both technical and business stakeholders.

Test the orchestration, not only the individual agents

An agent can pass its own tests and still fail inside a multi-agent workflow. Test routing, handoff data, permission boundaries, repeated calls, timeouts, conflicting results, and partial failure. Include cases where the orchestrator chooses the wrong specialist and cases where the specialist correctly refuses a task it is not authorized to perform. This reveals whether the architecture is truly modular or only appears modular under ideal conditions.

Regression testing becomes especially important when descriptions or tools change, because routing often depends on natural-language descriptions. A small wording change can alter which agent the orchestrator selects. Keep a representative test set for the highest-value business flows and rerun it after changes to instructions, agent descriptions, tool schemas, knowledge, or model configuration.

Define an operating model for the agent fleet

Multi-agent architecture also creates organizational questions. Decide who owns each agent, who approves changes, who can publish new versions, and who responds when a shared agent fails. Connected agents may serve several business processes, so an apparently local change can have multiple consumers. Versioning and change communication are therefore part of the architecture, not just project management.

Central governance should identify every production agent, its owner, data sources, tools, privileges, channels, and dependent agents. That inventory supports incident response and access review. It also helps architects spot duplicate agents that solve the same problem with different policies. A healthy multi-agent environment grows through reusable, governed capabilities rather than uncontrolled proliferation.

Control recursion, loops, and runaway delegation

Multi-agent systems need explicit limits on delegation. An orchestrator should not bounce a task between agents indefinitely, and connected agents should not recursively call one another without bounded depth or termination criteria. Set timeouts, maximum hops, or workflow-level budgets appropriate to the platform. When the system cannot make progress, it should return a clear failure or ask for human input rather than consuming resources in a loop.

The same guardrail applies to autonomous triggers. If one agent’s action can create an event that wakes another agent, the architecture should prevent feedback cycles. Model the event graph during design and test it under retry conditions. A loop that appears unlikely in a happy-path demonstration can become expensive or disruptive in production.

Document routing policy as business logic

Routing rules deserve the same design attention as any other business decision. Describe what signals make the orchestrator choose one agent over another, what happens when two agents appear equally suitable, and which requests should remain with the parent agent. Keep descriptions specific enough that routing is predictable, then verify them against a test corpus that represents real user language rather than only idealized prompts.

If routing has financial or compliance implications, consider deterministic prechecks before generative delegation. For example, a region, account type, or transaction class may determine which specialist is legally allowed to act. Let the model interpret intent where interpretation is valuable, but keep mandatory policy decisions explicit.