Last reviewed: October 13, 2026

Microsoft offers a whole spectrum of ways to build an agent, from guided no-code (Agent Builder, SharePoint agents) through low-code (Copilot Studio) to pro-code (Agents Toolkit/SDK, Microsoft Foundry, your own code). Each has a different builder persona, grounding source, billing model and admin owner. The part that ties them together is Microsoft Agent 365, one control plane that observes, governs and secures every agent, regardless of where it was built.

TL;DR: There is no single right way to build an agent. Pick the lightest path that covers your use case, and don’t reach for pro-code when a SharePoint agent would do. Copilot Studio alone is three harnesses (Copilot chat, standard, GitHub Copilot), and there are official pro-code paths (Agents Toolkit/SDK, Foundry, your own code on IaaS) beyond the popular “five ways”. Whatever you choose, Microsoft Agent 365 governs it under one policy, identity and compliance layer.

ℹ️ This is a comparison and explainer page, not a how-to. Every capability, license and admin role below is validated against Microsoft Learn. If you remember one thing: choose the lightest path that solves your problem, and let Agent 365 handle governance across all of them.

Who should read this

🔸 Business users and site owners deciding whether they can self-serve an agent.

🔸 Makers choosing between Copilot Studio’s harnesses.

🔸 Pro devs deciding between Copilot Studio, Agents Toolkit/SDK and Foundry.

🔸 Admins (Global, AI, SharePoint, Power Platform) who need to know what to secure and who owns each control.

The map at a glance

#	Build path	Builder persona	Code level	Grounding / knowledge	Billing model	Admin who owns it
1	Agent Builder (in M365 Copilot)	Business user	No-code, guided	Public websites, SharePoint, OneDrive, Teams, Outlook, uploaded files, Copilot connectors (per-source limits)	Included in M365 Copilot; without a license, web-only is free and tenant data is metered in Copilot Credits	M365 / Copilot admin
2	SharePoint agent	Site owner	No-code	The site, pages, libraries, files it lives on	M365 Copilot license or pay-as-you-go	SharePoint admin
3	Copilot Studio, Copilot chat harness	Citizen dev / maker	Low-code	Enterprise knowledge surfaced into M365 Copilot Chat	Consumption or in M365 Copilot license	Power Platform / Copilot admin
4	Copilot Studio, standard harness	Citizen dev / maker	Low-code	Topics, prompts, connectors, knowledge you define	Copilot Credits; included in Microsoft 365 channels for M365 Copilot-licensed users	Power Platform admin
5	Copilot Studio, GitHub Copilot harness	Maker / pro dev	Low-code + reasoning	Connectors, knowledge, MCP, connected agents, files	Copilot Credits for all usage, including build and test; not covered by the M365 Copilot license	Power Platform admin
6	Agents Toolkit + Agents SDK	Pro dev	Pro-code (C#, JS/TS, Python)	Anything you code: OpenAPI, REST, MCP; custom engine agents bring their own model and orchestrator	Declarative agents: hosted by M365 Copilot, no hosting cost. Custom engine agents: your own hosting (for example Azure). Unlicensed users on shared tenant data: Copilot Credits	Dev + M365 admin
7	Microsoft Foundry (Foundry Agent Service)	Pro dev / AI engineer	Declarative to full code	Foundry model catalog, tools, your data	Azure (Foundry): per-call inference + tool usage, plus container compute for hosted agents	Azure / AI admin
—	Your own code on GPUs & Containers (IaaS)	Pro dev	Full code	Whatever you build (Agent Framework, Semantic Kernel, LangChain, OpenAI Agents SDK)	Azure IaaS + your stack	Azure / platform admin

⚠️ Reality check on “5 vs. more”: The popular “five harnesses” framing is a good starting point, but the official Microsoft picture is richer. Copilot Studio alone is three harnesses, and the M365 admin center’s Agent Map clusters agents by builder: Agent Builder, Copilot Studio, Copilot Studio Legacy, Microsoft 365 Agents Toolkit, SharePoint, Azure AI Foundry, and even third parties (Amazon Bedrock, Google Vertex AI). The honest answer: there are more than five, and that’s fine. The governance layer is what makes the sprawl manageable.

1) Agent Builder, for business users, guided and no-code

