ExamFinch.com My Study

Study guide

11.3 Integrate an Existing Copilot Studio Agent

Practice this exam

Microsoft Certified: AI Agent Builder Associate AB-620

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Candidate Profile & Prerequisites 1.3 Skills Map & Study Strategy

2 Plan Integration, Identity & Channels

2.1 Plan Integration with Enterprise Systems 2.2 Plan Identity Strategy 2.3 Plan Channels and Deployment

3 Responsible AI, Security & Reuse

3.1 Plan Responsible AI Strategy 3.2 Security and Governance Considerations 3.3 Plan Reusable Agent Components 3.4 Design Agents for Internal or External Audiences

4 Agent Flows Fundamentals

4.1 Create an Agent Flow 4.2 Human-in-the-Loop Agent Flows 4.3 Configure Actions and Connectors in Flows

5 Agent Flow Monitoring & Resilience

5.1 Monitor Agent Flows 5.2 Input and Output Parameters 5.3 Error Handling in Agent Flows

6 Topics Configuration Core

6.1 Add Agent Flows to a Topic 6.2 Configure Agent Response Formatting 6.3 Add Tools to a Topic

7 Advanced Topic Responses

7.1 Custom Prompts for Advanced Responses 7.2 Custom Knowledge Sources for Advanced Responses 7.3 API and Send HTTP Request Responses

8 Generative Answers, Cards & Variables

8.1 Configure the Generative Answers Node 8.2 Configure Adaptive Cards 8.3 Manage Variables

9 Enterprise Knowledge Sources

9.1 Connect to Copilot Connectors 9.2 Connect to Power Platform Connectors 9.3 Connect to Azure AI Search

10 Add Tools to Agents

10.1 Configure and Monitor Computer Use 10.2 Configure MCP Tools 10.3 Tools via Existing Custom Connectors 10.4 Add REST APIs to an Agent

11 Multi-Agent Collaboration

11.1 Design Multi-Agent Solutions 11.2 Integrate a Foundry Agent 11.3 Integrate an Existing Copilot Studio Agent

12 Fabric Data Agents & A2A

12.1 Integrate a Fabric Data Agent 12.2 Multi-Agent Solutions with A2A Protocol

13 Integrate Agents with Azure

13.1 Generative Answers with Azure AI Search & Foundry 13.2 Foundry Model Catalog for Custom Prompts 13.3 Monitor Agents with Application Insights

14 Evaluate Agent Performance

14.1 Create a Test Set 14.2 Choose an Evaluation Method 14.3 Review Test Results

15 Application Lifecycle Management

15.1 Create a Solution 15.2 Add Existing Agents to a Solution 15.3 Create and Use Environment Variables 15.4 Power Platform Pipelines for Agents

11.3 Integrate an Existing Copilot Studio Agent

Key Takeaways Explain This Topic AI

You can connect a published Copilot Studio agent in the same environment as a modular connected agent when the target allows connections and is shared with or owned by the maker.

On the main agent’s Agents page, Add an agent → Copilot Studio, select the published peer, refine the local description for routing, and optionally control whether conversation history is passed.

Target agents must enable Let other agents connect to and use this one; publishers must republish after changes because parents only use the latest published version.

Connected-agent descriptions are controlled locally on the parent—updates to the child agent’s own description do not auto-sync to every parent that connected it.

Reuse connected agents across multiple parents when the specialist is not itself a multi-connected hub; plan identity sharing for end users so runtime access succeeds.

Last updated: August 2026

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 :

  • Trait Existing Copilot Studio connected agent
  • Platform Copilot Studio ↔ Copilot Studio
  • Environment Must be the same environment as the main agent
  • Publish state Target must be published
  • Allow flag Target settings: Let other agents connect to and use this one
  • Access Maker is owner or the agent is shared with the maker
  • Runtime users Depending on auth, you may need to share the connected agent with end users of the main agent
  • Description at parent Local copy—does not auto-sync from the specialist’s own description updates
  • Versioning Parent uses latest published specialist after republish
  • Prerequisites checklist

Before connection, verify all four Microsoft requirements:

Same environment as the main agent.

Published (draft-only specialists will not be usable as connected agents for production handoff expectations).

Configured to allow connections from other agents.

Maker is owner or has the agent shared .

  • Failure symptom Likely missing prerequisite
  • Agent not listed Wrong environment, not published, allow flag off, or not shared with maker
  • Works for maker test, fails for users Connected agent not shared/accessible to end users under your auth model
  • Parent ignores new specialist behavior Specialist changes not published
  • Routing to wrong intents Local description never refined for this parent
  • Make a specialist available for connections

On the specialist agent:

Open Settings .

Ensure Let other agents connect to and use this one is on .

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

Open the main agent → Agents page → Add an agent .

Under Connect to an external agent , select Copilot Studio .

Choose the desired agent from available Copilot Studio agents. You will see the agent’s name, instructions, and description .

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.

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.

Complete add, then test handoff paths in the test pane (activity map should show the connected agent when intents match).

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

Option Behavior Use when

Pass conversation history (default mindset) Specialist sees prior context Multi-turn continuity matters; user already supplied IDs/names

Do not pass history Specialist mainly gets the explicit delegated task Minimize data sharing; reduce cross-domain leakage; task is self-contained

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.

  • Change type What you must do
  • Specialist tools/knowledge/instructions Publish specialist
  • Specialist’s self-description in its own settings Manually refresh local description on each parent if needed
  • Parent routing intent Edit local description / parent instructions; republish parent as needed
  • 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)

  • Question Child agent Connect existing CS agent
  • Need independent channel for the specialist? No Yes
  • Separate team + solution pipeline? Rarely Yes
  • Reuse across many orchestrators? No Yes (as a leaf)
  • Single intent subroutine only? Yes Optional
  • Same environment published peer already exists? N/A Prefer connect, don’t rebuild
  • 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

Trying to connect across different environments .

Connecting an unpublished agent and expecting production behavior.

Allow-connection toggle off .

Maker lacks share/owner rights.

End users lack access under auth model.

Assuming specialist description auto-syncs to parents.

Forgetting publish after specialist changes.

Rebuilding a working peer as a fat parent instead of connecting .

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.