2.3.2. Connecting Copilot Studio Agents
💡 First Principle: A connected Copilot Studio agent is recruited, not rebuilt — the parent learns what the specialist can do (its name and description), never how it does it. Delegation quality therefore rises and falls on how well the connected agent describes itself.
Wiring it up offers two complementary mechanisms. Under generative orchestration, you add the agent on the Agents page and the orchestrator considers it a routing target like any tool — selected whenever the user's goal matches its description. For deterministic control, a topic can redirect to the agent via an explicit node: input variables pass context in (when the target supports them), and the target's outputs surface as topic variables the parent can use downstream. Instructions can also reference an agent directly (typing "/" in the instructions editor), steering the orchestrator toward the specialist in defined situations.
Operationally, connected agents can be toggled on and off (the Enabled toggle) without disconnecting them — useful when a downstream team is mid-migration. Two behaviors catch builders by surprise and therefore make good exam fodder: citations attached to a connected agent's answer may not survive the trip back to the parent's response, and the connected agent respects the parent's general-knowledge setting during delegated work, keeping the solution's grounding posture consistent.
⚠️ Exam Trap: Passing context matters. If a scenario requires the specialist to receive the order number collected earlier in conversation, the topic-redirect path with input variables is the reliable mechanism — orchestrator-mediated delegation doesn't guarantee specific variables transfer.
Reflection Question: Your IT specialist agent answers perfectly when tested alone but is never chosen by the parent's orchestrator. Reasoning from how delegation targets are selected, what do you fix first — and why is it not the specialist's tools?
