Extending Microsoft 365 Copilot with Microsoft Copilot Studio

Posted on April 7, 2026 by Imran Rashid

Reading Time: 31 minutes

In this blog post, I’ll explore why and how to extend Microsoft 365 Copilot with Microsoft Copilot Studio using declarative agents.

Microsoft 365 Copilot is already a powerful AI assistant that uses large language models (LLMs) and integrates with your data in the Microsoft Graph and Microsoft 365 apps and services. It’s designed to help users stay productive across the familiar Microsoft 365 experiences they use every day. However, out of the box, Microsoft 365 Copilot is designed to support a broad range of scenarios. Rather than being a single, standalone experience, it appears across multiple Microsoft 365 surfaces. You can access Microsoft 365 Copilot through several entry points, including:

Copilot in Loop
Microsoft 365 Copilot Chat – a central place where users can ask questions and reason over information across their organisation. Copilot Chat is grounded in Microsoft Graph and only has access to the data that the signed‑in user already has permission to access. Under the hood, Copilot uses an intelligence layer (often referred to as Work IQ) to understand context, relationships, and work patterns across your organisation, enabling more relevant and personalised responses.
Copilot in Outlook
Copilot in Teams
Copilot in Word
Copilot in PowerPoint
Copilot in Excel
Copilot in Whiteboard
Copilot in OneNote

Using Microsoft 365 Copilot, organisations benefit from integration with their Microsoft 365 data, such as, SharePoint, email, OneDrive, Word files and more.

Microsoft 365 Copilot isn’t a single, standalone app; rather, it’s a collection of intelligent capabilities built directly into Microsoft 365 applications. These capabilities are powered by Microsoft Graph, an orchestration service, large language models (LLMs), and Work IQ, all working together to deliver context-aware assistance.

Microsoft Graph and Work IQ: How Copilot understands your work

Microsoft Graph is the foundation that gives Microsoft 365 Copilot access to your organisation’s data. It securely connects information from across Microsoft 365, such as emails, files, meetings, chats, and calendars. It understands how this information relates to people, teams, and projects. This allows Copilot to find the right information at the right time, while always respecting your existing permissions and security controls.

Work IQ builds on top of Microsoft Graph and focuses on understanding how work actually happens. Instead of treating emails, documents, meetings, and chats as separate items, Work IQ looks at patterns across your daily work, such as, who you collaborate with, what you’re working on, and how information flows through the organisation. Over time, this creates a shared work memory that helps Copilot provide more relevant, personalised responses without you needing to explain context every time.

Together, Microsoft Graph and Work IQ allow Copilot to move beyond simple search. Copilot can understand intent, not just keywords. For example, if you ask about “project delivery status,” Copilot can surface a document titled “Team Milestone Update” even if the wording doesn’t exactly match. If a manager asks for “team updates”, Copilot can understand who the people in the team are and pull together the most relevant recent activity.

The result is an experience where Copilot feels aware of your role, your work, and your organisation, delivering answers and suggestions that are grounded in real data, meaningful context, and the way you actually work.

The below diagram demonstrates how Copilot works under the hood.

As shown in the diagram above, Microsoft 365 Copilot has access to Microsoft 365 data through Microsoft Graph. This includes content such as emails, files, meetings, chats, and calendar data that users already have permission to access. However, many organisations rely on business-critical data that lives outside Microsoft 365. This raises an important question: how can Copilot work with third‑party systems such as Jira, ServiceNow, and other applications used daily across the organisation? In the remainder of this blog post, we’ll explore the options available for extending Microsoft 365 Copilot so it can incorporate and reason over both Microsoft 365 data and third‑party data.

As organisations look to apply Copilot to specific business processes, domains, or knowledge areas, the ability to extend and tailor Copilot becomes essential. One of the primary ways Microsoft enables this is through declarative agents. Before we continue, it’s important to first understand what declarative agents are and the role they play in extending Microsoft 365 Copilot.

What are Declarative Agents?

Declarative agents, also known as Copilot agents, extend the capabilities of Microsoft 365 Copilot. These agents use the same orchestrator and models as Microsoft 365 Copilot. By reusing the existing infrastructure and controls, they provide a consistent experience for end users, as shown in the image above, but are scoped to specific business needs or scenarios.

These agents act as subject matter experts by using defined instructions, knowledge, and actions, while still running inside the familiar Microsoft 365 Copilot chat experience. This allows users to interact through the same Copilot interface.

If you require custom orchestration or the use of a different large language model, a declarative agent isn’t suitable; in that case, you should consider building a custom agent instead.

Declarative agents work best when the information relevant to your scenario is already available within Microsoft 365. If you need to ingest data from an external system into Microsoft 365, you can use a Copilot connector. If you need to interact with external systems in real time, you can expose those systems through custom actions; however, the agent will still rely on Microsoft 365 Copilot’s built‑in orchestration.

Do I really need to create an agent?

These agents act as subject‑matter experts by using defined instructions, knowledge, and actions, while still running inside the familiar Microsoft 365 Copilot chat experience. This allows users to interact with them through the same Copilot interface.

If you require custom orchestration or the use of a different large language model, a declarative agent isn’t suitable; in that case, you should consider building a custom agent instead.

To understand this in more detail, it’s helpful to look at the two types of Copilot connectors available today: synced connectors and federated connectors.

Copilot Connectors: Synced vs Federated (Live)

Microsoft 365 Copilot supports two connector models for bringing third party data into Copilot experiences.

Synced connectors ingest external content into Microsoft Graph, where it is indexed and added to the semantic index. This allows Copilot to search and reason over that content in the same way it would with native Microsoft 365 data.

In contrast, federated connectors retrieve information in real time using Model Context Protocol (MCP) and do not index content into Microsoft Graph. This makes federated connectors useful for sensitive or fast changing data, while synced connectors are usually better for large knowledge bases where you want broad discovery and consistent answers across Copilot.

Note: Federated connectors are currently available in early access preview and may not appear in all Microsoft 365 tenants, depending on release ring and licensing.

Why would you want to extend Microsoft 365 Copilot?
As shown in the diagram above, Microsoft 365 Copilot has access to a number of your files by default and can reason over this data. However, it doesn’t have access to everything. Microsoft 365 Copilot does not have access by default to the rest of your organisational data, such as line‑of‑business applications like Salesforce, SAP, Jira, ServiceNow, and others. This is because Microsoft 365 Copilot Chat is primarily grounded in data available through Microsoft Graph, including Word, PowerPoint, email, SharePoint content, Teams conversations, and files stored in OneDrive.

Microsoft 365 Copilot supports multiple ways of bringing third‑party data into Copilot experiences. One approach is synced connectors, which ingest external data into Microsoft Graph and make it available through semantic indexing. Another approach is federated connectors, which retrieve data in real time without indexing it into Microsoft Graph. At the time of writing this post, federated connectors are available in.

However, we won’t be using either synced or federated connectors as we continue through this post.

Instead, we’ll focus on a declarative agent approach, where knowledge and connectors are added directly to the agent and scoped specifically to that agent. This method is commonly used when integrating systems such as ServiceNow, Jira, Monday.com, and more, where the agent retrieves or interacts with data at runtime under the user’s permissions, without making that data tenant‑wide or indexing it into Microsoft Graph.

This approach allows Copilot to reason over the information relevant to a specific business scenario, while keeping the knowledge controlled, targeted, and scoped to the agent itself.

How Copilot Understands Knowledge from External Systems

When you connect Microsoft 365 Copilot to external systems such as Salesforce, ServiceNow, or Confluence, simply retrieving data is not enough. Copilot needs to understand what that information means.

Traditional keyword‑based search looks for exact words or phrases. For example, if you searched for “holiday allowance policy”, you might miss a document titled “Annual Leave Guidelines” because the wording does not match exactly.

The semantic search built into Microsoft 365 Copilot works differently. Instead of relying only on keywords, it understands the meaning and context behind a question. This allows Copilot to surface relevant information even if the wording does not match.

For example:

User asks:
“What’s the policy for booking time off?”

Copilot might retrieve information from a document titled:
“Annual Leave Request Procedure”

even though the words “time off” were never used in the document.

In many scenarios, the knowledge required by Copilot may already exist within Microsoft 365, such as documents stored in SharePoint sites.

Scenario we will build:

