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:
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.
