General

From Counting Users to Counting Agents: The ITAM and FinOps Role in the Agent Economy

Copilot readiness is a governance problem, not a licensing exercise. The ITAM and FinOps role is evolving from counting users to counting agents.

By Tony Mackelworth, CEO at Softspend 11 min read
  • ARPA
  • Copilot
  • Agent 365
  • Agent Economy
  • Copilot Readiness
  • FinOps
  • FinOps for Microsoft 365
  • softspend
  • Zero Trust

Why Copilot readiness is really a governance problem, and how the ITAM and FinOps role changes when the unit of consumption stops being the user.

This article is adapted from a recent conversation I had with Shaun Ashbury on the Off-Menu IT podcast. The discussion was aimed squarely at the ITAM and FinOps community, and the central argument is one I think that community needs to internalise quickly: the assumptions that have governed Microsoft licensing for a decade do not survive contact with the agent economy.

What Copilot readiness actually means

Most of the market treats Copilot readiness as one of three things, and all three miss the point:

  • The licensing motion. Buy the seats, assign the licences, declare victory.

  • The cultural motion. Enablement sessions, prompt training, adoption workshops.

  • The adoption lens. Tracking seats assigned, active users, and prompt volume.

    This is the one that looks most rigorous, and it is worth doing because it informs ROI. But it measures whether people are using Copilot. It tells you nothing about whether the data Copilot can reach is secured.

All three matter. None of them are readiness. The security foundation is the part many partners don't address at outset.

Readiness is a data governance problem. When you give Copilot access to your organisation's information, you are handing an AI the security posture of the identity that spawned it. If your identity, access, and information protection controls are weak for a user, they are weak for that user's Copilot, and they get amplified at machine speed. Oversharing does not become a risk with Copilot. It becomes an instant, queryable risk.

So the real readiness question is not "have we bought the licences?" It is "what is the current configuration state of our Microsoft 365 security stack, and is it effective?" That means looking hard at Defender, Purview, and Entra, the products that determine what Copilot can see and act upon, before switching anything on.

Licensed, activated, configured, effective

There is a chain hiding inside every readiness assessment, and most assessments stop at the first link.

Level

The question it answers

Why it is not enough on its own

1. Licensed

Does the tenant hold entitlement to the SKU, and is it assigned to the user?

Entitlement says nothing about whether the capability is actually switched on.

2. Service plan activated

Is the specific service plan inside that SKU enabled in the tenant?

A user can hold an E5 licence while the service plan that delivers a given control sits switched off.

3. Configured

Are the policies behind the activated capability set up?

An activated service plan does nothing useful until the policies behind it exist.

4. Effective

Is the feature rolled out in a way that materially improves posture in this environment?

Configuration on paper is not the same as protection in practice.

A Microsoft 365 SKU is not a single switch. It is a bundle of service plans, and each one can be enabled or disabled in the tenant. Entitlement alone therefore tells you nothing; you have to confirm the relevant service plan is activated, that it is configured down to individual feature level, and that the configuration is effective against a meaningful threshold.

This is the shift in the ITAM and FinOps mandate. The discipline has historically asked whether a licence is assigned to a user and whether it is being used. For the Microsoft security stack, that is no longer sufficient. You cannot advise a customer to downgrade from E5 to E3, or (more often) to upgrade, unless you know what is actually activated and whether it is doing anything. Anything presented without that visibility is, at best, a guess.

Frameworks give readiness a standard

The threshold for "effective" should not be whatever an individual consultant happened to think on the day. That does not scale, and it is not repeatable across a tenant fleet. The answer is to align configuration to a recognised industry framework. There is no single golden bullet, but a few stand out:

  • CIS Benchmarks for Microsoft 365. Common in the market, and they map reasonably well to tiered E3 and E5 topologies, which makes them a strong starting point.

  • Microsoft Secure Score. A built-in signal you can baseline and trend against.

  • Microsoft Zero Trust. Architectural direction across identity, device, and data controls.

  • Copilot Control System. An emerging, readiness-specific control set.