Employees across your organisation regularly need to refer to internal policies and procedures to complete everyday tasks. These documents are stored in a SharePoint Online site, such as expense policies, dress code policy, onboarding guides, sick leave, return to work, training and flexible working policies and more. However, searching through multiple documents can be time consuming.

You want to create a declarative agent that allows users to ask questions in natural language and receive accurate answers based on the documentation stored within SharePoint.

Now that you have an idea of what declarative agents are, let’s build a declarative agent based on this scenario. We will also explore agent options as we go through the demo.

Create a declarative agent built specifically for Microsoft 365 Copilot

Prerequisites:
To follow along and build declarative agents that run inside Microsoft 365 Copilot using Copilot Studio, you must have a Microsoft 365 Copilot licence.

If you don’t have a Microsoft 365 Copilot licence, you can still build agents in Copilot Studio using a Copilot Studio Trial or pay‑as‑you‑go (Copilot Credits). However, without a Microsoft 365 Copilot licence, you won’t be able to run or test the agent within the Microsoft 365 Copilot experience demonstrated in this post.

Note: If you plan to run declarative agents at scale, enable actions, or publish agents beyond basic internal usage, it’s worth reviewing how Copilot Studio usage is measured and managed using Copilot Credits. For more details, see Billing rates and management in Microsoft Copilot Studio.

Visit https://copilotstudio.microsoft.com
Click agents

3. Select Microsoft 365 Copilot

4. Select Add or New Agent (label may vary depending on tenant and release)

5. Configure the agent:
– Agent language: English
– Agent name: Policy Advisor
– Agent image: Upload a custom image (optional but recommended)

6. Description – Use your own words to describe what your agent should help with, including the target audience and end goal.

Note: The description helps Microsoft 365 Copilot identify when your agent is relevant for a specific task or situation. Keep it short, precise, and simple. This description will also be made visible to users when they start to make use of your agent. Character limit at the time of writing this post: 1,000 characters.

Description
The Policy Advisor helps employees quickly find clear, accurate answers to Contoso Ltd. policies and procedures. Ask natural language questions about onboarding, benefits, leave, remote work, training, conduct, and more.

7. Instructions – below

Note: These instructions define how the agent should behave when extending Microsoft 365 Copilot. They control what the agent does, how it responds, and the boundaries it must follow. You can update and refine these instructions later as you test the agent. These instructions are not visible to end users.

Your goal is to make policies easy to understand, easy to navigate, and less intimidating.

You are Policy Advisor, an employee facing assistant for Contoso Ltd.

Your role is to help employees understand internal policies, procedures, and guidelines based only on the documents provided in SharePoint. These include, but are not limited to, onboarding guides, workplace policies, code of conduct, benefits, training requirements, remote working, career progression, and wellbeing resources.

How you should respond

Answer questions clearly, calmly, and professionally
Use plain, friendly language suitable for all employees
Be supportive and reassuring, especially for new starters
Summarise policies in an easy‑to‑understand way rather than repeating them word for word
If appropriate, explain what employees can expect, do next, or who to contact

Grounding and accuracy

Only answer based on the content available in the connected SharePoint documents
Do not guess, invent, or assume information
If the answer is not clearly covered in the documents, say so politely and suggest contacting HR or a manager. Do not make information up if it’s not documented.

Boundaries

Do not provide legal advice
Do not make decisions or approvals on behalf of Contoso Ltd.
Do not speculate about disciplinary outcomes
Never assist with any other queries unless they are related to internal contoso policies. You are strictly a policy advisor and that is it.

Tone and behaviour

Be inclusive, neutral, and non‑judgmental
Encourage employees to ask questions
Reinforce that policies exist to support employees, not catch them out

When unsure

Clearly state that the information may vary by role or location
Recommend speaking with HR or a manager for confirmation

8. Click to Add suggested prompts. When done, click save.

I’ll be adding the starter prompts below.

Note: Suggested prompts are predefined example questions or actions that appear when a user opens a Copilot agent. They act as conversation starters and show users what the agent is capable of, especially when they don’t yet know what to ask.

Title: First day at Contoso
Prompt: What should I expect on my first day at Contoso Ltd?

Title: Mandatory training
Prompt: What mandatory training do I need to complete and by when?

Title: Remote or hybrid working
Prompt: How does remote or hybrid working work at Contoso?

Title: Booking time off
Prompt: How do I book annual leave or time off at Contoso?

Title: Dress code
Prompt: What is the dress code at Contoso, including for remote work?

9. Click Create. I’ll configure the agent further shortly.

10. Let’s test the agent. Click the Test button located at the top right, next to the Publish button, as shown in the image below.

The test pane is a great way to test your agent, fine‑tune its behaviour, and test again.

11. In the test pane, the agent name and the icon you uploaded earlier appear, along with some of the starter prompts.

I’ll click the Mandatory training prompt. This is one of the suggested prompts created earlier and acts as a conversation starter in case users are unsure what to ask the agent.

The response from the agent indicates that it was unable to locate any relevant information.

This is expected behaviour at this stage. The agent does not yet have access to any knowledge sources, and it is not allowed to search the internet. At the moment, the agent can only respond based on the instructions provided, but no supporting content has been connected.

The policy documents the agent needs to answer these questions are stored in SharePoint, and we haven’t connected that SharePoint data to the agent yet. In the next step, we’ll add the required SharePoint content as a knowledge source so the agent can start answering questions accurately.

12. Note about web search

Copilot Studio also provides an option to enable web search, as shown in the diagram below.

For this scenario, web search remains disabled. The Policy Advisor agent is designed to answer questions based only on approved internal policy documents stored in SharePoint. Enabling web search could result in answers being grounded in public web content, which is not appropriate for an internal policy advisor.

Clear instructions help guide the agent’s behaviour, but best practice is to control grounding by enabling only the knowledge sources you intend the agent to use.

Before adding a knowledge source, let’s do some further testing to validate the agent’s behaviour and boundaries.

At this stage, the agent is operating only on the instructions we defined earlier, without access to any internal knowledge sources. This allows us to confirm that the agent responds appropriately to questions that fall outside its intended scope.

13. Click the + icon visible under the Publish button to start a new conversation

14. Let’s try a different prompt to test the agent’s boundaries.

I’ll ask the agent:

“Can you recommend a 22‑inch Dell monitor under £500?”

The agent is not able to help with this request. This is expected behaviour.

Although Copilot Studio provides an option to enable web search, web search remains disabled for this scenario. More importantly, the instructions provided earlier clearly define the agent’s role as a Policy Advisor for Contoso Ltd.

The agent is designed to answer employee questions about internal policies and procedures only. Recommending products or equipment falls outside that scope.

I’ll try another prompt:

“Can you recommend a desk for my home office

Again, the agent correctly explains that it cannot help with this request. This confirms that the instructions and boundaries are working as intended.

15. So what next? let’s add my SharePoint URL including all my policy documents.

When you build an agent in Copilot Studio, you’re not technically training the AI in the traditional sense.
Instead, you’re connecting it to trusted information sources that it can search when responding to users. This is done using the Add Knowledge feature.

Think of this as:

“Where should my agent look to find answers?”

When you select Add Knowledge, Copilot Studio allows you to connect your agent to different data sources across your organisation (or public web content). These are grouped under the Featured and Advanced tabs as I will demonstrate next.

Click Add knowledge

You’ll find that there are additional knowledge source options available.

Public websites
This allows your agent to answer questions using information from selected public websites, such as a company website or publicly available documentation.

Note: By default, Copilot Studio uses generative orchestration, which allows you to add up to 25 public website URLs per agent when using Public websites as a knowledge source. Generative orchestration is enabled automatically for new agents, but you can switch to classic orchestration if required. It’s important to note that classic orchestration supports fewer public website URLs and is typically used for more narrowly scoped or legacy scenarios.

SharePoint:
This allows your agent to retrieve answers from documents stored in SharePoint sites, including:

Word documents
PDFs
Policy documents
Standard Operating Procedures
Internal guidance documentation

For SharePoint content, Copilot Studio uses Microsoft Graph and semantic search to retrieve relevant sections from documents in response to user questions. If this sounds familiar, that’s because we covered semantic search earlier in this post when explaining how Copilot understands and retrieves relevant information from connected data sources.

Dataverse:
Microsoft Dataverse is the secure data platform for Power Platform. It’s used to store and manage structured business data, such as customers, requests, or records, in a way that apps, automations, and Copilot agents can reliably read from and write to.

