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	SharePoint, Teams, Outlook, web, Copilot connectors (up to 20 sources)	Included in M365 Copilot license (or PAYG)	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	Standard harness messages	Power Platform admin
5	Copilot Studio, GitHub Copilot harness	Maker / pro dev	Low-code + reasoning	Connectors, knowledge, MCP, connected agents, files	Copilot Credits (usage)	Power Platform admin
6	Agents Toolkit + Agents SDK	Pro dev	Pro-code (C#, JS/TS, Python)	Anything you code: OpenAPI, REST, MCP; any model/orchestrator	Your Azure/hosting + M365 metering	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) consumption	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. Up to 20 knowledge sources (SharePoint sites/folders/files, Copilot connectors); with a Copilot add-on you can also ground in Teams messages and Outlook. 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.

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

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

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. Not for: open-ended reasoning.

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. Uses Copilot Credits. Best for: an accounts-payable agent that reads invoices, matches POs and routes exceptions.

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

🔸 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; publishing via Toolkit isn’t supported in M365 Government tenants.

🔸 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 hosted agent (your packaged code), or call the Responses API from an agent you run elsewhere.

🔸 What it can do. Any framework, any supported model from the Foundry catalog, built-in tools, memory, tracing, evaluations and multi-agent orchestration (connected agents, Microsoft Agent Framework). Unified RBAC, networking, policies under one Azure namespace.

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

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.

🔗 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, SharePoint agents, Copilot Studio harnesses and agents overview, Microsoft 365 Agents SDK/Toolkit, Microsoft Foundry Agent Service, Cloud Adoption Framework (AI agents), and Microsoft Agent 365 (overview, Entra/Purview/Defender capabilities, Agent Map, agent blueprint, licensing). Details reflect Microsoft Learn at time of writing and evolve quickly, so always confirm current capabilities and licensing in the official documentation.