🔸 What it is. A natural-language builder inside Microsoft 365 Copilot (“New agent”) that creates declarative agents. They reuse Copilot’s model and orchestrator; you add instructions, knowledge and starter prompts.

🔸 What it can do. Describe the agent in plain English or configure it manually. Knowledge limits per agent: 4 public website URLs, 100 SharePoint files, 1 SharePoint list (up to 20,000 items), 50 OneDrive files, 5 Teams chats and 5 meetings, and 20 uploaded files. Copilot connectors (enabled by an admin) and Dynamics 365/Power Apps data (an admin enables Business Applications in Work IQ) have no documented numerical limit. Teams, Outlook email and people sources need a Microsoft 365 Copilot license. Skills are in preview and only available through the Microsoft Frontier Program. Test on the Try it tab, then share.

🔸 What it can’t do. No Actions to call external services, no complex multi-step logic. If you need those, Microsoft’s own guidance says: move up to Copilot Studio. Agents built here also can’t be used in Teams group or 1:1 chats, and Customer Managed Keys aren’t supported.

🔸 How to secure it. Governed by your Microsoft 365 Copilot license. The agent only returns what the user is already permitted to see. Admins block/allow agents in the M365 admin center (Copilot Control System).

🔸 Who it’s for. A coaching assistant tuned to our writing standards, or an onboarding helper for my team. If that’s your whole need, stop here. Don’t build in Copilot Studio.

🔸 Admin to involve: M365 / Copilot admin.

2) SharePoint agent, for site owners, on your own content

🔸 What it is. An agent created directly on a SharePoint site, grounded in that site’s pages, libraries and files. Represented as a .agent file that behaves like any Word/Excel document.

🔸 What it can do. Answer questions over specific sites, folders or files, in SharePoint and Teams chat. A site owner can pin one main agent that opens from the site’s global header.

🔸 What it can’t do. It won’t reach beyond the content you point it at, and (currently) blocking an agent only affects Copilot Chat availability, not OneDrive, SharePoint or Teams directly. A SharePoint agent can’t be published to the organization catalog.

🔸 How to secure it, the important part: responses honor each user’s permissions; .agent file permissions decide who can open/edit; restricted content discovery (SharePoint admin) turns off all agent features on a site; restricted access control limits a site to specific Entra/M365 groups (up to 10 per site, enable with Set-SPOTenant -EnableRestrictedAccessControl $true); Purview DLP with sensitivity-label conditions excludes sensitive items. Requires SharePoint Advanced Management for the advanced controls.

🔸 Who it’s for. My HR site should answer policy questions from its own library. Perfect no-code fit, with real oversharing controls.

🔸 Admin to involve: SharePoint admin (site owner builds; admin governs).

3-5) Copilot Studio, one product, three harnesses

In Copilot Studio, a harness is the runtime between your design and the model. The harness you pick changes billing, features and capabilities. There are three. You choose the harness when you create the agent, and an agent can’t be transferred to another harness.

3) Copilot chat harness, extend M365 Copilot Chat

🔸 Connect enterprise knowledge to Microsoft 365 Copilot Chat so employees get grounded answers without leaving Copilot. Publishes to internal teams. Billing is consumption-based or included in the M365 Copilot subscription. Best for: an onboarding agent answering from SharePoint knowledge.

4) Standard harness, rule-based and predictable