Data in Dataverse is stored in tables, similar to Excel tables, with rows and columns that represent business information. Dataverse includes built‑in tables for common business scenarios and also allows you to create custom tables tailored to your organisation’s needs.

Dataverse provides important capabilities such as security, relationships, business rules, validation, and auditing, which help ensure data remains consistent and trustworthy, regardless of which app, flow, or agent accesses it. For example, you can track changes to data, including who made the change and the previous and new values.

In Copilot Studio, Dataverse is typically used when an agent needs to work with structured business data, such as creating or updating records, tracking requests, or retrieving information in a consistent format.

If you already use another data source, such as SharePoint, Excel, or an external database, you can connect to those using connectors. However, if you need a native data source built into Power Platform, Dataverse is a good choice because it supports relationships between tables, rich security controls, and scalability without manual infrastructure management.

Dataverse integrates with Microsoft Entra ID (Microsoft’s Cloud Identity and Access Management Solution), allowing admins to control who can read, write, or modify data. It works across all Power Platform services, including Power Apps, Power Automate, and Copilot Studio.

Dynamics 365
When you add Dynamics 365 as knowledge, you’re allowing your Copilot agent to retrieve information directly from live CRM (Customer Relationship Management) or operational system used by these applications. Instead of answering questions based on documents, your agent can answer questions based on, customer case history, order records, account data, sales opportunities and more.

For example, an organisation uses Dynamics 365 Customer Service. A user asks, “What’s the latest update on my support case?”. The agent retrieves the relevant case record, including the latest status update and assigned support engineer, and then returns a real‑time response.

Under the hood, Dynamics 365 applications store their data in Microsoft Dataverse, so access to Dynamics 365 data in Copilot Studio is provided through Dataverse with the appropriate permissions applied.

Under the Advanced tab in Add knowledge, another option is available: Bing Custom Search.

Bing Custom Search:
Bing Custom Search allows you to control how your Copilot Studio agent retrieves information from the internet by limiting it to search only trusted public websites that that you explicitly approve. Rather than performing a broad web‑wide search, the agent uses Bing to retrieve information only from the domains, sub‑paths, or individual webpages you configure.

When a user asks a question, Copilot Studio generates an optimised search query and sends it to Bing Custom Search. The response is then grounded only in content from your approved sources, helping ensure accuracy and governance.

When adding websites directly using the Public websites knowledge option, there are platform limits:

In classic orchestration, you can add up to 4 public website URLs
In generative orchestration (enabled by default), this increases to 25 public website URLs

Bing Custom Search is useful when knowledge is spread across many trusted external domains, as it allows you to manage significantly more approved sources within a single custom search configuration, rather than adding each URL individually in Copilot Studio. A single Bing Custom Search instance can include up to 400 configured web slices, such as domains, sub‑paths, or individual pages.

To use Bing Custom Search, you first create a custom search instance by visiting https://customsearch.ai
and signing in with a Microsoft account (for example, @hotmail @outlook or another Microsoft backed account). After adding and publishing your approved websites, you copy the Custom Configuration ID from the Production tab and paste it into Copilot Studio when adding Bing Custom Search as a knowledge source.

Summary:

SharePoint = Internal documents such as policies, PDFs, or Word files.
Dataverse = Structured business data stored in tables (for example employee records or support cases)
Dynamics 365 = Business applications (such as CRM systems) that store ana manage their data in Dataverse
Public Websites = Specific websites your agent is allowed to access
Bing Custom Search = A controlled search across multiple approved websites. A controlled search across multiple approved websites

Important clarification: “Add knowledge” vs “Copilot connectors”

The Add knowledge options in Copilot Studio refer to knowledge sources that an individual agent can use to ground its generative answers. These sources are configured directly within Copilot Studio and define where the agent is allowed to look for information when responding to users. Examples include SharePoint, Dataverse, Public websites, and Bing Custom Search.

Microsoft 365 Copilot connectors (such as Synced or Federated connectors) which I briefly mention earlier are a separate capability. They are used to extend Microsoft 365 Copilot and Microsoft Search across Microsoft 365 experiences and are configured centrally by administrators in the Microsoft 365 Admin Center (admin.microsoft.com → Copilot → Connectors), rather than within Copilot Studio.

Synced connectors ingest and index third‑party content into Microsoft Graph so that it can participate in semantic indexing and discovery across Microsoft 365 Copilot experiences. Microsoft describes synced connectors as crawling and indexing content from external sources into Microsoft Graph so the data becomes discoverable in Copilot and Microsoft Search experiences.

In contrast, federated connectors (Preview at the time of writing) retrieve information in real time using Model Context Protocol (MCP) without indexing external data into Microsoft Graph. This makes federated connectors useful for sensitive or fast‑changing data, while synced connectors are typically more suitable for large knowledge repositories where broad discovery and consistent grounding is required.

Note: Federated connectors are currently available in early access preview and may not appear in all Microsoft 365 tenants.

For more information, see Microsoft’s overview of Copilot connectors (synced vs federated):
https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview

16. I’ll now add documents from SharePoint. Click SharePoint.

17. From here, you can either browse for content or paste a SharePoint URL directly.

18. Browsing allows you to select individual files, folders, or document libraries from SharePoint, as shown in the image below.

19. I’ll add the SharePoint URL that contains all of the policy documents.

Note: SharePoint knowledge sources are only available to authenticated users. If a user interacting with the agent does not have permission to a specific file or location in SharePoint, the agent will not be able to access or use that content when generating a response.

After adding the URL, the SharePoint knowledge source displays an error:

Error details: No SharePoint connection was found in this environment. The knowledge source cannot access SharePoint content. Recommended action: Please add a SharePoint connection to this environment and re-authenticate.

This error indicates that no active SharePoint connection has been configured for the Copilot Studio environment yet. In other words, although the URL is valid, Copilot Studio cannot currently authenticate to SharePoint to retrieve the content.

This is expected behaviour if a SharePoint connection has not previously been set up or if the existing connection has expired. Once a SharePoint connection is added to the environment and authentication is completed, the knowledge source will be able to access the SharePoint content and move into a Ready state.

There are several ways to create the required SharePoint connection. In this example, I’ll create the connection using the Power Apps portal.

Go to https://make.powerapps.com
In the top‑right corner, make sure you select the same environment that your Copilot Studio agent is using
From the left‑hand navigation, select Connections
Click + New connection
Choose SharePoint from the list
Sign in using an appropriate account (for example, an admin or service account)

This creates a SharePoint connection within the selected environment. Copilot Studio automatically detects the new connection, typically within a minute, and the SharePoint knowledge source status updates to Ready, as shown in the image below.

20. Let’s test the agent again. Click the + icon in the test pane to start a new conversation.

I’ll run the same prompt as before:

“What mandatory training do I need to complete and by when?”

This time, the agent is able to respond successfully. Because the SharePoint knowledge source is now connected and in a Ready state, the agent retrieves the required information from the policy document stored in SharePoint and uses it to generate an accurate, grounded response.

It also includes clear attribution, showing which SharePoint document the information was retrieved from. This helps users understand where the answer came from, reinforces trust in the response, and makes it easy to verify or follow up by opening the source document directly.

21. Next, let’s explore the tools available under the Knowledge section. Click Add tool.

22. Here are the tools available to me.

I’ll briefly explain what each tool does.

Agent Flow

Agent flows are structured, deterministic (meaning they follow a fixed, predefined set of steps and produce the same outcome every time given the same input), step‑by‑step automations that an agent can run to complete tasks reliably. They follow a defined sequence of actions and rules, ensuring consistency and predictability rather than generative reasoning. Agent flows can be triggered on demand by an agent, on a schedule, or in response to specific events.

Agent flows are typically used when a business process must be handled consistently and predictably, rather than relying on generative AI behaviour alone.

Use case 1:
HR policy advisor agent

When a user asks, “How do I request parental leave?”, an agent flow can be triggered to collect the required details (such as dates and type of leave) and then submit the request by creating a ticket, starting an approval process, or sending a notification email.

Use case 2:
Operations/administration

Agent flows can automate repeatable operational processes, such as creating a case, notifying a team in Microsoft Teams, and logging the interaction. This ensures the same steps are followed every time, improving reliability, auditability, and governance.

Note:
Agent flows can also make use of hundreds of built‑in actions and connectors available through Power Automate. This allows an agent to interact with both Microsoft and third‑party services as part of a structured workflow.

