Agent Builder vs Copilot Studio: Pick the Tool, Then Govern It

Microsoft gives business users two no-code places to build an agent: Agent Builder inside the Microsoft 365 Copilot app, and Copilot Studio. Both carry the Copilot name, so most people assume Studio is simply the advanced version and pick by comfort level. That's the wrong test. The real line is what the agent has to do, and the choice quietly decides which admin console governs it.

I went through Lisa Crosbie's walkthrough, published October 26, 2026, and Microsoft's own admin documentation. I haven't tested every connector or environment configuration, so this post sticks to what the video shows and what Microsoft documents. It gives you a four-question test for picking the tool, explains what the Copy to Copilot Studio button actually does, and lays out the two governance decisions admins should make before the next agent ships.

What Agent Builder is, and where it stops

Agent Builder scopes Copilot down. You describe a goal in plain language, and it turns that into instructions, skills, and knowledge sources such as SharePoint folders, cloud files, Outlook, or Teams chats. Crosbie's point is that you stop retyping the same long prompt. The agent then lives inside Copilot and nowhere else: sharing sends a link, and the recipient pins it in their own Copilot, working with whatever they already have access to.

Microsoft's comparison table puts it the same way. Agent Builder is for information workers building lightweight question and answer agents for individuals or small teams. Copilot Studio is for makers building agents for a department, the whole organization, or external customers, with multi-step workflows and business system integration. The Agent Builder overview is blunt about the boundary: it "doesn't support authoring actions that integrate external services."

Licensing follows a similar split. Both tools are included with a Microsoft 365 Copilot license. Without one, agents built only on instructions or public websites cost nothing extra, while agents that ground on shared tenant data such as SharePoint are metered in Copilot Credits through Copilot Studio.

The four-question test

Before you open either tool, answer these:

1. Does the agent need to act in another system? Sending the email instead of drafting it, raising a ServiceNow ticket, or updating a CRM record all count.
2. Does it need to run on a schedule, with nobody asking? Crosbie's example is "every Monday do this," which Agent Builder can't do.
3. Does it need to live somewhere other than Copilot? A Teams channel, a website, or a customer-facing app.
4. Is it running a business process for a team or the organization, rather than your own productivity?

If every answer is no, stay in Agent Builder. It's faster, it needs no publishing decisions, and it respects each user's existing permissions. One yes, and the agent belongs in Copilot Studio, where you get tools and connectors, channels, triggers, and development, test, and production environments.

The bridge is a save-as, not a migration

Agent Builder has a Copy to Copilot Studio option under the More options menu. Crosbie calls it a save-as, and Microsoft's copy documentation backs that up. The name, description, instructions, suggested prompts, icon, and SharePoint and website knowledge come across. Embedded files, Teams chats and meetings, emails as knowledge, scoped Copilot connectors, and image generation do not. You reconnect those in Studio, mostly through Power Platform connectors.

Three details matter for governance. The original agent stays in Copilot, still shared with whoever had it. Every copy operation creates a new Studio agent. And the copy lands in a Power Platform environment the maker selects, which must have Dataverse and in which the maker needs a security role. Microsoft's own advice after you publish the Studio version is to decide whether to delete the original and tell the people you shared it with.

Two consoles, two sharing switches

This is the part the demos skip. Agent Builder agents are governed in the Microsoft 365 admin center. Under Agents, the Sharing setting controls who can share agents with the whole organization: all users, specific users or groups, or no users. Two details are easy to miss. The default is All users, and changing it applies only to new sharing actions, so anything already shared stays shared. Even with No users selected, people can still share directly with specific individuals.

Copilot Studio agents are governed in the Power Platform admin center. Data policies can block individual connectors, channels, knowledge sources, HTTP requests, and the event triggers that let agents run autonomously, and Microsoft has enforced them on all tenants since early 2025. Sharing limits in Managed Environments control Editor and Viewer rights, block sharing with security groups, and cap the number of viewers, though they apply only to agents that require authentication. Publishing to the organization's app catalog requires admin approval.

Microsoft also warns, in the copy documentation, that the sharing limit in the Microsoft 365 admin center is different from the one in the Power Platform admin center. Setting one does nothing to the other. Both consoles do share one backstop: admins can block any Agent Builder or Copilot Studio agent tenant-wide from Agents, All agents.

What admins should decide this week

1. Set the Agent Builder sharing option on purpose. If org-wide sharing should be limited to a group of champions, set that group now rather than inheriting All users. Then review what's already shared, because the change isn't retroactive.
2. Pick where copied agents land. Turn on environment routing or point makers at a governed development environment, so Copy to Copilot Studio doesn't drop agents somewhere with no data policy.
3. Name who approves the move to Studio, and who approves publishing to the catalog. That's the moment an agent starts taking actions with real connectors.
4. Write down the four questions and put them where people request agents, so the tool choice gets made before anyone builds.

For context on why this is worth an afternoon: a vendor-sponsored ShareGate survey of about 1,800 IT professionals, summarized by 2toLead, found 77% of organizations reported at least one Microsoft 365 governance incident, and 65% learn of governance problems only after the fact. ShareGate sells governance tooling and the data is self-reported, so treat it as context. The documented defaults are the stronger argument.

The limitation

The line moves. Crosbie says her walkthrough is accurate "at the time of recording," and Microsoft keeps adding Agent Builder features; skills, for example, are in preview for Frontier program tenants. Microsoft also documents downloading an Agent Builder agent as a ZIP package to sideload into Teams, so "only in Copilot" has an asterisk. The sanctioned path for broad distribution is still Studio with admin approval. That's why I'd lean on the four questions rather than a feature checklist, and recheck the docs before settling an argument with them.

The takeaway

The choice between Agent Builder and Copilot Studio isn't about how technical you are. It's about whether the agent acts, runs on its own, leaves Copilot, or runs a team process, and each answer puts it under a different admin console with its own sharing rules. Run the four questions on the next agent you build, before you open either tool.