Featured image of post Which Copilot Feature for Which Job: A Four-Level Map With Agent Governance

Which Copilot Feature for Which Job: A Four-Level Map With Agent Governance

Chat, in-app Copilot, agents, Copilot Studio or Cowork? How to place each Copilot feature on a four-level map, and why every agent needs an owner.

Copilot Chat, Copilot in Word, Agent Builder, SharePoint agents, Copilot Studio, Cowork: that’s just the list for this quarter. Every month brings another entry point, and every new one gets the same question from users and stakeholders: “So should we use this now instead?” Answering it means knowing which tool fits which job, and keeping the agents you build from turning into the next generation of orphaned Power Automate flows.

TL;DR

  • Think of Copilot as four levels: ad hoc chat → Copilot inside the apps → agents → Copilot Studio and Cowork-style automation.
  • Four questions decide the level: Does it happen more than once a week? Does it use the same sources or tone every time? Is it rule-based? Does it span multiple systems and approvals? More “yes” answers mean a higher level.
  • The higher you go, the more governance you need, but one rule applies on every level: no agent without an owner. As of October 2026, the Agent 365 registry in the Microsoft 365 admin center shows you which agents are missing one.

A quick note on names

Microsoft has renamed things again: Microsoft 365 Copilot is now Microsoft Copilot, and Microsoft 365 Copilot Chat is now Microsoft Copilot Chat, with the app moving to copilot.cloud.microsoft. Licences, portals and docs will show both names for a while. I’m using the new names below. If your users are confused, that’s one more reason to give them a map instead of a product list.

The map: four levels

The idea comes from Patrick Kelbch’s session at M365 Con D-A-CH, and I like it because it organises things by the kind of work, not by product. Here’s how I’d fill it in with what’s actually available today:

LevelWhat it isTypical jobLicence / cost (simplified)Who governs it
1 – ChatCopilot Chat in the Copilot app, Edge, Teams, OutlookAd hoc questions, drafting, summarising something you paste or uploadIncluded with eligible Microsoft 365 plans (web-grounded); work-grounded chat needs a Copilot licenceCopilot settings in the Microsoft 365 admin center
2 – In the appsCopilot inside Word, Excel, PowerPoint, Outlook, TeamsMeeting recap, inbox triage, first PowerPoint draft from a documentBasic in-app features for eligible users; the full experience with a Microsoft Copilot licenceSame as above, plus your data foundation (permissions, labels)
3 – AgentsAgent Builder agents, SharePoint agents, agents from the Agent StoreA reusable assistant with fixed instructions and knowledge, e.g. a project FAQIncluded with a Copilot licence; without one via pay-as-you-go (web-only agents are free)Agent registry in the Microsoft 365 admin center
4 – AutomationCopilot Studio agents (flows, triggers, autonomy) and Copilot CoworkMulti-step processes across systems, with approvalsCopilot Studio: Copilot licence or Copilot Credits; Cowork: Copilot licence plus usage-based billingPower Platform admin center + Agent 365 + Cost Management

The line between level 1 and 2 is now drawn by licensing more than by technology. Users without a Copilot licence get basic Copilot features in Word, Excel and PowerPoint, and Copilot Chat in Outlook and Teams can work with the content you have open. For users, it all looks like “Copilot in the app”. For you, the difference matters because it decides whether Copilot can reach into their mailbox, chats and files by itself, or only sees what they hand it.

Level 4 has two very different branches. Copilot Studio is process-centric: a maker builds an agent with topics, agent flows and event triggers, and it runs for many users, sometimes without anyone prompting it. Cowork is person-centric: a user delegates an outcome (“prepare the steering committee pack from last week’s mails and the project site”), Cowork plans the steps, works across Outlook, Teams, OneDrive and SharePoint, and asks for approval before sensitive actions. Microsoft calls Cowork an agentic system rather than an agent, and it’s governed through spending policies rather than the agent registry.

Four questions to find the right level

When a new use case or a new feature shows up, run it through four questions:

  1. Does it happen more than once a week? If not, stay on level 1 or 2. Building something reusable for a one-off is overkill.
  2. Does it use the same sources or the same tone every time? If yes, you’re looking at an agent (level 3): instructions plus a fixed knowledge base beat re-typing the same prompt.
  3. Is it rule-based? If the steps are predictable (“when X arrives, check Y, then do Z”), you want deterministic logic: a Copilot Studio agent with topics or agent flows (level 4).
  4. Does it span multiple systems and need approvals? Then you need level 4 with real process design: connectors, human-in-the-loop steps, and someone thinking about the credentials the agent runs with.

The more “yes” answers, the higher you climb. If you can’t answer yes, don’t climb: an agent nobody uses still has to be inventoried, reviewed and eventually retired.

Decision tree: which Copilot level for a use caseFour questions lead from a new use case to the right level: less than weekly or without the same sources stays at level 1/2. Without rule-based steps, level 3 is enough; without multiple systems and approvals, level 3/4; otherwise level 4.New use caseMore than oncea week?Same sourcesor tone?Rule-basedsteps?Multiple systemsand approvals?Level 1/2Chat or Copilot in the appLevel 3Agent Builder orSharePoint agentLevel 3/4Agent with actionsin Copilot StudioLevel 4Copilot Studio flowsor Coworknoyesnoyesnoyesnoyes

