The Meter Is the Feature

The biggest Microsoft 365 AI change this month is not a feature. It is a meter. A meter is what a capability looks like once it has become its own runtime tier you call, and pay for, per invocation.

Copilot Cowork is generally available and billed by consumption, and in September Microsoft shipped the controls that make consumption survivable: spending policies, spending alerts, per-policy consumption reports, and approval workflows for credit requests, all in the M365 admin center. Read that as a productivity announcement and you file it under adoption. Read the bill instead and it is an architecture diagram. It tells you a new tier has landed in your stack, sitting between the identity and data your users already have and the apps they touch. The question that follows is an architect’s. Where does that tier live, and what does it couple to.

What actually shipped

I already worked the money once. In Microsoft’s Claude Looks Cheaper Until You Read the Prerequisite I walked the Cowork math: a per-user license floor plus a per-task credit meter, so the cheaper-per-task claim only holds after you have already paid the seat. I will not re-run that here. What changed in September is not the price. It is the plumbing around it.

Microsoft put the meter into the management surface. Per the Cowork admin documentation and the usage-based billing overview, admins now get spending policies, spending alerts, consumption reports per policy, and custom approval workflows for credit requests, sitting under Copilot cost management alongside a Viva Insights dashboard that tracks credit usage for Cowork and the Work IQ APIs.

Here is the line worth reading twice. New usage-billed services get added to your spending policies automatically, and the behavior is on by default. Convenient, until a service nobody evaluated starts spending credits under a policy someone configured in June.

Microsoft shipped a control plane for the agent runtime

For a year I have been writing that the agent runtime was real and had no control plane. In Nobody Budgeted for the Agent That Never Sleeps I argued the seat was a self-capping fiction, and that an agent fleet meters on compute that does not sleep, so you have to build per-run budgets yourself. In Data 360 Is a Reference System, Not a Database I flagged the same unmetered runtime on the Salesforce side and said I had not seen anyone price it cleanly.

Microsoft just shipped the vendor version of that missing layer. Read it as a control plane for the agent runtime: the spending policy is the per-run budget I said you would have to hand-roll, the consumption report is the usage rollup, and the Viva dashboard is the telemetry nobody was giving you.

That is a real gain, and it is also a coupling decision. When the vendor supplies the control plane, your control plane is bound to the tenant it governs, configured in the same console that benefits when the number goes up. Nobody chose that dependency on purpose. It arrived with the feature. The architecture question is the old build versus buy: adopt their control plane, or put a vendor-neutral broker in front of the tier so the budgets, quotas, and routing live somewhere you own. Neither is free. Coupling to theirs is one console and zero build. Owning yours is a service you have to run.

Where the cap is bound

The test I keep coming back to, from Governance or Containment, is where a control is bound. A control in the execution path runs every time and can stop the work. A control off to the side records what already happened. Apply that to spend.

A spending alert sits off to the side. It fires after the credits are gone. A spending policy that caps and halts a run at the limit sits in the path, in the same class as a rate limit, a timeout, or a circuit breaker on any service you would design. Microsoft’s policies are described as limit-based controls, which is the right shape, so the question for your own tenant is a design question, not a compliance one: at the limit, does the run stop, or does the number turn red while the run completes. Have the halt demonstrated, not the chart.

Then there is the default. A policy that auto-applies to every new usage-billed service, on by default, is a control that expands its own surface without a decision. The first time that bites is the day a service nobody evaluated bills against a policy set for something else. The safer design inverts it: new services land in a capped, deny-by-default policy until someone wires them in on purpose, the same way you would not auto-trust a new upstream. If the platform will not let you invert it, that is a constraint worth knowing before you build on it.

The rest of the wave points the same way

Everything else in the September roadmap is a productivity feature with an architecture question underneath. Anthropic models available alongside OpenAI when you edit in Word. Python execution when you edit with Copilot in Excel. Authoritative SharePoint sites so Copilot Search prioritizes official content. Work IQ as one unified REST endpoint to invoke agents and workflows in place of the legacy ones.

