Connected Agents in Microsoft 365 Copilot - Making Your Declarative Agents Talk to Each Other

Here is a pattern I keep seeing in Australian organisations that have started building Copilot agents. Someone in HR builds a leave policy agent. Someone in IT builds a service desk agent. Finance builds one for expense queries. Each one works fine on its own. Then an employee asks the HR agent "can I get a new laptop while I'm on parental leave" and the agent falls flat, because half the answer lives in another team's agent.

The traditional fix was to build one giant agent that knows everything. That approach collapses under its own weight pretty quickly. The instructions get long and contradictory, the knowledge sources multiply, and the agent starts giving confidently wrong answers because it is trying to be an expert in six domains at once.

Microsoft's answer to this is connected agents. A declarative agent in Microsoft 365 Copilot can now hand off parts of a conversation to other agents in your organisation. The HR agent stays an HR expert, but when the laptop question comes up, it can route that piece to the IT agent and bring the answer back. Microsoft documents the mechanics in their Copilot extensibility docs, and having now built a few of these for clients, I want to share what the docs don't tell you.

What connected agents actually are

A declarative agent is the lightweight kind of Copilot agent. You define its name, its instructions, its knowledge sources, and the capabilities it can use. No custom orchestration code, no hosting. Microsoft 365 Copilot's own orchestrator runs the show.

Connected agents extend that model. When you build your agent, you can nominate other agents as connections. You give each connection a description that explains what that agent is good at. At runtime, when the orchestrator decides the user's request matches one of those descriptions better than the parent agent's own capabilities, it routes the request across. The connected agent does its work, and the response comes back through the parent.

The thing I like about this design is that the routing decision is driven by plain language descriptions, the same way tool selection works. You are not writing routing logic. You are writing a good job description for each connected agent, and the orchestrator does the matching.

The thing I like less is the same fact viewed from the other side. Because routing is description-driven, vague descriptions produce vague routing. If your IT agent's connection description says "helps with IT stuff", you will get misrouted questions, missed handoffs, and users who lose trust in the whole setup. More on that below.

Why this matters more in Australia than you might think

Australian mid-market companies tend to run lean IT teams. The pattern we see at Team 400 is that agent building gets distributed fast - the business units want their own agents and they want them now, and IT cannot build them all centrally. Within six months you have a dozen agents scattered across departments, built by different people, with overlapping knowledge and no coordination.

Connected agents are the first real mechanism for stitching that sprawl into something coherent without a rewrite. You keep the departmental ownership, which the business units like, and you add a routing layer on top, which the users need. One front door, many specialists behind it.

We have used this with a professional services client who had separate agents for engagement letters, timesheets, and resourcing policy. Staff hated guessing which agent to ask. We built a single "firm assistant" declarative agent whose main job is to be the receptionist - it answers the simple stuff itself and connects out to the three specialist agents for everything else. Adoption went up noticeably, not because any individual agent got smarter, but because people stopped having to think about which one to open.

Building one - the parts that need actual thought

The setup itself is not hard. In Copilot Studio or the Microsoft 365 Agents Toolkit you add connections to your declarative agent, pick the agents to connect, and write the descriptions. A competent developer can wire it up in an afternoon. Here is where the real effort goes.

The connection descriptions are the product. I said it above but it deserves its own paragraph. The description you write for each connected agent is what the orchestrator uses to decide when to hand off. Treat it like you would treat a tool description in any agent framework. Be specific about what the agent covers, and just as specific about what it does not. "Answers questions about IT hardware requests, laptop and phone provisioning, and software licence approvals. Does not handle password resets or outage reports" routes far better than a one-liner. Test it with the awkward questions, the ones that sit on the boundary between two agents, because that boundary is where users actually live.

Each connected agent has to stand on its own. The parent agent passes the request across, but the connected agent answers with its own instructions, its own knowledge, and its own permissions. If the IT agent gives mediocre answers when used directly, it will give mediocre answers through a connection too. Connecting agents together does not average out their quality. It exposes the weakest one to a bigger audience.

Permissions do not magically blend. The user's identity flows through, which is the right design, but it means a user who lacks access to the connected agent's underlying knowledge will get a different experience than one who has it. Map this out before launch. The worst version of this is an exec asking a question, getting a thin answer because of a permissions gap, and concluding the whole agent program is rubbish.

Decide who owns the seams. When the HR agent hands off to the IT agent and the combined answer is wrong, whose problem is it? In a single-agent world that question never comes up. In a connected world it comes up in the first week. Agree on ownership of the routing layer before you ship, not after the first incident.

Where it still feels rough

I will be honest about the current state of this feature, because the marketing makes it sound more finished than it is.

Routing is good but not perfect. Ambiguous questions sometimes stay with the parent agent when they should have been handed off, and occasionally the reverse. You can tune this with better descriptions and better parent instructions, but you cannot eliminate it. Budget time for a tuning cycle after launch with real user questions, not just your test script.

The user experience around handoffs is still maturing. Users do not always have a clear sense of which agent produced which part of the answer, which matters when they want to follow up or challenge something. For internal tools this is usually tolerable. For anything customer-facing, think harder.

Debugging multi-agent conversations is harder than debugging one agent. When an answer is wrong, you now have to work out whether the routing was wrong, the connected agent was wrong, or the parent mangled the response on the way back. Good test coverage of the routing layer pays for itself quickly here.

And there are practical limits on how many agents you can connect and how deep the chains can go. Check the current numbers in the documentation before you design an elaborate hub-and-spoke architecture, because the limits have shifted as the feature has matured and your design needs to fit inside whatever they are this quarter.

When not to use connected agents

If you have two or three closely related knowledge areas, just build one agent with all of them. Connected agents add a routing hop, a tuning burden, and an ownership question. None of that is free. The pattern earns its keep when the domains are genuinely separate, owned by different teams, or large enough that a single agent's instructions would become a mess.

Also be wary of using connections to paper over a content problem. If your underlying SharePoint documentation is contradictory and stale, splitting it across five agents and connecting them does not fix anything. It distributes the problem. Fix the content first. This is unglamorous advice and clients never love hearing it, but it is where most agent quality problems actually come from.

Getting started

If you are already running declarative agents, the on-ramp is gentle. Pick two agents that users frequently confuse, build a simple front-door agent that connects to both, and run it with a pilot group for a month. You will learn more from that than from any architecture diagram.

If you are earlier in the journey, get the individual agents right first. We help organisations with both stages - our Copilot Studio consulting work covers agent design and the routing layer, and our Microsoft AI consultants handle the broader question of which agents are worth building in the first place. For teams that want to build the capability in-house, our Copilot training covers declarative agents end to end.

My take overall - connected agents are the right architectural direction, and Microsoft has built the right primitive. The orchestration is description-driven rather than code-driven, which keeps it accessible to the people who actually own the business knowledge. It is not yet effortless, and the tuning work is real. But if your organisation already has agent sprawl, and most do by now, this is the cleanest path to making it feel like one assistant instead of a dozen.

Reference: Microsoft Learn - Connect to other agents