Aligning to a framework does two things. It lets a partner deliver assessments to a defensible, standardised level across a whole fleet rather than per consultant. And it reframes the upgrade conversation entirely. There is a world of difference between telling a client "upgrade to E5" and telling them "here is the framework maturity tier your organisation needs, and here is the gap between where you are and what you already own." The second is a conversation a customer can act on. The first is a sales pitch.

The spreadsheet cannot survive the agent economy

For years, the licensing optimisation exercise has looked like this: a specialist sits in a room with an Excel spreadsheet and a list of Microsoft 365 features, going yes, no, yes, no, down the column. Then they go away and build the cost model by hand. The leading consultancies still charge large enterprises a great deal of money for exactly this.

That model is already creaking under the weight of monthly Microsoft licensing changes and the sheer number of feature-level checks a proper baseline assessment now requires. The agent economy breaks it completely. The spreadsheet is dead. It cannot keep pace with the change cadence, and it certainly cannot accommodate the volume of checks that agent governance will demand.

This is the problem we built Softspend to solve. There are more than 300 Microsoft 365 features mapped to over 50 suites, an impossible amount to track by hand. In effectively one click, the platform connects to a client's environment and surfaces:

  • what the tenant is licensed for;

  • what is actually activated at feature level;

  • the most efficient licensing path, based on either current usage or a future roadmap.

The manual yes/no analysis and the cost modelling that used to take a week become near-instant.

To be clear, this does not remove the licensing expert. It scales them. The ecosystem has deeply experienced FinOps, SAM, and licensing people, often in teams of fewer than five, supporting large enterprises and being pulled in every direction by sales and pre-sales. Technology lets them do the analysis faster and spend their time on the part machines cannot do: understanding the business and connecting with the client. They become more important, not less.

Two kinds of agent, one accountability problem

The agent landscape splits into two categories, and they carry different governance weights.

Assisted agent (Copilot)

Autonomous agent (digital worker)

Identity

Acts on behalf of a named user

An independent entity in its own right

Permissions

Bounded by that user's access

Operates at machine speed with its own data access

Risk inheritance

Inherits the user's security posture

Needs its own controls, owner, and lifecycle


The old identity and information-access frameworks that apply to users apply first to those assisted agents. As I said earlier, if it is badly configured for me, it is badly configured for my Copilot. The exposure gets materially worse with autonomous agents, because they are not bounded by a human's working pattern or attention.

Microsoft's response, Microsoft 365 E7 and Agent 365 (both generally available since 1 May 2026), is fundamentally about laying the security foundations for this: giving the agent a first-class identity through Entra Agent ID and bringing it under the same Defender, Purview, and Entra controls that govern users. It is long overdue for Copilot, and it is foundational for everything that comes after.

Every agent needs an owner

You cannot have autonomous agents running riot, spinning up capability and accessing data with no line of accountability. From a FinOps perspective, the requirement is threefold:

  • Visibility. Every agent is discoverable and inventoried.

  • Cost allocation. Each agent maps back to a business unit or business line.

  • Accountability. Each agent has a named human owner or sponsor.

Notably, Microsoft's own Agent 365 licensing reflects this. It is licensed per the human user who interacts with, owns, manages, or sponsors the agents. It is not, yet, licensed per agent. That sponsor model validates the accountability principle: an agent is not a free-floating entity; it belongs to someone.

This is where joiners, movers, and leavers, a process plenty of organisations already handle poorly, takes on new urgency. When a user leaves the organisation, you do not want the autonomous agents they spun up continuing to run, untethered from any ownership or accountability. The leaver process now has to account for the agent fleet attached to the people leaving.

It is also where shadow AI becomes a first-order concern. Users will bring third-party agents into the business that do not align to the organisation's governance controls. An agent registry is how you surface that shadow AI and bring it under management, in exactly the way Defender for Cloud Apps was built to discover shadow SaaS.

ITAM is the data layer

None of this is as far from the ITAM and FinOps core competency as it might first appear. ITAM has always sat at the intersection of many disciplines because it is the data layer. SAM has long been the authoritative data layer for a host of interconnected functions, and you are already collecting the entitlement, assignment, and usage data. The agent era does not ask you to collect something entirely new. It asks you to apply a different lens to the same data set: a security and agent-governance lens on top of the licensing one.

