Integrate and extend agents in Copilot Studio

A team asks for one agent that answers questions from ten years of service tickets and also opens a new ticket when the answer turns out to be "you need one". Those are two different integrations, and picking a single mechanism for both is the most reliably wrong answer in this domain. Copilot Studio gives an agent three ways to reach something outside itself, and what decides between them is what the far side is, not which system happens to hold the data: content that should ground an answer attaches as a knowledge source, an operation that changes a record or returns a value that is true at this instant attaches as a tool, and a system that runs its own reasoning over the request attaches as an agent. Underneath all three sits the fourth thing this domain owns, model and telemetry: which model actually executes a prompt, and what you can see once the conversation ends. The trap runs in both directions, and the exam sets it often, so watch for indexing a transactional system and expecting a grounded answer to write to it, or uploading an API's documentation as knowledge and expecting its endpoints to become callable.

Knowledge comes first, as three routes to a grounded sentence. Connect to Copilot connectors is the indexed path: a tenant administrator indexes external content into Microsoft Graph through a synced connector and the agent grounds on that copy, carrying citations and the source's own permissions with it. Connect to Microsoft Power Platform connectors is the live path, where one connection serves two uses, a knowledge use that indexes only table and column names and queries the source at request time, and an action use that exposes the same connection's operations as tools. Freshness is not the divider between knowledge and tools: the live path is current and still only grounds an answer. Connect to Azure AI Search attaches a vector index you already own through a search data connection, the second indexed route because its index is built on the Azure side first, and it introduces the seam that runs through the rest of the domain: an Azure side that has to be prepared first, and a Copilot Studio side that can only consume what the Azure side already supports.

Tools come second, ordered from the far side that publishes least to the one that publishes most. Configure and monitor computer use for an agent is what you reach for when a system publishes no contract at all and the only way in is its user interface. Configure MCP tools connects one Model Context Protocol (MCP) server whose tools and resources the agent discovers from server-owned metadata, so a single entry on the Tools page carries many. Add a tool by using an existing custom connector consumes one operation of a contract your organization already published. Add REST APIs to an agent is the do-it-yourself end of the same idea: you supply an OpenAPI specification and choose which API operations become tools.

Agents come third. Design multi-agent solutions in Copilot Studio is the decision page, where the lifecycle boundary chooses between a child agent that lives inside your main agent and a separately published connected agent. The four pages after it are the connection options, one per kind of far side: Integrate a Foundry agent for a reasoning agent that stays in Microsoft Foundry, Integrate an existing agent in Copilot Studio for a published agent in the same environment, Integrate a Fabric data agent for governed read-only analysis of structured business data, and Create a multi-agent solution by using A2A protocol for an agent hosted on another framework entirely, reached over Agent2Agent (A2A).

The last step goes underneath the other three. Configure generative answers by using Azure AI Search with Foundry returns to knowledge with a second and non-interchangeable route to the same grounded sentence, wired on a generative answers node's own Classic data option (the Classic data route) rather than added as an agent-level knowledge source. Configure custom prompts to use the Foundry model catalog changes which model executes one prompt, and nothing else about the agent; its connector is named Azure AI Foundry, not Microsoft Foundry. Monitor agents by using Application Insights makes the whole assembly observable, exporting message, event and node-execution telemetry to a resource you own in Azure.

Almost nothing in this domain is configured in Copilot Studio alone. A Copilot connector has to be set up by a tenant administrator before a maker can even select it, an Azure AI Search index has to be built the way Copilot Studio can consume it before the connection is added, a Copilot Studio agent has to be published and allow inbound connections before another agent can connect to it, and a Fabric data agent has to be published in Fabric. When two answers both look plausible, the one that inspects the far side is usually right, because the near side rarely raises an error when the far side is the problem: an unauthorized user gets an answer that behaves as though the content does not exist, and a source whose status has not reached Ready is simply not ready to be tested. On the Copilot Studio side, three switches recur on almost every page here and are worth checking in this order: generative orchestration, which is what lets the agent choose a computer use tool, an MCP tool or another agent from its description at all; the routing description, which is a runtime interface the orchestrator reads rather than documentation for humans; and the credential mode, End user credentials or Maker-provided credentials, which decides whose access the call actually runs with.