Common examples include adding data to an Excel file, creating or updating records in third‑party applications, sending emails via Outlook, posting messages to Microsoft Teams, copying files from one folder to another in SharePoint or OneDrive, starting and managing approval processes, creating or updating tasks in tools such as Planner, and generating documents from templates and storing them in SharePoint or OneDrive. Because these actions can be executed as part of an agent flow, they run in a predefined, deterministic sequence, ensuring the process is carried out consistently every time.

Prompt

This concept is easiest to understand with an example.

Example 1 – Prompt Tool:
An employee asks the HR Policy Advisor agent:

“Can I book more than 3 weeks leave?”

The agent identifies the user by retrieving their profile from Microsoft Entra ID (via the Office 365 Users connector), including details such as their location and manager.

Next, the agent checks the HR leave policy using a knowledge source, such as SharePoint, where the organisation’s policy documents are stored.

In this scenario:

Their manager is David Smith
The employee is based in the UK

Based on the policy, the agent responds:

“Hi Imran, I can see you’re based in the UK and are entitled to a maximum of 3 weeks’ annual leave. Anything beyond this requires manager approval. Would you like me to draft an email to David Smith requesting approval?”

If the employee agrees, the agent asks for additional details, such as the requested leave dates and the reason for the extended leave.

How the Prompt Tool is used

The Prompt Tool takes the structured information gathered during the conversation, for example:

Employee name
Manager name
Leave dates
Reason for the request

and transforms it into a consistent, well‑written output based on predefined instructions.

For example, the following prompt could be added to the agent using the Prompt Tool in Copilot Studio:

“Write a professional email from the employee to their manager requesting approval for extended annual leave. Include the employee name, manager name, leave dates, and reason. Address the manager appropriately and sign off from the employee.”

The Prompt Tool is used to transform structured data gathered during the interaction into a consistent, well‑written output, such as an email, message, or document, based on predefined instructions.

Example 2 – Prompt tool

Prompt Tools can also be used when an agent needs to understand, analyse, or extract information from documents, such as invoices, receipts, or reports.

For example, a user uploads an invoice and asks:

“Can you extract the supplier name, invoice number, total cost and due date from this document?”

The agent receives the uploaded file and passes the contents of the invoice to a Prompt Tool for processing.

The Prompt Tool analyses the document and extracts the required information based on predefined instructions, returning the results in a structured format.

For example, the Prompt Tool could be configured with the following instructions:

“You are an accounts assistant.
From the uploaded invoice document, extract the following information:
– Supplier name
– Invoice number
– Invoice date
– Total amount
– Due date
Return the information in a clear and structured format.
If a value cannot be found, state this explicitly.”

The agent can then return a response such as:

Supplier Name: Contoso Ltd
Invoice Number: INV‑10421
Invoice Date: 28/03/2026
Total Amount: £2,450
Due Date: 28/12/2026

Prompt Tools – Other Common Use Cases

Prompt Tools can be used across a wide range of business scenarios where an agent needs to generate, interpret, transform, or structure content. Common examples include:

Custom summarisation – summarising a policy document into plain English for an employee
Image description – explaining what a user has uploaded (for example, identifying that an image is a receipt)
Information extraction – extracting key details such as supplier name, invoice number, or due date from a document
Document creation – generating a report, letter, or approval email based on user‑provided information
Chart generation – turning extracted sales or performance data into a simple chart‑ready format
Email replies – drafting responses to customer or internal enquiries in a consistent tone
Content classification – identifying whether a document is, for example, a contract, invoice, or policy
Data reshaping – converting unstructured or extracted data into a structured format such as a table or list
and many more.

In each of the scenarios above, the Prompt Tool allows you to define a prompt that the agent runs to transform information into a clear and usable output.

The image below shows an example of a Prompt Tool configured to analyse an uploaded image and generate an output in a humorous and poetic style. The Prompt Tool also allows you to upload sample data, enabling you to test whether the prompt produces the expected result before deploying it as part of your agent.

In this example, a sample image has been uploaded to validate that the prompt correctly analyses the uploaded file and generates a creative description based on the predefined instructions provided by the maker.

Sample image of rabbit below

It is also possible to configure which AI model is used by a Prompt Tool. This allows you to experiment with different models and select the one most suitable for your scenario, such as optimising for creativity, accuracy, or reasoning capability.

As shown in the image below, the maker can choose the model to be used by the Prompt Tool and test the prompt against sample input. This makes it easy to compare outputs across models and validate that the selected model produces the desired result before the Prompt Tool is used within the agent.

Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024 to help AI agents connect to external business systems such as databases, ticketing platforms, and collaboration tools.

A simple way to understand MCP is to think of it as a USB‑C connector for AI. Just as USB‑C provides a single, standard way to connect different devices, MCP provides a standard way for AI applications such as Microsoft Copilot to connect to business systems, access their data, or perform tasks, without requiring a completely bespoke integration for each system.

AI agents are good at conversation, but they don’t automatically know how to interact with your business applications (such as HR systems, Jira, or service desks). MCP (Model Context Protocol) was introduced as a standard way for AI tools to connect to those systems, rather than needing a custom integration every time.

In Copilot Studio, you can connect to apps using built‑in connectors or APIs, but MCP is useful when you want a more “plug‑and‑play” approach where an MCP server publishes a set of tools the agent can use, and Copilot Studio can automatically discover and use those tools over time. As those tools evolve, the MCP server can surface changes centrally, without requiring you to manually rebuild integrations for each agent over time.

Example: Jira MCP Server

Jira is a widely used work management and issue‑tracking system. Atlassian (the company behind Jira) has released an official Jira MCP Server, which allows AI assistants to securely access Jira data and create or update issues on behalf of users.

Although Copilot Studio provides built‑in connectors for Jira, these typically require you to manually configure individual actions—for example:

Create an issue
Update a ticket
Check issue status

Each action also needs to be configured with specific inputs such as issue title, description, priority, or assignee. If Jira introduces new capabilities, these changes must be manually configured for each agent.

With MCP, the agent connects instead to a central Jira MCP Server. This server publishes Jira’s available capabilities as tools that Copilot Studio can automatically discover and use. If new Jira capabilities are added in the future, the MCP server can expose them centrally, allowing multiple agents to benefit without manual reconfiguration.

In short, with MCP, you connect once to a Jira MCP Server and gain access to multiple Jira tools (such as searching, creating, or updating issues), rather than configuring each action individually inside every agent.

In simple terms, an MCP server doesn’t just list what actions are available. It also handles the hard work behind the scenes, such as finding the right data, checking permissions, and applying rules. This lets the agent focus on using the tools, without needing complex configuration or prompts.

The screenshot below shows several Jira tools available in Copilot Studio that can be added manually. It also shows that you can connect to the Jira MCP Server instead. After connecting, specific tools exposed by the MCP server can be enabled or disabled based on your requirements.

Example: Microsoft Learn MCP Server

Another example is Microsoft Learn, which also provides an MCP Server.

If I added the public Microsoft Learn website address as a knowledge source, the agent would rely on indexed or stored copies of documentation. This means responses could be based on information that is slightly out of date.

By connecting to the Microsoft Learn MCP Server instead, the agent can query Microsoft’s documentation live, at runtime, using a structured interface. This allows the agent to retrieve the latest guidance directly from Microsoft Learn whenever a user asks a question.

As a result, the agent can provide:

more up‑to‑date information
more accurate answers
responses that reflect the current state of Microsoft documentation

rather than relying on pre‑indexed content or the model’s existing knowledge.

Connect to your own MCP Server

You can also create your own MCP Server for internal systems or products and connect it to Copilot Studio. This allows your organisation to publish custom tools that agents can use securely, without having to build or configure separate integrations for each agent.

Rest API

Let’s move on to the Rest API tool

You may wonder why you would choose to use a REST API Tool if built‑in connectors or MCP Servers are available.

In many cases, these pre‑built or simplified integrations may not exist yet for the system you want to connect to. However, the system may still expose a REST API, which allows external applications to communicate with it securely.

For example, your organisation may have an internal HR system, customer booking platform, or finance application which provides API access but does not have a built‑in connector or MCP Server available. REST APIs act as a standard interface between applications, allowing systems to exchange data and trigger actions.

By using the REST API Tool in Copilot Studio, you can configure your agent to:

Retrieve data from external systems
Submit or update information
Trigger processes within another application

without manual intervention.

Use Case Rest API Copilot Studio – Example 1 (Internal System)