That is the opportunity. The discipline that already owns the data is best placed to own readiness, if it moves first.

From ARPU to ARPA

To understand why Microsoft is investing so heavily in agent foundations, follow the commercial model. Microsoft's business has been indexed to the seat, to paid users like me. There is a ceiling on how far you can push that. E7 at $99 per user per month is a strong number, but not every organisation jumps to it overnight. So the more interesting bet is not the seat. It is agent proliferation.

I describe this shift as the move from ARPU to ARPA:

ARPU (the model we are leaving)

ARPA (the model replacing it)

Unit of revenue

The paid human seat

The governed AI agent

How it grows

Adding users, capped by hiring

Agent proliferation, effectively uncapped

What partners count

Users and licence assignments

Agents, owners, and agent profiles

Microsoft's lever

E5, Copilot, E7 seat pricing

Agent 365 per sponsor, with per-agent pricing signalled

Average Revenue Per User (ARPU) has defined the economics of enterprise software for two decades: you grow revenue by adding paid human seats. Average Revenue Per Agent (ARPA) is the model that replaces it. In an ARPA model, vendor revenue grows with the number of governed AI agents in an environment, not the number of people in it. I believe ARPA will become the defining commercial metric of the Microsoft agent economy, and the partners and FinOps teams who understand it first will be the ones positioned to price, govern, and optimise for it.

The logic runs like this. Today, I am one licence. If I spin up one agent, Microsoft can monetise that. But the real wager is that my five-person team does not stop at one agent between them. It ends up running twenty-five. That is the shift from Average Revenue Per User to Average Revenue Per Agent, from ARPU to ARPA, and it is the engine of Microsoft's next growth phase. A human headcount grows slowly and is capped by hiring. An agent population carries no such ceiling, which is precisely why it is attractive to a vendor whose growth has been tied to seats.

The sequencing is deliberate. First, drive ARPU up by getting customers agent-ready: E5, the Defender and Purview suites, the Entra Suite, the security stack that agents require. Agent readiness pushes customers up the licensing stack before a single agent is ever monetised. Then, once agents are genuinely unleashed, monetise the agents themselves. Agent 365 today is licensed per the human sponsor at $15 per user per month, but multiple Microsoft executives have already signalled a per-agent direction. I would bet on a true per-agent licensing model arriving, because those agents will need to be secured independently, with their own identity, access, and compliance posture, and many of them will consume the Microsoft productivity stack in their own right.

The practical consequence for our discipline is concrete. Where we used to build user profiles, asking whether a given person needs E3 or E5, we will start building agent profiles. What does this agent do? What data does it touch? Does it need the Microsoft productivity stack or only the security wrapper? FinOps as it stands today, built around cloud cost management, is not yet equipped for the Microsoft 365 and agent ecosystem. ARPA is the lens that closes that gap, and defining the standards, the metrics, and the assessment models for an ARPA world is the opportunity for whoever gets there first.

The partner opportunity

I would wager that the overwhelming majority of partner client fleets have not done a Copilot or AI readiness assessment in any rigorous sense. That is the opening.

If you can run those assessments at scale, surface the real security posture, and map it back to licensing, you can give a client a firm view in three directions at once:

  • Optimise what they already own. Show how to get full value from the licences already in place.

  • Establish where they really are. The true security posture today, whether that is Business Standard, Business Premium, or E3.

  • Map the path forward. A framework-led route to improve posture ahead of the agent economy.

That is a far more constructive conversation than a workshop on prompting.

And this is happening regardless. There is already AI in every business, much of it stealth. We have all used ChatGPT or Claude in environments where nobody formally sanctioned it. An AI strategy that consists only of cultural enablement, with no view of configuration state or agent inventory, is not a strategy. It is a compounding governance liability and a stack of technical debt waiting to surface. When a partner sells Copilot and walks away, they have not finished the job. They have created that debt on the customer's behalf.

