What to Choose When Creating an Agent in the Microsoft Ecosystem
What to Choose When Creating an Agent in the Microsoft Ecosystem.
An overview of all options for creating an AI agent in the Microsoft ecosystem—categorized by purpose, licensing, developers, and development method.
Microsoft currently offers several ways to create an AI agent. You can create an agent on SharePoint in just a few minutes; a maker can create an agent in Copilot Studio using a low-code or no-code approach; and a development team can bring its own orchestration to Microsoft 365 or run its own agent (code) in Azure Foundry.
A similar demo can be set up in almost any of them. The difference becomes apparent only in production: in identity, permissions, distribution, observability, billing, and who handles the incident on Monday morning.
Do not choose based on where you can build the fastest demo. Choose based on who will carry the production responsibility..
Questions to Help You Choose the Right Tool
The breakdown into no-code, low-code, and pro-code is useful for assessing skills, but it is not sufficient on its own. The following four questions will help you better determine the production architecture.
1. Where should the agent be available?
Just Microsoft 365 Copilot, SharePoint, and Teams? Or a web version as well? Should it be available on mobile? Should it offer an API?
2. Whose identity will the agent use?
Should the agent always respect the permissions of the user, or should it operate autonomously using its own application or agent identity?
3. Who operates the agent?
Who monitors the quality of responses, costs, and manages the agent lifecycle? Who handles outages and approves changes or new skills?
4. What kind of loss can result from an agent's error?
An incorrect answer to an FAQ and sending an wrong payment are not errors with the same impact. The greater the impact of an agent’s action, the more we need deterministic safeguards (human approval, auditing, the ability to manage agent runs).
One Ecosystem, Four Options
Microsoft 365 Copilot Agent: A Great Foundation for Responses
Agent Builder in Microsoft 365 Copilot creates declarative agents using instructions, knowledge, and actions on top of Copilot's orchestrator and models. It suits a personal or team knowledge scenario that should remain inside Microsoft 365. Sharing from Agent Builder is intended for a limited group of users; for broader distribution and multiple channels, Microsoft points to Copilot Studio.
The SharePoint agent automatically makes sense: a specific site, library, or selected files. It is a good choice for Q&A over documentation when content quality is known and SharePoint permissions match the intended audience.
Copilot Studio: For Makers and Citizen Developers
Copilot Studio is appropriate when a maker needs to combine knowledge, tools, topics, workflows, testing, and publishing into a managed solution. The agent can be available in Microsoft 365, Teams, on the web, and in other channels. Power Platform adds environments, DLP, roles, solutions, and lifecycle management.
Microsoft 365 Agent SDK: When You Need Professional IT Approach
If you need (or want) to use your own orchestration and code for your solution, Microsoft 365 Agents SDK provides the communication and channel layer. Agents Toolkit helps with scaffolding, manifests, local testing, provisioning, and deployment.
An SDK is not an entire AI platform. You still have to handle the model, orchestration, hosting, and telemetry. It’s the right approach if your own UX and integrations provide added value. It’s not the right solution just because “the team knows how to write code.”
Microsoft Foundry, Agent Framework: a custom agent platform
Microsoft Foundry Agent Service is a managed platform for building, deploying, and scaling agents. Prompt agents leave execution to the service; hosted agents let you package custom agent code while using a managed endpoint, scaling, identity, and observability. This layer makes sense when you are building a production service and need model choice, Azure network and RBAC boundaries, or a custom API.
Microsoft Agent Framework is a code-first layer for agents and explicit graph-based workflows. It represents the shared next direction from the AutoGen and Semantic Kernel teams. For a new project, it therefore makes more sense to evaluate Agent Framework than to automatically start another solution on AutoGen.
Do not create new agents on Foundry Agents (classic).
Microsoft marks the classic service as deprecated and lists its retirement date as March 31, 2027.
Decision map
The control is not for free
Moving from a declarative agent to custom engine (code) adds capabilities, but it also brings more responsibility. With Copilot Agent, Microsoft largely determines the model, orchestration, and security. With Copilot Studio, the Maker can operate within the boundaries defined by the Power Platform’s governance settings. With custom solutions, the team manages nearly the entire stack.
The most common mistake is byuing more control than the team is capable of operate. A custom orchestrator without an evaluation set, telemetry, and safe deployment is not “enterprise.” It is simply a larger surface for unnoticed failures.
- Identity: Distinguish between delegated user access and application (agent) identities.
- Data: Determine where the agent reads data from, where it can store data, and how permissions are configured for the data.
- Actions: separate read, write, delete, approval, and external communication. Use a deterministic flow or human approval for risky steps.
- Quality: create an evaluation set before the pilot, not after the first public failure.
- Operations: assign owners for cost, alerts, versions, incidents, and the emergency-disable procedure.
When not to build an AI agent
An agent is not a synonym for modern automation. A model is useful when the system must interpret ambiguous input, work with natural language, select a tool, or adaptively plan the next step. It is not a good, more expensive replacement for a precisely known rule.
| Situation | Better default | Why |
|---|---|---|
| Input and output have fixed schemas and the steps are known | Power Automate / agent flow | Determinism, simpler testing, and predictable cost |
| The user needs to find a document or record | Search, filters, navigation | A faster and more explainable result |
| The decision must always be consistent and auditable | Rules, business logic, approval | An LLM is not deterministic |
| There is no owner for the knowledge or process | Establish ownership first | The agent only scales outdated content and unclear responsibility |
| You do not have representative test cases | Create an evaluation set first | Without a baseline, you cannot prove improvement |
Adoption: pilot, process, platform
An organization does not need to choose one platform for every future agent. It needs rules for using the smallest sufficient layer and for allowing a controlled move to the right.
- Pilot: Choose a known process, identify the owner, and measure both the quality of the responses and actual usage.
- Scale: Add processes, environments, DLP, test suites, and telemetry.
- Platform: Standardize only critical and integration-intensive processes to a pro-code approach with CI/CD, identity, networking, and production operations.
The goal is not to move everything to the right. The goal is for every agent to end up on the simplest layer that meets its risk and operating profile—and to retain an escape path when requirements genuinely change.
The most effective agency strategy is not to use as many platforms as possible. Instead, it is to use and take advantage of all available options while using as few platforms as possible.
Sources
- Agents hub — Microsoft Learn
- Declarative and custom engine agents for Microsoft 365 Copilot — Microsoft Learn
- Choose between Agent Builder and Copilot Studio — Microsoft Learn
- Copilot Studio implementation guidance — Microsoft Learn
- Copilot Studio billing rates and management — Microsoft Learn
- Microsoft 365 Agents SDK overview — Microsoft Learn
- Microsoft Foundry Agent Service overview — Microsoft Learn
- Microsoft Agent Framework documentation — Microsoft Learn
- AutoGen to Microsoft Agent Framework migration guide — Microsoft Learn
- Foundry Agent Service classic lifecycle — Microsoft Learn
Comments
Post a Comment