I’d add one question of my own, and it’s the first one I ask in regulated environments: who will own this when it breaks? If nobody raises their hand, the use case stays on level 1 or 2, however good the idea is.

Governance per level, and an owner for every agent

On levels 1 and 2, governance is mostly about your data foundation: oversharing, sensitivity labels, permissions. Copilot only shows users what they can already access, which is exactly why messy permissions show up the moment Copilot is switched on.

From level 3 upward, you’re managing objects that live on: agents with knowledge, actions and sometimes their own identity. The session had a checklist for these; here’s how each item maps to current tooling:

An owner for every agent. The agent registry in the Microsoft 365 admin center (Agents > All agents > Registry) lists agents across platforms (Copilot Studio, Agent Builder, partner and Microsoft agents) and shows Agents without owners as a top-level number. Viewing the inventory doesn’t need an extra licence, only the right role; AI Reader is the least-privileged option. Assigning a new owner requires AI Administrator (or Global Administrator).

Owner vs. sponsor. For agents with a Microsoft Entra Agent ID, Entra separates two roles: the owner handles technical operations, while the sponsor is the business person accountable for whether the agent should still exist and what access it gets. Every agent identity needs at least one sponsor, and if a sponsor leaves the organisation, sponsorship transfers automatically to their manager. Use both roles. “IT built it” is not the same as “the business needs it”.

Approval for actions. Cowork asks for approval before sensitive actions. In Copilot Studio, you design it yourself: human-in-the-loop steps in agent flows for anything high-impact or irreversible. One detail worth knowing: event triggers in Copilot Studio authenticate with the maker’s credentials, so users of a published agent may reach data through the maker’s access. Least privilege applies to makers too.

One registry. Microsoft is converging the agent views from Entra and the Microsoft 365 admin center into Agent 365, so you end up with one inventory instead of three. Agents from other platforms can be synced into the registry as well.

Entra ID sprawl under control. Every agent with its own identity adds objects to your directory: blueprints, agent identities, possibly agent users. Treat them like any other non-human identity: Conditional Access, access packages with expiry, and lifecycle workflows that catch sponsor changes.

Lifecycle, licensing and cost. Agents can be blocked, deleted (with a 30-day recovery window) and reassigned from the admin center. On the cost side, Cowork and other usage-billed experiences run on Copilot Credits and are managed under Copilot > Cost Management.

A quick inventory with Microsoft Graph

If you want the registry in a script, for a monthly report or a review with the business, there’s a Package Management API in Microsoft Graph. It’s available on v1.0, needs CopilotPackages.Read.All (delegated or application), and requires a Microsoft Agent 365 licence.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# Requires: Microsoft.Graph.Authentication, permission CopilotPackages.Read.All
Connect-MgGraph -Scopes "CopilotPackages.Read.All" -NoWelcome

# Only packages that surface in Copilot, i.e. agents
$uri = "https://graph.microsoft.com/v1.0/copilot/admin/catalog/packages?`$filter=supportedHosts/any(h:h eq 'Copilot')"
$agents = while ($uri) {
    $page = Invoke-MgGraphRequest -Method GET -Uri $uri
    $page.value
    $uri = $page.'@odata.nextLink'   # follow paging until no nextLink is returned
}

$agents |
    Select-Object displayName, type, platform, publisher, isBlocked, availableTo, deployedTo, lastModifiedDateTime |
    Sort-Object lastModifiedDateTime |
    Export-Csv -Path .\agent-inventory.csv -NoTypeInformation -Encoding utf8

Sorting by lastModifiedDateTime is a cheap first lifecycle check: agents that haven’t changed in a year are the first ones to review. For ownership, the Agents without owners view in the admin center is still the quickest way in.

Things to watch out for

  • A spending policy is an access control as well as a budget. For Cowork, anyone in scope of a policy that selects Cowork gets access, even if the limit is a single credit. To keep someone out, keep them out of the policy.
  • “Auto-apply new services” is on by default in spending policies. New usage-billed services can be covered automatically. If you’d rather review every new service first (a reasonable stance under NIS2-style change control), switch it off.
  • Set per-user limits. Otherwise one enthusiastic user can use up the whole month’s credits.
  • Agent 365 licensing is tiered. The registry inventory and basic actions (block, delete, reassign owner) come with Microsoft 365 Enterprise, Business, Education and Frontline plans. Policy templates, observability, tenant-wide tool control and the Graph API need Microsoft 365 E7 or Agent 365. Check the service description before you promise a feature.
  • Names and admin paths keep moving. The rename to Microsoft Copilot is recent; screenshots in your internal docs will be out of date sooner than you think.

Wrap-up

Build the map once, then place every new Copilot feature on it instead of debating it from scratch. Use the four questions to decide how high a use case should go, and be strict about the extra one: if nobody owns it, it doesn’t get built. For the agents you already have, the registry shows you exactly where an owner is missing.

Which level are most of your users on today, and how many agents in your registry are already missing an owner?

References

Inspired by a post from Marcel Broschk on LinkedIn summarising the session “Copilot everywhere: Chat, Agents, Automatisierung: wie finde ich mich noch zurecht?” by Patrick Kelbch at M365 Con D-A-CH.