Microsoft 365 E7 Pricing and Agent 365 Licensing: What You Are Actually Buying

Short answer: Microsoft 365 E7 lists at 99 dollars per user per month in the US and bundles E5, Copilot, the Entra Suite and Agent 365. Buying those pieces individually comes to roughly 105 dollars, so E7 is the cheaper route if you want all four. Agent 365 on its own is 15 dollars per user per month and has been generally available since 1 May 2026. Licensing is per user, not per agent, so one seat covers every agent that person owns, sponsors, manages or interacts with. What the 99 dollars does not cover is the cost of running the agents, which is metered on the Azure invoice, or anything the agents buy in the outside world, which has no ceiling anywhere in the product.

If you are costing out an agent rollout this quarter, the licensing arithmetic is the easy half. The half that goes wrong in month three is the part where costs arrive on invoices your seat count never predicted. This is written for whoever has to defend the number.

Microsoft 365 E7 pricing, and how it compares to buying the parts

The list prices are public and they are simple. The trap is assuming the bundle is a cost ceiling rather than a bundle.

So the decision between E7 and a standalone add-on is genuinely just a bundle question. If you are already on E5 and you do not want Copilot or the Entra Suite, adding Agent 365 at 15 dollars is the sane move and E7 is 84 dollars of things you did not ask for. If you want Copilot anyway, E7 saves you about 6 dollars a seat against the a la carte price and simplifies the paperwork. Neither choice changes anything below.

Per user, not per agent: the number that surprises people in a good way

This is the most commonly misread part of Agent 365 licensing and the misreading is pessimistic, which is unusual for Microsoft licensing. Agents do not carry licenses. A single user license covers every agent that person owns, sponsors, manages or interacts with. Deploying your eleventh agent, or your hundredth, adds nothing to the governance line on the invoice.

That has a practical consequence for how you scope the purchase. The question is not how many agents you plan to run, which nobody can answer honestly at the start of a rollout. The question is how many humans will end up interacting with one, and in most organizations that number converges on everybody. Model it that way from the start rather than buying a small pilot block and renegotiating in six months from a weaker position.

It also means the per seat line is the predictable part of your agent budget. Everything unpredictable is somewhere else.

The first cost E7 does not contain: consumption

Agent 365 licensing covers governance. It does not cover building or running an agent. Copilot Studio consumption and the Azure compute underneath your agents are metered and land on the Azure invoice, not the Microsoft 365 one.

That split is where the organizational failure happens, and it is worth naming precisely because it is boring rather than dramatic. The governance team sees a fixed per seat cost and reports a predictable number upward. The engineering team sees a variable consumption bill. Neither has full visibility into the other without somebody deliberately building a cross team view. Meanwhile the underlying driver is invisible to both: an agent that retrieves ten files per prompt costs more than one that retrieves three, and an agent that runs 500 times a day costs more than one that runs fifty, and no procurement conversation ever surfaced either fact.

Several Microsoft licensing consultancies have written this up well and they are right about it. It is a FinOps problem with FinOps answers: tag the workloads, attribute them to a cost center, alert on the derivative rather than the total. Do that work.

The second cost, which almost nobody is writing about

There is a third invoice, and it is not from Microsoft. It is your bank statement.

The moment an agent does something genuinely useful in a business process, it starts moving money outward. It renews a SaaS subscription because the renewal notice landed in a mailbox it monitors. It tops up an ad account because performance dipped. It books travel. It pays a supplier invoice it just matched to a purchase order. It buys API credits so it can finish the task it was given. Every one of those is a real payment leaving through your card program, your payables system or your bank, and none of it appears on a Microsoft invoice at all.

We went looking for a control for this rather than assuming one way or the other. On 8 September 2026 we pulled the Microsoft Graph beta schema document, which defines every entity and property in the Graph beta surface, and read the property list of every agent governance type in it. There are 48 such types carrying 623 properties between them, and not one expresses an amount, a currency, a budget or a limit. The 29 Conditional Access types carry 99 distinct properties and none of those is monetary either, even though the policy conditions now explicitly name agents. To be sure the search was not simply broken, we ran the identical pattern across the rest of Graph: it matched 37 other types, including invoice amounts on bookings, default prices on services and currency codes on aged payables. Microsoft Graph models money in detail when the domain calls for it. It does not model money anywhere near an agent. The full method and the numbers are on our Microsoft Agent 365 page.

This is not a flaw in Agent 365. An identity and access control plane is the wrong place to encode a finance policy, and Microsoft scoping it out is a defensible design decision rather than an oversight. It is a gap at the program level, and the reason it catches people is that Agent 365 is so thorough about everything else that thoroughness here gets assumed.

What the 99 dollars does buy, and it is a lot

None of the above is an argument against the purchase. Agent 365 does the hardest and least glamorous part of an agent program, which is turning shadow deployments into managed assets. You get a single registry covering every agent in the tenant including ones Microsoft did not build, an Entra Agent ID for each, named owners and sponsors, Conditional Access and identity governance applied to agents the way you already apply them to people, reusable policy templates that hit new agents on day one, and Defender and Purview coverage. Viewing the inventory needs only the AI Reader role and no specific license, which makes it easy to give finance and audit read access without handing anyone the ability to change things.

Budget for the human side too. Agent 365 assigns every agent a named owner and a sponsor, and those are real accountabilities that land on people who have never held one before. Rolling this out well means you have to train and certify the people who will own them on what they just became responsible for, which is a line item most licensing business cases forget entirely.

How to build the business case without a surprise in month three

1. Size the seat count on humans, not agents. Count everyone who will interact with an agent, which is usually the whole tenant, and price E7 against E5 plus the 15 dollar add-on at that number.
2. Put the Azure consumption line in the same document. Even a rough estimate is better than an absent one, because an absent one reads as zero to a budget holder.
3. Name an owner for the cross invoice view. The failure is not that either bill is unknowable, it is that nobody owns adding them together.
4. Decide the purchasing question before an agent can buy anything. This is the one with no Microsoft answer, so it needs a decision rather than a default.
5. Give finance the AI Reader role. It costs nothing and it means the people who own the budget can see the inventory that drives it.

What to put in front of the money

The design that holds up separates capability from authority. A Conditional Access policy or an OAuth scope decides what an agent can reach. A spend policy decides whether this specific action, right now, for this amount, to this counterparty, is allowed. Those are different shapes of control, and no amount of tuning turns a binary access gate into a graduated one on amount.

Concretely, before your first agent transacts: give each agent its own funded wallet rather than a shared corporate card, so a bad day is contained to one balance and every charge is attributable to a named agent. Check each intended payment against policy before a credential exists, covering the per transaction ceiling, the running total over a window, the vendor allowlist and the velocity rule that catches a retry loop. Pause anything above your threshold for human approval, ideally routed to the same person Agent 365 already records as the owner. Issue a merchant locked virtual card scoped to one purchase instead of a reusable key. And write every decision to an immutable audit trail naming the agent, its owner, the intent and the policy that allowed it, because when a charge appears at 3am the only useful question is which agent, on whose authority.

Run that alongside Agent 365 rather than instead of it. Microsoft keeps identity, registry, access and security, and does those better than anyone else will. The spend decision sits in front of the payment, where the Graph schema shows there is currently nothing at all. If your agents are also reaching your books or your processor, we ran the same probe method against accounting MCP servers and payment MCP servers and reached the same conclusion one layer down: they all govern which tools an agent may call, and none of them governs the amount.