You do not bet against Microsoft. If you are ready for the agent economy, if you can tell a customer exactly what their agent readiness is, what agents are in their environment, and whether their users have the right policies in place for the Copilots they are already spinning up, you have an opportunity to take disproportionate market share from competitors who are still running prompt workshops. The execution gap between baseline and readiness, and now between user governance and agent governance, is exactly where partner value, and partner revenue, concentrates.

The spreadsheet got us this far. It does not get us to the agent economy. The partners who industrialise readiness, making it standardised, framework-aligned, automated, and licence-aware, will be the ones still standing as the unit of consumption shifts from the user to the agent.

Hope this helps!


References


#CopilotReadiness #ITAM #FinOps #AgentEconomy #Microsoft365 #Agent365 #MicrosoftE7 #ZeroTrust #ARPA #AverageRevenuePerAgent #ShadowAI #SAM

This analysis is based on publicly available product information, industry research, and direct market experience.

Copyright (2026). softspend limited. All rights reserved.

Published by softspend.com. Microsoft 365 licensing intelligence for partners.

Key Takeaways

This article by Tony Mackelworth, CEO of Softspend, argues that Microsoft Copilot readiness is primarily a data governance problem rather than a licensing or adoption exercise. Copilot inherits the security posture of the identity that invokes it, so weak identity, access, and information-protection controls are amplified at machine speed. Most organisations measure Copilot by utilisation and adoption, but that is not readiness; the security foundation is the part that gets skipped. The article reframes the ITAM and FinOps role around a four-level chain: licensed (entitlement to the SKU), service plan activated (the capability switched on in the tenant), configured (policies set up), and effective (rolled out to improve posture), aligned to frameworks such as CIS Benchmarks and Microsoft Zero Trust. As Microsoft 365 E7 and Agent 365 (both generally available 1 May 2026) establish identity and governance foundations for AI agents, the discipline shifts from counting users to counting agents, with each agent requiring a named human owner or sponsor. The underlying commercial driver is the shift Tony Mackelworth describes as ARPU to ARPA: from Average Revenue Per User to Average Revenue Per Agent, where vendor revenue grows with the number of governed AI agents rather than human seats. Standardised, automated, licence-aware readiness is the resulting partner opportunity.

Key Facts

  • Key Facts (one per line)
  • Copilot readiness assessment has four levels: licensed, service plan activated in the tenant, configured, and effective. Adoption and utilisation metrics do not measure the security foundation.
  • A Microsoft 365 SKU is a bundle of service plans, each of which can be enabled or disabled in the tenant, so holding a licence does not mean the underlying control is switched on.
  • Microsoft Copilot inherits the security posture of the user identity that invokes it, amplifying existing oversharing and access risks at machine speed.
  • Microsoft 365 E7 (the Frontier Suite) reached general availability on 1 May 2026 at $99 per user per month.
  • Microsoft Agent 365 reached general availability on 1 May 2026 at $15 per user per month as a standalone add-on.
  • Agent 365 is licensed per the human user who interacts with, owns, manages, or sponsors agents, not per agent.
  • Microsoft 365 E5 list price rises from $57 to $60 per user per month on 1 July 2026 (E3 from $36 to $39).
  • CIS Microsoft 365 Foundations Benchmarks map to tiered E3 and E5 topologies.
  • Softspend maps 300+ Microsoft 365 features across 50+ suites and surfaces licensed-versus-activated state via Microsoft Graph.
  • Tony Mackelworth (Softspend) characterises the agent economy as a shift from Average Revenue Per User (ARPU) to Average Revenue Per Agent (ARPA), where vendor revenue scales with the number of governed AI agents rather than human seats.

Sources

  • https://blogs.microsoft.com/blog/2026/03/09/introducing-the-first-frontier-suite-built-on-intelligence-trust/
  • https://techcommunity.microsoft.com/blog/microsoft_365blog/microsoft-365-e7-and-agent-365-are-now-generally-available/4516295
  • https://www.microsoft.com/en-us/security/business/microsoft-entra
  • https://www.cisecurity.org/benchmark/microsoft_365
  • https://learn.microsoft.com/en-us/security/zero-trust/