For example, your organisation may use an internal equipment booking system that allows employees to reserve laptops or meeting rooms. While this system might not have a Copilot Studio connector or an MCP Server available, it may still expose a REST API endpoint.

Using the REST API Tool in Copilot Studio, the agent can call this API to:

check equipment or room availability
create a new booking
retrieve existing reservations

on behalf of the employee.

This allows the agent to interact with internal systems that already expose APIs, even when no pre‑built integration is available.

Use Case Rest API Copilot Studio Example 2 (Third‑Party Application)

Similarly, your organisation may use a third‑party e‑commerce platform to track customer orders. If this platform provides API access, the agent can use the REST API Tool to retrieve information such as order status or update delivery details.

For example, a user could ask:

“What is the status of my order?”
or
“Can you update the delivery address for my order?”

API integrations like this allow organisations to connect systems and automate processes in near real‑time, helping to reduce manual effort and improve operational efficiency.

When REST APIs are typically used:

a built‑in connector is not available
an MCP Server has not been provided
an internal or third‑party system exposes API access

Custom Connector

While the REST API Tool allows your agent to connect directly to an external system, a Custom Connector is useful when you want to create a reusable integration that can be used across multiple agents or solutions within your organisation.

A Custom Connector acts as a wrapper around a REST API and allows Microsoft Power Platform services such as Copilot Studio, Power Apps, Power Automate and Power Pages to securely communicate with internal or external systems using a shared set of actions and authentication rules.

Instead of configuring the same REST API calls separately in each agent or application, a Custom Connector lets you define the integration once. This includes:

expected outputs
available actions
required inputs
authentication methods

That connection can then be reused across multiple solutions.

For example, Imran works in HR and frequently needs to retrieve payroll information when employees ask questions about salary adjustments or overtime payments. The organisation’s internal payroll system exposes a REST API which does not have a built‑in Copilot Studio connector or an MCP Server.

Initially, this integration could be set up using the REST API Tool inside a single HR agent. However, other solutions, such as a Payroll Advisor agent, an internal Power App, or an external Power Pages website may also need access to the same payroll system.

If the REST API Tool were used directly, each solution would need its own copy of the same API configuration. Instead, a Custom Connector can be created to define this integration once and store it centrally within the Power Platform environment.

Where Custom Connectors are created

When selecting the Custom Connector option within Copilot Studio, you may notice that you are redirected to the Power Apps Maker Portal. This is expected, because Custom Connectors are not created directly inside Copilot Studio. They are part of the wider Microsoft Power Platform and are managed at the environment level.

Once created, the same Custom Connector can be reused by:

Copilot Studio agents
Internal Power Apps
External Power Pages websites
Power Automate workflows
Logic Apps

without needing to configure the REST API integration separately within each solution.

Computer Use

Next, let’s move on to Computer use, as shown in the images below.

So far, we’ve seen how agents can use tools to send emails, retrieve data, or integrate with third-party applications such as ServiceNow using connectors, REST APIs, or MCP. However, many organisations still rely on legacy systems which do not support modern integrations. These may include older desktop applications or internal web based systems that are too costly or complex to redesign and do not expose APIs or MCP servers.

For example, employees might currently need to manually copy invoice details from a Word or PDF document into a legacy invoice management system, such as the one shown below. (Image source: Microsoft Events)

In many organisations, this type of manual process could involve processing hundreds or even thousands of invoices every month.

With the Computer Use in Copilot Studio, an agent can interact directly with applications in the same way a human would, by using a virtual keyboard and mouse to control what appears on screen. This allows agents to automate tasks even when no API integration exists.

Example: Automating invoice entry in a legacy system

Using Computer use, you could configure your agent to monitor a shared mailbox for incoming invoices. When a new invoice arrives, the agent can:

open a legacy desktop application or browser‑based system
sign in using securely stored credentials (for example, via a secure credential store or Azure Key Vault)
copy invoice details from the uploaded document
enter the information into the system
save the record and move on to the next invoice

The agent navigates the application by clicking buttons, entering text, and interacting with the user interface exactly as a person would. If required information is missing or unclear, the agent can pause the process and notify a human by sending an email or message, supporting human‑in‑the‑loop supervision.

Copilot Studio: Where Computer use can run

Computer use can run on different machine types, including:

a hosted browser environment
a Windows machine registered for Computer use
a Windows 365 Cloud PC

This flexibility allows organisations to automate legacy processes without modifying their existing applications.

Publish agent to Microsoft 365 Chat and Teams

Finally, let’s look at how to make your agent available to users in Microsoft 365 Copilot chat and Microsoft Teams.

Once you’ve configured your agent’s instructions, knowledge sources, and tools, the next step is to publish it. Publishing applies the latest version of your agent and makes it ready to be used in Microsoft 365 Copilot experiences and other supported channels.

Think of Publish as deploying the agent so it can be accessed outside of Copilot Studio. Users will only see the most recently published version of your agent.

To publish your agent:

In Copilot Studio, open your agent
Select Publish
Confirm to make the latest version available.

4. After clicking Publish, you’ll be prompted to add some additional details, such as:

the developer name
a short description of the agent

5. Once completed, click Publish.
The publishing process usually completes in under a minute.

6. Configure user access
After publishing, you’ll need to decide who can access the agent. At this stage, you can either grant access to specific users or groups or click Copy link to test the agent yourself.

Note: To make an agent available to the entire organisation, an administrator must approve the request in the Microsoft 365 admin centre: admin.microsoft.com → Agents (left navigation) → Requests

Granting permissions to individual users or groups does not require admin approval. Admin approval is only required when making the agent available to the entire organisation, as shown in the image below.

The owner or maker of the agent is automatically granted full control. If I were to select a different user or group, I could configure specific permissions, such as whether they are allowed to view, edit, configure, share, publish, or delete the agent.

7. Click Copy

8. Open a web browser and paste the link.
Sign in using an account that has permissions to access the agent.

After a few seconds, you’ll be prompted to add the agent as shown in the image below.

Success. The agent has now been added to my Microsoft 365 Copilot Chat.

The agent is also visible in the agent store, making it easy for authorised users to find and access it.

Note: If you make any changes to the agent in Copilot Studio, you must publish again. After publishing, updates can take 5–15 minutes to appear consistently across Microsoft 365 Copilot experiences.

9. You can optionally pin the agent, so it appears in the left‑hand navigation for quick access. Alternatively, you can invoke the agent directly within Microsoft 365 Copilot Chat by typing the @ symbol followed by the agent’s name, and selecting it from the list.

To validate the behaviour, I asked the agent an off‑topic question, such as:

“Can you help me bake a chocolate cake?”

Result: The Policy Advisor agent correctly declined to help, as expected, in line with the instructions and scope defined earlier.

When asked questions related to internal policies, the agent responds correctly.

I hope you found this post useful.

If you have any feedback or questions, please feel free to leave a comment below.

See you in the next post

Copilot Agents: Agent Builder, Copilot Studio, or Foundry?

Posted on March 25, 2026 by Imran Rashid

Reading Time: 9 minutes

In this blog post, I’ll explore the different ways you can build and deploy agents. We’ll compare Agent Builder in Microsoft 365 Copilot, Microsoft Copilot Studio, and Microsoft Foundry, focusing on when to use each option. The goal is to help you understand the trade offs around complexity, cost, control, and required skills, so you can confidently choose the right approach (or a combination) for your scenario.

Microsoft provides several ways to build agents because different audiences need different levels of control. Some users want a quick, no‑code experience, while others require deeper engineering flexibility and operational controls. Instead of a single tool, Microsoft offers multiple platforms that sit at different levels of complexity, each designed for a specific type of use case.

What do we mean by an agent?

Before looking at the different platforms, it’s important to clarify what we mean by an agent.

In the Microsoft ecosystem, an agent is a customised AI assistant created for a specific purpose. Unlike Microsoft 365 Copilot’s out of the box experience included in Microsoft 365 Copilot Chat, Word, Excel, PowerPoint, Outlook, Teams and more, an agent has clearer instructions, can be grounded in specific knowledge, and may be able to take actions (such as calling tools, workflows, or APIs).

Not every agent needs the same level of capability. Some agents are simple and focus on answering questions consistently from approved content, while others are designed for multi-step workflows, deep integrations, or full application style deployment and monitoring. This is why Microsoft provides multiple ways to build agents, rather than a single platform. It is also possible to start with the simpler options before moving on to the others.

