11.3 Integrate an Existing Copilot Studio Agent

11.3 Integrate an Existing Copilot Studio Agent

Quick Answer: Connect a published peer agent in the same environment that allows connections and is owned by or shared with you. On Agents → Add an agent → Copilot Studio, pick the agent, tune the local description, choose whether to pass conversation history, then test. Republish specialists after changes; parents consume the latest published version.

AB-620 measures Integrate an existing agent in Copilot Studio—the modular reuse pattern that turns successful single-purpose agents into connected specialists for orchestrators. Microsoft docs title this Connect to an existing Copilot Studio agent. This is how enterprises avoid rebuilding HR, IT, or finance bots inside every parent.

Mental model: same product, separate agent lifecycle

Unlike child agents (inline inside one agent) and unlike Foundry (external platform), this pattern links two first-class Copilot Studio agents:

Prerequisites checklist

Before connection, verify all four Microsoft requirements:

1. Same environment as the main agent.
2. Published (draft-only specialists will not be usable as connected agents for production handoff expectations).
3. Configured to allow connections from other agents.
4. Maker is owner or has the agent shared.

Make a specialist available for connections

On the specialist agent:

1. Open Settings.
2. Ensure Let other agents connect to and use this one is on.
3. To prevent connections, turn it off (hard stop for new modular reuse).

Microsoft notes that by default any agent can connect to another agent in the same environment when allowed—still treat the toggle as an intentional governance control in exam scenarios about lockdown.

Connect steps on the main agent

1. Open the main agent → Agents page → Add an agent.
2. Under Connect to an external agent, select Copilot Studio.
3. Choose the desired agent from available Copilot Studio agents. You will see the agent’s name, instructions, and description.
4. Adjust the description to be more contextual for this main agent. Make it more specific when other tools or agents might overlap so orchestration knows when to invoke the second agent.
5. Optionally clear Pass conversation history to this agent if you want to limit shared context to the explicit task the main agent assigns—not the full prior conversation.
6. Complete add, then test handoff paths in the test pane (activity map should show the connected agent when intents match).
7. Optionally reference the agent from parent Instructions with / for autonomous patterns, or redirect from a topic when the business process always requires that specialist.

Conversation history: pass vs task-only

Exam trap: Privacy-sensitive designs may intentionally clear history pass-through even though default convenience favors passing history. Choose based on data minimization and domain separation, not habit.

Local description ownership (critical)

Microsoft is explicit:

• Once connected, you control the specialist’s description locally on the parent.
• Updates to the connected agent’s own description do not automatically sync to your main agent.
• You must manually update the local description to reflect changes or further differentiate routing.

Also: if you change the connected agent’s behavior, publish those changes. The main agent can only use the latest published version after publish.

Modular reuse and ALM

Connected existing agents are the primary answer when exam stems say:

• “Reuse the existing IT support agent inside a new employee onboarding orchestrator.”
• “HR and Facilities teams own separate agents with independent solution pipelines.”
• “Users can talk to the payroll agent directly and through a corporate assistant.”

Independent ALM benefits:

• Specialist teams ship on their cadence.
• Parents pin to published contracts via description + expected capabilities.
• Blast radius of a bad publish is limited if parents can disable or disconnect a specialist.

Enable, disconnect, and lifecycle

On the main agent’s Agents page:

• Enabled toggle — temporarily make a connected agent inactive (no user/trigger response) without full removal.
• Disconnect agent — remove the connection from this parent.
• Child agents use Delete; connected agents use Disconnect (know the vocabulary).

Known multi-agent constraints that affect reuse design

From the add-other-agents overview, remember design limits that show up next to this skill:

• If an agent is used as a main agent with connected agents, you generally cannot also use that same agent as a connected agent for a second main agent.
• Agents without connected agents can typically be reused as connected specialists in multiple main agents.
• Plan topology: prefer leaf specialists for wide reuse; avoid making every agent a multi-connected hub if you need many parents.

Citations may not always be fully maintained when outputs pass back through parents—design answer quality tests accordingly.

Child agent vs connected existing agent (decision table)

Realistic scenarios

Scenario A — Modular reuse done right. Contoso already published IT Helpdesk Agent with ServiceNow tools. The new Employee Concierge orchestrator connects that agent, rewrites the local description to “Handles device, VPN, and access issues using IT Helpdesk capabilities—do not use for payroll or benefits,” leaves history pass-on for ticket continuity, and shares the IT agent with employees who use Concierge. IT continues independent ALM; Concierge only updates local description when routing drifts.

Scenario B — Publish lag. HR updates knowledge in Benefits Agent but forgets to publish. Concierge still routes correctly but answers reflect the old published specialist. Exam answer: publish the connected agent; not “restart Teams.”

Scenario C — Description drift. Benefits Agent authors improve their global description, but Concierge still has a year-old local description that overlaps with Payroll Agent. Routing breaks. Fix is local description maintenance on the parent—not only specialist-side edits.

Scenario D — History minimization. Legal wants the Investigations specialist to receive only the delegated task text, not the full employee chat. Makers clear Pass conversation history to this agent and put required case IDs into the delegated task payload/instructions.

Pitfalls

1. Trying to connect across different environments.
2. Connecting an unpublished agent and expecting production behavior.
3. Allow-connection toggle off.
4. Maker lacks share/owner rights.
5. End users lack access under auth model.
6. Assuming specialist description auto-syncs to parents.
7. Forgetting publish after specialist changes.
8. Rebuilding a working peer as a fat parent instead of connecting.
9. Using a multi-connected hub as a reusable leaf when platform limits block second-parent patterns.

Success checklist

• List the four connection prerequisites cold.
• Configure allow other agents to connect on specialists.
• Perform Add agent → Copilot Studio and refine local description.
• Explain history pass-through trade-offs.
• Tie publish and non-syncing descriptions to operational runbooks.
• Prefer connect existing for modular reuse and independent ALM over cloning logic into one mega-agent.

Master this leaf and you can defend multi-agent modular reuse on AB-620: not every specialist is Foundry, not every subroutine is a child agent—often the best specialist is an existing published Copilot Studio agent you connect with care.