Microsoft shipped general availability of multi-agent orchestration in Copilot Studio this month, letting one agent call another agent as a skill, including agents built in Azure AI Foundry and external M365 Copilot agents. The announcement landed on the Copilot Studio docs and the blog feed last week. If you build agents inside Microsoft 365, this changes how you should think about agent design starting now.
I have been testing it for a few days. The feature itself is straightforward. The interesting part is which multi-agent orchestration pattern you pick, because most teams will default to the wrong one and rebuild six months from now.
What it actually does
You can now register another agent as a connected agent inside Copilot Studio. The parent agent sees it as a tool. When the LLM decides the user request fits the connected agent’s described purpose, it hands off the conversation, gets a structured response back, and continues reasoning.
Three things are worth knowing. The handoff is generative, meaning routing depends on the description you write for each connected agent, not on trigger phrases. The child agent runs with its own instructions, its own tools, and its own knowledge sources. And the parent agent receives the child’s output as context it can reason over, not as a final answer it must return verbatim.
You can chain this. Parent calls child A, child A calls child B. You can also fan out, where the parent calls multiple children based on the request shape.
Why it matters
Single-agent designs hit a wall fast. I wrote about this in Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat. When one agent owns too many topics, routing fails at the edges, the system prompt balloons past 4000 tokens, and every change risks breaking three unrelated flows.
Multi-agent orchestration lets you split by domain. One agent for HR queries, one for IT, one for finance, each with its own tight instructions and tool list. The parent becomes a router with personality. That sounds clean, and it can be, but only if you pick the right pattern.
From what I have seen building and from what I hear from people at other organisations, three patterns keep showing up:
Supervisor pattern. One parent agent owns the conversation, delegates to specialists, aggregates results. Best when the user does not need to know which agent is answering. Trade-off: the parent’s instructions become the bottleneck. If the parent picks the wrong child confidently, you get the same misrouting failure mode I described in my post on Copilot Studio agents passing tests and still failing in production, just one layer deeper and harder to debug.
Sequential pipeline. Agent A produces output, agent B consumes it, agent C finalises. Best for structured workflows like draft, review, publish. Trade-off: latency stacks. Each hop adds seconds, and latency is the quiet killer of agentic workflows — budgeting round-trip time before you build matters more than most teams expect.
Peer network. Agents call each other based on need, no fixed parent. Powerful, almost always premature. I have not seen a single internal use case where this beats a supervisor design once you account for debugging cost.
The real win is not the multi-agent capability itself. It is the reduction in system prompt size per agent. When each agent has 400 tokens of focused instructions instead of 4000 tokens trying to cover everything, behavior gets predictable. Output testing gets meaningful. Drift gets easier to catch.
What I would do with it this week
Pick one existing Copilot Studio agent that has grown too many topics. Look at the system prompt. If it is over 2000 tokens or covers more than two distinct domains, it is a candidate.
Split it. Create one child agent per domain. Move the relevant tools, knowledge sources, and instructions into the child. Write a clear description for each child, because that description is what the parent’s LLM uses to route. Vague descriptions kill routing accuracy faster than anything else. If you need to wire external capabilities into those child agents, building a custom connector for Copilot Studio is the practical path for connecting APIs that do not already have a prebuilt connector.
Then test the edges. Phrasings that sit between two children. Requests that should hit two children sequentially. Requests that should fail cleanly when no child fits. The supervisor pattern looks great on the happy path. The behavior at the edges is what tells you whether the split was worth it.
Multi-agent orchestration is not a silver bullet, it is a structural tool. Used right, it makes agents maintainable. Used wrong, it builds another silo with extra latency. The patterns matter more than the feature.