The three levels of agent building in Microsoft

Rather than thinking about these platforms as competing tools, it’s more helpful to think of them as different levels of agent complexity and control. Organisations can start with the simplest option and move up as their requirements (and skills) grow.

Microsoft provides three main ways to build agents, each designed for a different audience and level of control listed below:

Copilot‑native agents (Agent Builder) – built directly inside Microsoft 365 Copilot Chat for fast internal use and simple scenarios. Accessible via m365copilot.com

Best for: quick, focused agents that help you (or a small team) get consistent answers and guidance using approved content, without building workflows or managing deployment.

Example use case:
Team onboarding helper – An agent that answers common questions like:

“Where’s the onboarding checklist?”
“What’s the process for requesting access?”
“Who do I contact for a laptop or software?”

It can be grounded in SharePoint pages, onboarding documents, and internal FAQs so new starters get consistent answers without asking the same questions repeatedly.

Choose this when: you want a quick internal agent that stays within the Copilot experience and doesn’t need complex automation or multi-channel deployment.

2. Low‑code business agents (Copilot Studio) – built using Microsoft Copilot Studio when you need richer automation, connectors, and broader rollout. Accessible via copilotstudio.microsoft.com

Best for: agents that can do more than answer questions, that can take action, follow a conversation flow, connect to systems, and be rolled out to more users and channels.

Example use case:
IT helpdesk agent – An agent that answers common questions like:

Answer: “How do I reset my VPN / access a shared mailbox?”

Take action: “Create a support ticket”, “Check ticket status”, “Route to the right team”

Run a workflow: gather device details, confirm urgency, trigger an approval, notify support

This is where connectors and workflows really help, your agent doesn’t just talk, it gets things done.

Choose this when: you need automation/workflows, integrations (connectors/APIs), or a wider deployment across Teams, web or other supported channels.

3. Engineered AI agents (Microsoft Foundry) – built and operated as applications using Microsoft Foundry on Azure for full engineering control, deeper integrations, and production monitoring. This approach is more powerful, but also more complex and typically requires developer/DevOps skills. Accessible via Azure Portal or https://ai.azure.com

Best for: pro‑code, production-grade agent solutions where you need maximum control over how the agent is built, deployed, secured, monitored, and scaled.

Example use case:
Customer order assistant embedded in an app – A customer facing agent that:

Looks up orders in multiple systems
Applies business rules (refund thresholds, fraud checks, region specific policies)
Uses advanced monitoring/telemetry so engineers can troubleshoot issues in production
Scales reliably during peak demand
This is ideal when the agent is part of a larger application or service and needs full engineering and operational control.
Agents in Microsoft Foundry can be integrated with agents in Copilot Studio as part of a hybrid approach.

Choose this when: you need a code first approach, more control, complex integrations, advanced observability/evaluation, integration with pipelines, or you’re building an agent as an application that must run at scale.

These options are not mutually exclusive. Many organisations start with simpler agents and move up the stack as requirements around control, scale, integration, and observability increase.

Naming note: Microsoft’s naming has evolved over time. The embedded agent experience inside Microsoft 365 Copilot (Agent Builder) has also been referred to as Copilot Studio “Lite”. The standalone Microsoft Copilot Studio experience evolved from Power Virtual Agents (PVA).

Quick decision guide

Choose Agent Builder if you want a quick internal agent for yourself or a small team, built directly in the Microsoft 365 Copilot experience with no coding experience needed.
Choose Copilot Studio if you need workflows/actions, connectors, publishing, authentication options, and broader rollout across different channels, such as a website/web app, Microsoft Teams, Microsoft 365 Copilot, SharePoint, and other supported channels.
Choose Microsoft Foundry if you’re building an agent as an application and need pro-code control, deeper Azure integration, DevOps, and production-grade monitoring/evaluation.

Copilot Studio vs Microsoft Foundry (the simplest way to understand the difference)

A way to view this is SaaS (Software as a Service) vs PaaS (Platform as a Service).

Copilot Studio is a managed, low‑code SaaS experience, designed for business teams, makers, and IT pros who want to build agents quickly with plug and play integrations and minimal infrastructure management.
Microsoft Foundry is a more Azure native, pro‑code PaaS approach, designed for professional developers and engineering teams who need fine-grained control over runtime, integrations, security configuration, and DevOps practices.

The key trade off: Copilot Studio optimises for speed and simplicity, while Foundry optimises for control and flexibility, especially at scale.

Security and governance

A common worry is: “Will an agent expose data users should not see?”

1) The most important principle: agents are designed to respect existing permissions and access controls

In Microsoft 365, agents are designed to respect your existing access model. For example, SharePoint agents respond based on what the current user is allowed to access. If the user doesn’t have permission to a file or site, the agent will not surface information from it. This is why cleaning up overshared SharePoint sites and using clear permissions is one of the best security improvements you can make before rolling out agents.

2) Microsoft Purview: governance for prompts, responses, and AI usage

Microsoft Purview is the place to apply security and compliance controls to AI interactions (prompts and responses) using the same tools you already use for Microsoft 365 data. This can include:

Auditing and investigation support (who asked what, when)
Data classification and sensitivity labels
Data Loss Prevention (DLP) to reduce accidental oversharing
eDiscovery, retention, and lifecycle management
Insider Risk and Communication Compliance

In other words: Purview helps you treat AI interactions as governed business data, not random chat.
Purview Auditing = who did what where in Copilot?
Purview eDiscovery = searching for the actual prompt and response

3) Controlling rollout: block agents, limit who can use them, and require approval

You don’t have to let everyone build or use agents on day one. A safe rollout usually looks like this:

Start with a pilot group (selected users)
Allow only approved agents to be available broadly
Block or remove agents that aren’t compliant or aren’t needed

For Copilot native agents built with Agent Builder, sharing is intended for limited access (for example, a small team) rather than formal organisation wide deployment. For broader rollout and multi channel publishing, use Copilot Studio and follow your organisation’s approval process before the agent becomes widely available.

4) Microsoft Foundry (Azure): security looks like an Azure workload

Foundry is the engineered option, so governance is handled like any other Azure application:

Identity and access control using Azure roles and Microsoft Entra ID
Network controls (private endpoints/VNET where needed)
Secrets management (for example Key Vault)
Monitoring and tracing (so you can see what happened and debug issues)

This is ideal when you need deeper control, but it also means more responsibility and stronger engineering discipline.

5) Defender for Cloud for AI: detecting agent specific attacks

Agents introduce new attack paths (prompt injection, jailbreaking, data leakage, credential theft, and more). Microsoft Defender for Cloud includes threat protection for AI services that helps detect and respond to these threats, and can integrate with Defender XDR so AI related alerts appear alongside the rest of your security incidents. For Foundry agents, Microsoft has also introduced specific protections and recommendations focused on the agent lifecycle (inputs, memory, tool calls, and actions).

6) What’s coming next: Microsoft Agent 365 (the control plane for agents)

As organisations create more agents, the challenge becomes visibility and control:

“How many agents exist, who owns them, what can they access, and are they behaving safely?”

Microsoft Agent 365 is designed to address this by giving IT and security teams a central control plane to discover, govern, and manage agents including third party agents at scale, including agent identity, access control, observability, and integration with Purview and Defender. As this matures, it should help organisations move from agent sprawl to governed, auditable deployments.

7) and others – Check out the Zero Trust Workshop

I’d recommend checking out Microsoft’s free Zero Trust Workshop, which now includes an AI security pillar with guidance for securing AI resources and agents. You can access it here: https://zerotrust.microsoft.com/

Agent Builder vs Copilot Studio vs Foundry Comparison

