Ask three people in the same organisation what a Copilot agent is and you get three honest, incompatible answers: the thing a site owner made on the intranet, the thing someone built by describing it in Copilot chat, and the thing the automation team ships from Copilot Studio. All three are called agents. They are billed through different paths, governed in different admin centres, and shared under different rules, and most confusion in this space comes from advice about one type being applied to another.
This guide lays out the three surfaces one at a time, then the comparison matrix, then the governance steps per type. Everything here is drawn from Microsoft's capacity and pay-as-you-go documentation as at August 2026.
SharePoint agents: made on sites, billed through Microsoft 365
SharePoint agents are created by site users directly on a SharePoint site and grounded in that site's content, respecting the permissions the reader already has. Billing is the most mechanical of the three: every interaction consumes 12 messages, made of 2 for the generative answer and 10 for tenant graph grounding, because SharePoint agents always ground in the tenant graph. For users with a Microsoft 365 Copilot licence, interactive use is included in the seat. For everyone else, usage bills through pay-as-you-go at the standard credit rate, which puts an unlicensed interaction at about US$0.12.
The setup is Microsoft 365 admin centre work, not Power Platform work: create a pay-as-you-go billing policy under Copilot > Billing & usage, backed by an Azure subscription and resource group, then connect the policy to the SharePoint agents service. The current policy model has a governance bonus: each billing policy takes a security group, only users in that group can use SharePoint agents under it, and you can run up to 10 policies to split cost across teams or subscriptions. The charges land on the Copilot Studio meter of the Azure invoice, with the per-feature breakdown visible in Microsoft Cost Management, which is where budgets and alerts belong.
Agent Builder: made in Copilot, governed in the Microsoft 365 admin centre
Agent Builder is the lightweight authoring surface inside Microsoft 365 Copilot: natural-language creation, aimed at individuals and small teams, no code and no Power Platform environment. Its governance principles are the simplest of the three because agents grant no new privileges; they only surface content the user could already open, and standard audit logs, DLP and retention apply.
- Billing: agents grounded only on web knowledge are free to use. Agents that touch tenant data (SharePoint, Teams, Outlook) need the user to hold a Microsoft 365 Copilot licence, or bill through Copilot Credits pay-as-you-go. A documented quirk in the rates table: generative answers from Agent Builder agents that do not use tenant grounding are not charged.
- Admin controls: the Microsoft 365 admin centre's Copilot > Agents page carries the inventory, and lets admins enable, disable, assign, block or remove agents, and configure pay-as-you-go and usage reporting.
- Sharing: governed from Copilot > Settings > Data access > Agents, where admins set the sharing controls for user-built agents.
Copilot Studio agents: made by makers, governed in Power Platform
Copilot Studio is the full product: multi-step logic, connectors beyond Microsoft 365, autonomous triggers, external channels, and application lifecycle management across dev, test and production environments. Its agents live in Power Platform environments, which is why every governance lever is in the Power Platform admin centre: environment strategy, data policies on connectors, sharing controls and limits, per-agent consumption caps, and the environment-to-Azure-subscription billing policies that carry pay-as-you-go. Publishing into the organisation's app catalog requires admin approval. Capacity is Copilot Credits, through prepaid packs or the PAYG meter, and usage by Microsoft 365 Copilot licensed employees inside Microsoft 365 surfaces is included in their seats for the core features. Frontrow's guide at /insights/copilot-agents-australian-playbook covers the build path for this type in detail.
The matrix
Four dimensions cover almost every decision. Read each line as SharePoint agents, then Agent Builder, then Copilot Studio.
- Billing path: M365 pay-as-you-go billing policy connected to the SharePoint agents service, 12 messages per interaction for unlicensed users · included with a Microsoft 365 Copilot seat or Copilot Credits PAYG, web-only agents free · Copilot Credit prepaid packs or PAYG on an Azure billing policy per environment.
- Where it lives: the SharePoint site · the user's Microsoft 365 Copilot context · a Power Platform environment with full ALM.
- Where admins govern it: Microsoft 365 admin centre (Copilot > Billing & usage, plus SharePoint site controls) · Microsoft 365 admin centre (Copilot > Agents, and Copilot > Settings > Data access > Agents) · Power Platform admin centre (environments, data policies, sharing controls, Manage Agents caps).
- Sharing rules: reach follows site access, and billing-policy security groups gate who can use agents at all · admin-set sharing controls on the Agents data-access page · maker sharing governed by sharing controls and managed environment limits, with admin approval to publish org-wide.
- Who can consume without extra cost: Microsoft 365 Copilot licensed users, in all three cases, for the core interactive features; everyone else meters.
Governance steps per type
- 1SharePoint agents: decide the licensing posture first, because unlicensed usage cannot happen at all until an admin connects a billing policy. If you do connect one, use the security group on the policy as the access gate, set an Azure budget with an action group on the subscription, and keep agent-bearing sites tightly permissioned since reach follows site access.
- 2Agent Builder: review the Copilot > Agents inventory monthly, block or remove what should not exist, and set the sharing controls under Data access > Agents so personal experiments cannot quietly become department infrastructure. Remember the content boundary is the user's own permissions, so oversharing risk is really a SharePoint permissions problem.
- 3Copilot Studio: everything in Frontrow's creation-controls checklist applies (locked default environment, data policies, governed maker environment), plus per-agent consumption caps in Manage Agents and a preference for prepaid packs on autonomous agents so the capacity enforcement backstop exists.
- 4Across all three: keep one register of every agent, its type, its owner and its billing path. The three inventories live in two different admin centres, and the organisations that get surprised are the ones reading only one of them.
Try it
Map your agent opportunities properly
Work out which processes justify a governed Copilot Studio build versus a lightweight Agent Builder or SharePoint agent.
3 questions · 90 seconds
Which agents would augment your team first?
Pick your industry, team size, and the top three back-office queues currently clogging your team. Frontrow returns the agent recommendations that fit, with what each one would augment.