🔸 You define topics, prompts and paths; the agent responds consistently and can call your connectors and knowledge. Best for: an internal help-desk that answers common questions and routes simple requests, and for existing production agents that depend on established channels and features. Not for: open-ended reasoning. Billing: Copilot Credits, but included in Microsoft 365 channels for users with a Microsoft 365 Copilot license. Credits are billed when the user has no license or the channel is outside Microsoft 365. A working standard-harness agent doesn’t need to move just because the GitHub Copilot harness exists.

5) GitHub Copilot harness, reasoning-heavy and file-capable

🔸 The most capable option. Takes a goal, breaks it into steps, calls tools across connectors/knowledge/MCP/connected agents, and recovers when a step fails. Natively creates and edits Word, Excel, PowerPoint and PDF; supports skills and memory; runs each task in a secure sandbox. Best for: an accounts-payable agent that reads invoices, matches POs and routes exceptions.

🔸 Billing. All usage consumes Copilot Credits, and billing starts when you start building: creating, previewing, testing and evaluating count too. It isn’t covered by a Microsoft 365 Copilot license. Credits are managed per environment and agent in the Power Platform admin center. A simple task can cost more here than on the standard harness without a better result, so don’t use it as a default.

🔸 Good to know. It’s a Copilot Studio runtime, not the GitHub Copilot service, and customer data isn’t sent to GitHub. The Copilot Studio connector in Power Automate doesn’t support these agents; call them from a Copilot Studio workflow through an agent node. The preview upgrade from a standard agent creates a copy and doesn’t carry over knowledge sources, Power Fx expressions or child agents.

🔸 How to secure Copilot Studio (all harnesses): Power Platform environments + DLP policies, environment routing, geo/data-residency controls, and agent inventory/administration in Copilot Studio. Wrap risky connector calls in flows.

🔸 Admin to involve: Power Platform admin (plus Copilot admin for the chat harness).

✅ Clear boundary: If your scenario is predictable Q&A, use the standard harness. Don’t pay for reasoning you won’t use. If it’s a real multi-step process with files, use the GitHub Copilot harness. If you just want to enrich Copilot Chat, use the Copilot chat harness.

6) Agents Toolkit + Microsoft 365 Agents SDK, pro-code, your stack

🔸 What it is. The code-first path (VS Code, Visual Studio or CLI) for building declarative or custom engine agents in C#, JavaScript/TypeScript or Python. The SDK is model- and orchestrator-agnostic: plug in Azure Foundry, Semantic Kernel, OpenAI Agents or LangChain. For pro-code declarative agents, Microsoft now suggests starting with Work IQ Dev Tools (preview) when its lifecycle fits, and using the Toolkit directly for lower-level manifest and package control. Custom engine agents use the Toolkit and the Agents SDK.

🔸 What it can do. Full source control, PRs, CI/CD; custom API actions via OpenAPI/REST; surface agents across M365 Copilot and Teams. New capabilities often land here first.

🔸 What it can’t do. No drag-and-drop Power Platform connectors, no UI (you edit JSON), and agents built here can’t be reused in low-code Copilot Studio. Steeper learning curve. Microsoft Learn notes that publishing via the Toolkit isn’t supported in Microsoft 365 Government tenants, while the declarative-agent overview lists pro-code Toolkit support for GCC High and DoD. Check your cloud’s current status before you plan.

🔸 Who it’s for. We’re a dev team with an existing C#/Python agent and want it in Copilot with our own CI/CD.

🔸 Admin to involve: Dev team + M365 admin (for publishing/sideloading).

7) Microsoft Foundry, enterprise and multi-agent, declarative to full code

🔸 What it is. Foundry Agent Service, a managed platform to build, deploy and scale agents. It meets you anywhere on the spectrum: a prompt agent (declarative), a voice-based prompt agent (managed real-time voice), a hosted agent (your packaged code), or call the Responses API from an agent you run elsewhere.