.	Agent Builder	Microsoft Copilot Studio	Microsoft Foundry (Azure)
Best for	Quick, internal agents for individuals or small teams, ideal for simple, scenario specific help (for example onboarding or coaching) built directly inside Microsoft 365 Copilot Chat.	Business agents that can answer and take action (workflows, integrations, and broader rollout beyond a small team).	Production grade, engineered AI agents built as applications (complex scenarios, full engineering control).
Primary audience	Information workers and beginners who want to create simple, Copilot native agents quickly (no code).	Business teams, makers (low‑code builders), and IT admins	Developers, software engineers, and data/AI teams with strong coding and DevOps
Skill level	No‑code (built using natural language inside Microsoft 365 Copilot).	Low‑code (UI‑based building; minimal coding for most scenarios).	Pro‑code (engineering and DevOps skills typically required).
Platform model	Copilot native experience inside Microsoft 365 Copilot Chat (designed for quick, straightforward agent creation without managing infrastructure).	Managed, Microsoft‑hosted service (SaaS‑style), so you don’t manage servers/infrastructure.	Azure native PaaS (Platform as a Service) in your Azure subscription for maximum control.
Where it runs	Inside Microsoft 365 Copilot experiences	Runs in a Microsoft hosted Copilot Studio service within a Power Platform environment. You publish it to channels (Teams/M365, web, etc.) rather than hosting it yourself.	Runs on Azure. You manage the supporting Azure resources and operational setup (like any other cloud application).
Integration approach	Focused on simple, Copilot‑native configuration with selected knowledge sources (for example SharePoint content and Microsoft 365 Copilot connectors) to keep the agent scoped and easy to maintain.	Uses built‑in connectors and low‑code workflows/topics to connect to Microsoft 365 and other systems.	Deep integrations via code with Azure services and enterprise systems (ideal for complex architectures).
Dev experience	Simple build experience using natural language and basic configuration (Describe/Configure). Includes a built‑in test experience so you can try the agent and refine it quickly.	Build with a visual UI (topics, tools/actions, publish), designed for fast iteration.	Code first development with SDK/tooling and CI/CD integration into your existing engineering workflows.
Deployment channels	Runs inside Microsoft 365 Copilot experiences (microsoft365.com/chat, office.com/chat, and Teams desktop/web). You typically share it with specific people for internal use rather than publishing across multiple channels.	Publish to multiple channels (for example Teams and Microsoft 365, web, and other supported channels).	Flexible delivery options. Expose via APIs or integrate into apps/services and custom channels (you choose the delivery pattern).
Observability	Basic adoption/usage visibility through Microsoft 365 Copilot agent reporting (for example active users/sessions and agent inventory), rather than deep application style tracing/telemetry.	Built‑in analytics and usage insights for deployed agents (good for adoption/performance tracking).	Strong production monitoring and debugging capabilities, including tracing into Azure Application Insights using OpenTelemetry.
Evaluation	Basic testing through the built in “Try it” experience to validate behaviour and then refining instructions if needed.	Supports testing and a publish/re‑publish lifecycle (so changes go live only when you publish).	More rigorous testing and debugging options suited to production engineering and quality control.
Cost	Included with Microsoft 365 Copilot. Copilot Chat business users (without a Copilot license) can use web grounded agents free, but tenant data grounding requires metered billing.	If users have a Microsoft 365 Copilot license, they can use Copilot Studio agents inside Microsoft 365 without separate per‑use billing in many employee scenarios. Otherwise, Copilot Studio usage is paid via Copilot Credits (packs or pay‑as‑you‑go). More info here	Azure consumption billing, you pay for the Azure resources and services used by your solution.

Model Choice and Fine Tuning

No explicit model selection

Limited model selection available (choose the primary model; admins can control access to preview/experimental and external models).

Largest model choice and fine‑tuning (broad model catalog including over 10,000 models; fine tune supported models to fit your needs).

Examples (Mapping a scenario to a platform)

Example 1: Internal policy helper
A small HR team wants an agent that answers common policy questions using approved internal content (for example, leave policy, expenses, onboarding). Agent Builder is a good fit because it’s quick to set up inside Microsoft 365 Copilot and works well for simple internal scenarios.

Example 2: IT helpdesk agent that can take actions
You want the agent to answer questions and trigger workflows (for example, create a ticket, check ticket status, notify an on-call engineer, or run an approval). Copilot Studio is typically the better fit because it’s designed for business workflows, connectors, and publishing to multiple channels.

Example 3: Customer support agent embedded in a production application
You’re building a customer facing agent inside a web/app experience that must securely access order data, enforce business rules, and perform actions like creating tickets or initiating refunds. You need strong operational controls (monitoring/tracing) and private networking options. Microsoft Foundry is built for this agent as an application scenario.

Summary: how to choose without overthinking it

There isn’t a single best option. The right choice depends on your team, your audience, and how much control you need.

If you need something quick and internal, start with Agent Builder.
If you need automation, connectors, and broader rollout, use Copilot Studio.
If you need full engineering control, deep Azure integration, and production operations, use Microsoft Foundry.
Organisations can also use a mix of the above.

The images below summarise the three solutions:

AgentBuilder vs CopilotStudio vs Foundry

One last example that usually makes it click:

Agent Builder = enter a store and grab a pre‑packed sandwich (fast, minimal choices).

Copilot Studio = enter a restaurant and order a freshly made sandwich from a menu (more options, still managed for you).

Microsoft Foundry = you’re the chef. You choose the ingredients and the recipe, and you’re responsible for all operations.

I hope you found this post useful. See you at the next one.

Building an Autonomous AI Agent in Copilot Studio – Part 7: Add Tools to a Copilot Studio Agent

Posted on January 20, 2026 by Imran Rashid

Reading Time: 9 minutes

Welcome to part 7 of this blog post series.

If you missed the previous parts, visit the links below:

In this part of this blog post series, I will connect a number of tools to my agent. Tools enable agents to automate processes and complete tasks without human intervention. There are over 1,000 pre-built connectors in the Power Platform, which allow us to connect to Microsoft and third party applications.

We can grant the agent access to the Excel files, Email, and more. Without tools, the agent would not have the permissions to access my data and make changes.

We need a combination of the trigger, the tools, and the instructions so the agent knows what is required of it. The end result is an agent that has access to the tools it needs, a trigger to start it, and clear instructions that guide how the tools should be used.

But haven’t we already added a trigger in an earlier post?
Correct, the trigger plays an important part. The trigger detects when a Microsoft Form is submitted and retrieves the responses. It allows the agent to capture details such as the course code submitted by the trainer.

However, for the agent to determine who to assign the request to, it also needs access to the central mentors Excel spreadsheet so it can compare the submitted course code with the central mentors.xlsx spreadsheet.

The agent therefore needs permission to read data from both the Microsoft Form and the Excel file. This is why we need to add tools. Tools allow the agent to access and work with external data sources such as Forms, Excel, and email.

In this post, we’ll explore the different types of tools available in Copilot Studio before adding the required tools to the Course Mentor Agent.

We will add and configure the following tools:

Get response details (Microsoft Form)
List rows present in a table
Add a row into a table
Send an email (V2)

Task: Add tools to agent

Select tools

2. Click + Add a tool

You’ll find a number of tools to choose from. I have provided an explanation for each option in the table below.

Tool option	What it does	Explanation
All	Shows all available tools	Displays every tool your agent can use in one place. Useful if you just want to browse everything that’s available.
Connector	Connects to other services	Lets your agent connect to Microsoft or third‑party services (for example SharePoint, Dataverse, Outlook, or Teams) using built‑in connectors.
Prompt	AI‑based instruction	Allows you to define a natural‑language prompt that the agent can run using AI, such as summarising text, rewriting content, or generating an explanation.
Flow	Runs Power Automate	Runs a Power Automate flow from your agent, such as saving data to Excel, sending an automated email, or creating a ticket.
REST API	Calls external APIs	Allows the agent to call an external REST API directly to send or retrieve data from custom or third‑party systems.
Model Context Protocol (MCP)	Connects to MCP servers	MCP is an open‑source standard for connecting agents to external tools and data through an MCP server. When you connect to an MCP server, Copilot Studio automatically discovers the tools and data it provides (including names, inputs, and outputs). In many cases this feels plug‑and‑play as you don’t need to build anything yourself unless you want to expose your own systems. The MCP server provides the context and capabilities, and the agent uses them as needed.

There are over 1,000 tools available that allow an agent to connect to both Microsoft and third-party products to automate business processes. I’ve added a few images below that show the different types of tools available. This is just a small sample, there are many more available.

Task: Add tool – Get response details (Microsoft Forms)

3. Search for and select Get response details, or use the search box if the tool is not visible.

4. Click the Add and configure button, as shown in the image below

5. If a connection is not already established, click Create connection and sign-in

This will allow the agent to retrieve the Microsoft Form response, but we need to select the Microsoft Form created in part 1.

6. Click additional details, as shown in the image below.

7. I’ll be changing End user credentials to Maker-provided credentials, as shown in the image below.

Why change this setting?