I traced where this leads in Microsoft Conceded the Harness, Then It Moved the Moat: the model stops being the lock-in and the context layer becomes it. Each of these features is the productivity wrapping that justifies the consumption floor and pulls more of your context into the tier, which is the coupling that decides how hard the tier is to move later. I will not re-explain the mechanism. I will just ask the four questions each feature actually poses. Which tier resolves a credit request. Which models are allowed to run. Which SharePoint sites become the retrieval source. Which agents can be called through the new endpoint, and from where. Those are placement, routing, and data-path questions wearing a feature’s clothes.

The decision, on the axes that matter

So the practical question is not whose meter you want to be governing. It is where the tier sits. There are three doors, and I mapped them in Claude Is Already in the Building. What changed is that the axis that separates them is now placement and coupling, not features.

Copilot Cowork. The tier sits inside the M365 tenant, on top of the identity and data your users already work in, sharing their context layer. One bill, one console, one control plane. If your center of gravity is already Microsoft, that co-location is the whole argument, and it is a strong one. The cost is that the tier is now coupled to a context layer you do not own.

Anthropic, direct. Worth a note that the branding just moved: as of mid-September Anthropic is folding its own Cowork into unified Claude. Going direct means model choice is yours, the tier runs against a context layer you assemble, and the data path and identity are wherever you wire them. More control, more to build, and a thinner exit surface, because the context you own travels with you.

Salesforce Agentforce. A different placement: the tier runs inside the Salesforce trust boundary, on Flex Credits and per-conversation pricing, next to data that already lives there. If your regulated data already sits in Salesforce, putting the tier where the data sits is the point, as I covered in Salesforce Headless 360.

The axes to score them on: which layer the tier sits on and how tightly it couples to your identity, data, and context; the exit surface, meaning what you would have to rebuild the day you leave; the data path and where it runs; and whether you keep real model choice. The meter, and who governs it, falls out of those. It is a consequence of placement, not the first question.

Both sides, honestly

Microsoft’s case is real and I do not want to wave it away. One control plane beats three. A tier that sits on the identity and data your users already have, with budgets and routing in the same console, is a tier your platform team can actually operate, without a fourth control plane to wire and reconcile. For an org already all-in on M365, going direct to buy an independence you will not exercise is its own waste.

The direct case is just as real. A tier you place on someone else’s context layer is a tier that can be repriced and re-scoped without you. Going to Claude or Agentforce lets you put the tier where your data gravity already is and keep model choice and the exit surface in your own hands. Neither of these is a fight to win on principle. You resolve it by asking where your identity, data, and context already live, and how much you would have to rebuild the day you move.

The rule, and what it does not fix

The rule is short. Treat the agentic-work tier like any other service you put into production. Decide where it sits before you turn it on, not after the invoice. Bind the spend cap in the execution path so it runs every time, not on a dashboard that watches after the fact. Invert the default so new services land capped until someone wires them in. And keep the coupling to the context layer a dependency you chose, not one that arrived with a feature.

What none of this fixes is the meter itself. All three vendors bill by consumption now, so placement does not remove the cost. It changes which layer the tier sits on, where your identity and data sit while it runs, and how cleanly you can leave. That is the honest scope of the decision. I am not naming a winner, because the right answer is a function of your gravity, not of which vendor shipped the nicer dashboard this month.

The feature wave was an architecture decision the whole time. Read the meter, and read the tier it is pointing at.

Sources

Microsoft Learn: usage-based billing and Copilot Credits · Microsoft Learn: manage Copilot Cowork governance · Fortune: Anthropic folds Cowork into Claude · Salesforce Agentforce pricing

---

If you want the money math this post builds on, read Microsoft’s Claude Looks Cheaper Until You Read the Prerequisite, and for the runtime discipline underneath it, Nobody Budgeted for the Agent That Never Sleeps. This post is the architecture sequel: the month the meter moved into the admin center and showed you where the new tier sits.

Find me on X or LinkedIn. I write about what happens when AI infrastructure meets regulated reality.