🔸 What it can do. Any framework for hosted agents (for example Microsoft Agent Framework, LangGraph, OpenAI Agents SDK), any supported model from the Foundry catalog, shared toolboxes (web search, file search, code interpreter, MCP servers, custom functions), tracing, evaluations and monitoring. Each agent can have its own Microsoft Entra identity, with RBAC, private networking and content filters, and you can publish to Microsoft Teams and Microsoft Copilot.

🔸 Multi-agent, status October 2026. The classic Connected Agents tool is deprecated, and Agents (classic) retire on March 31, 2027. In the new Agent Service, use Microsoft Agent Framework workflows or the agent-to-agent (A2A) tool. Foundry’s visual workflow designer (preview) retires on December 1, 2026.

🔸 What it can’t do. It’s an Azure/PaaS commitment, heavier than Copilot Studio for simple internal Q&A. Overkill if you don’t need multi-agent scale or custom models.

🔸 Who it’s for. We’re building a multi-agent system at enterprise scale with our own models and Azure governance.

🔸 Admin to involve: Azure / AI admin.

ℹ️ Also official: For maximum control you can run your own code on GPUs & Containers (IaaS) with frameworks like Microsoft Agent Framework, Semantic Kernel, LangChain or OpenAI Agents SDK, the third platform alongside Foundry (PaaS) and Copilot Studio (SaaS). Only go here when PaaS/SaaS genuinely can’t meet your requirements.

The real story: Microsoft Agent 365, one governance layer for all of them

However the agent was built, Agent Builder, SharePoint, Copilot Studio, Agents SDK, Foundry, LangChain, even Amazon Bedrock or Google Vertex AI on AWS/GCP, Microsoft Agent 365 is the central control plane. It stops “agent sprawl” by giving every agent a managed identity and a single place to observe, govern and secure it.

🔸 Observe: a central registry, Agent Map, hero metrics and auto-instrumented observability into agent activity, access patterns and risk.

🔸 Govern: lifecycle management, access control and compliance guardrails via Microsoft Entra, Microsoft Purview and the Microsoft 365 admin center; onboard/approve agents through one IT-controlled flow, flag ownerless agents, retire risky ones.

🔸 Secure: risk-based access with Entra Agent ID (scoped, time-bound tokens; Conditional Access; Identity Protection), threat detection with Microsoft Defender, and data protection with Microsoft Purview (DLP, information protection).

🔸 Under the hood: identity, security, data protection/compliance and device management come from Microsoft Entra, Microsoft Defender, Microsoft Purview and Microsoft Intune.

🔸 The agent blueprint: an IT-approved, pre-configured definition of an agent type (capabilities, required tool access, security/compliance constraints, audit requirements, linked DLP/external-access/logging policies). Every agent instance inherits its blueprint’s rules, so governance is consistent across mail, calendar, Teams and SharePoint.

🔸 Licensing: Agent 365 is included with Microsoft 365 E7 or available as a standalone subscription. Agent Map requires an E7 (Agent 365) license and a Global Administrator or AI Administrator role.

✅ So the organizational question is no longer “no-code or pro-code?” It’s “which path fits this use case, without sacrificing governance?” With Agent 365, the governance answer is the same no matter which builder you choose.

Decision guide, pick the lightest path that works

🔸 Just answer questions over one SharePoint site? SharePoint agent. Nothing more.

🔸 A personal/team helper grounded in M365 content, no external calls? Agent Builder.

🔸 Enrich Microsoft 365 Copilot Chat with company knowledge? Copilot Studio, Copilot chat harness.

🔸 Predictable, rule-based Q&A or routing? Copilot Studio, standard harness.

🔸 A real multi-step business process with files and tool calls? Copilot Studio, GitHub Copilot harness.

🔸 A dev team that wants full code, CI/CD, custom APIs, any model? Agents Toolkit + Agents SDK.

🔸 Multi-agent system at enterprise scale with custom models? Microsoft Foundry.

🔸 Requirements PaaS/SaaS can’t meet? Your own code on IaaS.

And in every case: govern it with Microsoft Agent 365.