If I leave as the default End user credentials option enabled, users will be prompted to sign-in before the agent can retrieve form responses. This may work fine for internal only forms, but it can cause problems if the form is shared publicly, as not everyone will be able to sign-in. By switching to Maker‑provided credentials, the agent uses my connection to Microsoft Forms instead of the end user’s credentials. This allows the agent to retrieve form responses automatically, even when the form is available to external or anonymous users.

This setting depends on your scenario and how you want users to interact with your form.

8. Next, scroll down to Inputs. This is where I select which Microsoft Form to use. I chose the form I created earlier in this blog post series (Part 1).

Click Dynamically fill with AI and select custom value

9. Click inside the Unique identifier of the form field. A list of available Microsoft Forms will appear. I select the form I created earlier in part 1 of this series.

10. The Response Id field will be left set to Dynamically fill with AI. This is because each time a trainer submits the form, a new and unique form response ID is generated, so it isn’t possible to provide a fixed value.

11. Click Save

Task: Add tool – List rows present in a table (Excel Online Business)

Next, I need to add an Excel tool so that my agent can access my Mentors Excel file, which includes a list of all course mentors.

12. Select Tools and search for Excel. Select List rows present in a table, as shown in the image below. This allows the agent to read all rows from the Mentors table and dynamically determine which mentors are qualified based on the course code is associated with them. The agent can then use this information later to select a suitable mentor for the request.

13. If a connection is not already established, click Create new connection

14. Click Create

15. Sign-in

16. Check that the connection is enabled.

17. Again, as we did earlier with the Microsoft Forms tool, click the Add and configure button, as shown in the image below.

18. Click Additional details and change the credentials to Maker-provided credentials, so the tools uses my credentials. Leave the name and description set to their defaults.

19. Scroll down to Inputs

For Location, click the dropdown under Fill using, select Custom value. Click inside the Value box, and choose OneDrive for Business from the list.

For Document library, click the drop down under Fill using and select Custom value. Click directly inside the Value box, and select OneDrive from the list.

For File: Click and select the file. This would be my file named Mentors.xlsx

If you received the following error message: You are not authorized to use this connection. Please consider using a different connection. Manually type the name of the Excel file, such as Mentors.xlsx. This is common if you have only just created or uploaded the file.

20. Select Table1, or manually type Table1 if it does not appear.

Note: the table name comes from Excel when your data is formatted as a table. With the table selected in your Excel file, go to Table Design at the top of the Excel spreadsheet. You’ll find the table name there, which usually defaults to Table1.

21. Click Save

22. You should now have two tools added to the agent

Task: Add tool – Add a row into a table

23. We also need the agent to record the outcome of each mentoring request. This includes logging the requester’s details and the mentor who has been assigned.

To achieve this, we’ll add the Add a row into a table Excel tool, which will be used to add a row to the RequestLogs.xlsx file after a mentor has been selected.

In addition, we’ll add an email tool later in this post so the assigned mentor is notified when a new mentoring request has been assigned to them.

24. Select Tools and choose Add a tool. Search for Add a row into a table (Excel Online Business), and select it from the list.

25. Click Add and configure

26. Click Additional details and change the authentication setting to Maker‑provided credentials, so the tool uses my account.

27. Click Inputs and configure the following settings:

Location: Select Custom value from the drop box, click in the Value box, and choose OneDrive for Business.

Document Library: Select Custom value from the dropdown, click inside the Value box and choose OneDrive.

File: Select Custom value from the dropdown, click inside the Value box, and browse to select file RequestLogs.xlsx.

Table: Select table1

Row: Leave this set to the default (if not already greyed out). We can’t specify a specific row, as new rows will be added dynamically by the agent.

Note: If you’re unable to browse to the file, manually type the name of the Excel file. This can happen if the file has not yet been indexed.

28. Click save

Task: Add tool – Send an email

29. Select Tools, then click Add a tool. Search for and select Send an email V2 (Office 365 Outlook)

30. If a connection is not already established, click Create connection and sign in

31. Click Add and configure

32. Click Additional details and change the authentication setting from End user credentials to Maker‑provided credentials, so the tool uses my account.

33. Scroll down to Inputs and configure the following:

To: Leave this field dynamic. The agent will determine who to send the email to by analysing the MentorEmail field in the Excel spreadsheet (Mentors.xlsx).

Subject: Select Custom value from the drop down and add a subject, Course Mentor Request

Body: Leave this field dynamic. The agent will generate a suitable email message based on the mentoring request.

That’s it, we’ve successfully added four tools, as shown in the image below.

In the next post, we’ll return to the agent instructions we described in part 3 and make some amendments to instruct the agent to use the tools we’ve just created.

Click the following link to continue: Building an Autonomous AI Agent in Copilot Studio – Part 8: Amend Existing Agent Instructions to Use Tools – Cloud Build

Building an Autonomous AI Agent in Copilot Studio – Part 1: Create a Microsoft Form

Posted on January 20, 2026 by Imran Rashid

Reading Time: 3 minutes

In this blog post series, I will go through the steps to build an autonomous agent in Copilot Studio. This blog post series has been broken down into 9 parts.

Use case:
Imran Rashid Training Ltd (a fictitious company) wants to develop an autonomous AI agent. An agent that can automatically respond to events and take actions without human intervention, using Copilot Studio.

The company wants to help new trainers who are looking for a mentor to help them prepare for new Microsoft courses, such as AZ‑104, SC‑300, AZ‑700, PL‑7008, AZ‑204, AI‑102, AI‑900, AZ‑900, and others.

The company requires new trainers/mentees to complete a Microsoft Form if they would like help when preparing for a course before they begin delivering to customers. When the Microsoft form is submitted, it triggers an autonomous action that allows the agent to process the request automatically. In simple terms, the autonomous agent reacts when something happens, such as a Microsoft form submission.

The autonomous AI agent detects the form submission and processes the request. The agent accesses an Excel spreadsheet that includes a list of trainers who already deliver a number of Microsoft courses and have volunteered to mentor others who are delivering specific courses for the first time.

The agent analyses the form submission and compares it with the Excel data to determine which mentor should be assigned. An email is then automatically sent to the selected mentor so a one‑to‑one call can be arranged.

Furthermore, the agent will update a central Excel spreadsheet with the details of the request, such as the requester’s name, email address, country and areas of concern. The agent will also complete the mentor assigned field so we can track which mentor was automatically assigned to the request.

To summarise, we will:

Create a Microsoft Form that allows new trainers to submit mentoring requests.
Build an autonomous AI agent in Copilot Studio, without writing any code, using natural language to define what the agent is built for and the tasks it needs to complete.
We will name the agent, upload an image/logo, and add draft instructions so the agent understands what it was built for. These instructions will include a few placeholders that we’ll return to and complete later.
Create a Microsoft Form trigger so the agent is able to detect and process new Microsoft forms submissions whenever a form is completed.
Connect the agent to tools such as Excel and Outlook, allowing the agent to automate sending an email, reading an Excel spreadsheet which will include a list of mentors, and updating a log file including mentee details and the name of the mentor assigned.

Let’s get started and build our autonomous AI agent in Copilot Studio.

Task 1: Create Microsoft Form for requesters who require a course mentor

Access and sign in to https://forms.microsoft.com
Select Create new and choose Form (in some tenants it may say New form).
Instead of creating the form manually, I will use Copilot in Microsoft Forms to generate the form for me. In Copilot for Microsoft Forms, enter the following prompt:

Prompt start

Create a Microsoft Form titled “Trainer Mentoring Request” for Imran Rashid Training Ltd.

Purpose: allow trainers to request mentoring support before delivering a Microsoft course.

Add a short description at the top explaining that a mentor will be assigned based on the information provided, so it is important that the form is completed accurately.

Include the following questions:

1) Full Name (text, required)
2) Email Address (text, required)
3) Course Selection (choice, required):

AI-102
AI-900
AZ-104
AZ-204
AZ-500
AZ-700
AZ-900
MS-4018
PL-7008
SC-100
SC-200
SC-300
SC-401
MS-4023
AZ-305

4) Country (text, required):

5) Specific Areas of Concern (long text, required) – for example, help with demos or course delivery

Prompt end

4. Check you’re happy with the form and feel free to test it clicking the preview button. Change the design of the form if needed and make any additional tweaks to the form.

Join me in Part 2, where I explore environments in Power Platform and create a new one for use in Copilot Studio. Click the following link to continue: Building an Autonomous AI Agent in Copilot Studio – Part 2: Create a Power Platform Environment – Cloud Build