🛠️ FAQ

Are there really only “five ways”?

No, that’s a useful simplification. Officially, Copilot Studio is three harnesses, and the Agent Map recognizes Agent Builder, Copilot Studio (plus Legacy), Agents Toolkit, SharePoint, Azure AI Foundry and third-party builders. Think spectrum, not a fixed five.

What’s the difference between the GitHub Copilot harness and Agents Toolkit / SDK?

The GitHub Copilot harness is a low-code runtime inside Copilot Studio for reasoning-heavy agents. Agents Toolkit/SDK is pro-code outside Copilot Studio (VS Code/CLI, your own languages and orchestrators). Different personas, different tools.

Is the GitHub Copilot harness the same as GitHub Copilot?

No. It’s an authoring and runtime framework inside Microsoft Copilot Studio. It shares technology with GitHub Copilot, but customer data isn’t sent to or processed by the GitHub Copilot service.

Does a GitHub Copilot harness agent cost Copilot Credits even with a Microsoft 365 Copilot license?

Yes. Building, testing, evaluating and running these agents consumes Copilot Credits, and that usage isn’t included in the user’s license. Details in Copilot Studio vs Microsoft 365 Copilot.

Can I move an agent from one harness to the other?

Not directly, agents can’t be transferred between harnesses. Microsoft offers a preview upgrade that copies a standard agent to the GitHub Copilot harness (instructions, tools and suggested prompts carry over), and recommends treating a move as a re-architecture that must show a clear benefit.

Does Agent 365 only govern Microsoft-built agents?

No. It governs agents built on any SDK/platform and hosted anywhere, including LangChain, OpenAI Agents SDK and agents on AWS/GCP, plus Bedrock/Vertex agents surfaced in the Agent Map.

Which admin do I actually talk to?

SharePoint agent: SharePoint admin; Agent Builder: M365/Copilot admin; Copilot Studio: Power Platform admin; Foundry/IaaS: Azure/AI admin; tenant-wide agent governance and Agent Map: Global or AI Administrator (E7).

How do I stop an agent from oversharing SharePoint content?

Combine permission-trimmed responses, restricted content discovery, restricted access control (Entra/M365 groups) and Purview DLP. See the SharePoint agent section above and the tenant readiness checklist.

What is the easiest way to build an agent in Microsoft 365?

For questions over one SharePoint site, a SharePoint agent. For a personal or team helper grounded in Microsoft 365 content without external calls, Agent Builder. Move to Copilot Studio only when the agent needs connectors, flows or a wider audience.

When do I need Copilot Studio instead of Agent Builder?

When the agent has to enrich Microsoft 365 Copilot Chat with company knowledge (Copilot chat harness), handle predictable rule-based Q&A or routing (standard harness), or run a multi-step business process with files and tool calls (GitHub Copilot harness).

🔗 Related

🔸 Get your tenant agent- and Copilot-ready (10-point checklist), the governance companion to this page.

🔸 M365 Copilot vs Copilot Studio, which Copilot builds agents that take action.

🔸 Computer use (CUA) in Copilot Studio, let an agent operate any app by describing the task.

🔸 All AI & Copilot tips · Knowledge base overview

Sources: Microsoft Learn: Agent Builder (overview and knowledge sources), SharePoint agents, Compare Copilot Studio agent harnesses, Manage costs for agents powered by the GitHub Copilot harness, Plan licensing and cost for Microsoft 365 Copilot extensibility, Compare tools for declarative agents, Microsoft 365 Agents SDK/Toolkit, Microsoft Foundry Agent Service (overview, hosted agents, workflow migration), Cloud Adoption Framework (AI agents), and Microsoft Agent 365 (overview, Entra/Purview/Defender capabilities, Agent Map, agent blueprint, licensing). Last checked October 13, 2026. Details reflect Microsoft Learn at time of writing and evolve quickly, so always confirm current capabilities and licensing in the official documentation.