Agents working alongside people in the flow of work: what changes about the licence question when the thing consuming the software is not a person. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session eighteen of forty. Last session established that there are two layers to the Copilot bill and that the metered one has no ceiling. Today we go to the end of that road, which is agents doing work on your behalf, and the specific thing that makes this session necessary. Every intuition you have about software cost comes from software being used by people. People sleep. People go on holiday. People get bored of a tool and stop opening it, which is the adoption gap we spent session sixteen on. An agent does none of those things. A scheduled agent runs at three in the morning whether or not anybody wants it to, at exactly the same rate, indefinitely, and nobody ever re approves it. So the numbers in this session look wrong the first time you see them, and they are not wrong. They are what happens when consumption meets automation and nobody does the arithmetic first.
Five takeaways. One, it is not a separate SKU: cowork rides on an active Microsoft 365 Copilot licence and is delivered through the Frontier program, so the buying decision sits inside your Copilot contract rather than beside it. Two, what it does: long running multi step tasks, drafting documents, sending mail, scheduling, posting in Teams, running reusable skills. A delegate rather than a chat assistant. Three, the message meter: actions bill in messages, a simple query is one, multi step reasoning three to five, each tool call one more, an agent to agent handoff two at each agent involved. Four, the scheduled agent problem: one nightly agent over two thousand records worked out at roughly three point six million messages a year, about three hundred and sixty thousand dollars before discount, from a single agent. Five, governance is a purchase: Agent 365 is a separate entitlement, and assuming otherwise added ten to twenty five percent of unbudgeted cost.
What cowork actually is, three things that are true commercially. It is a mode rather than a product line: an agentic mode of Microsoft 365 Copilot that carries out long running multi step tasks instead of answering a single prompt, so you describe an outcome and it acts across Microsoft 365. There is no standalone cowork price to negotiate, which means the leverage sits entirely in the underlying Copilot commitment. It is gated: it requires an active Copilot licence and comes through the Frontier early access program, and that gate is exactly why cowork shows up in expansion conversations, because the route to it runs through more Copilot. That is a commercial fact rather than a technical one and it is worth naming as such. And model choice is real: Anthropic Opus is selectable inside cowork alongside the Microsoft models, which matters for capability assessment and for your governance review, because which model handles which work is now a decision somebody in your organisation is making.
What you must already own, the stack underneath an agent. A qualifying base, E3 or E5 on the user as in session sixteen, billing per user per month. Microsoft 365 Copilot, the active licence cowork rides on, around thirty dollars list per user per month. Frontier access, the early access program it is delivered through, which is program terms rather than a price line. Execution, meaning the agentic work itself, metered as credits or as messages on the agent SKUs. And Agent 365: identity, audit, lifecycle, sensitivity, and DLP across the agent estate, which is a separate entitlement and is not inside Copilot or E5. Read those last two rows together, because that is the shape of the bill. Execution is metered with no ceiling, and governance is a separate purchase. Both get routinely assumed to be included, and that second assumption alone added ten to twenty five percent of unbudgeted cost where it was tested against an actual invoice.
First check. A proposal prices an agent rollout as Copilot seats plus a small credit pool. What is missing? A, nothing, seats plus consumption is the whole bill. B, the governance layer, because Agent 365 is a separate entitlement covering identity, audit, lifecycle, and DLP across the agent estate, and assuming it is included added ten to twenty five percent of unbudgeted cost. C, only the training and change management cost. D, nothing, governance is an IT concern rather than a licensing one. Pause it, and as you think, ask yourself who is responsible for knowing what every agent in the tenant did last week, and what licences that actually requires.
The answer is B. Agent 365 covers identity, audit, lifecycle, sensitivity, DLP, and data loss boundaries across the whole agent estate, which is broader than most buyers assume before they read it, and it is a separate entitlement rather than something bundled into Copilot or E5. Across the estates we looked at, that assumption added ten to twenty five percent of unbudgeted cost at the point it met the invoice, and on roughly half the rollouts governance was scoped after the agents had already shipped. D is the belief that produces that finding and it deserves a direct answer: governance here is not a policy document, it is a licensed capability, so treating it as somebody else's concern means it arrives as an unplanned purchase at true up. A prices two of the three layers and calls it complete. C names a real cost that is not the one being missed, and change management will not give you an audit trail for what an agent did at three in the morning.
The message meter, decoded, five ways an action becomes a message. Simple query, one message: a single round trip through a single agent, and this is the number people build their intuition from, while almost nothing an agent does in production looks like this. Multi step reasoning, three to five, because each reasoning step adds, so an agent that plans before it acts costs several times what a single question costs, which is the entire point of it. Tool use, one message per tool call, charged on top of the reasoning, so an agent that reads one system, writes to another, and confirms pays for each separately. Agent to agent handoff, two messages per handoff, counted at each agent involved, which means multi agent designs are elegant and they multiply the meter. And long context retrieval, two plus a surcharge, because large context windows cost more. Then the multiplier that dominates all five: a scheduled run is the sum of everything above, times the schedule, forever.
Guest analyst The conversation that changed how I talk about agents happened in a room where nobody had done anything wrong. A logistics business, and their data team had built an agent to review exception records overnight. About two thousand records a night, a few reasoning steps each, a couple of system lookups per record, and it worked beautifully. It cleared a backlog that had been a problem for years. Everyone was pleased and I want to be clear that they should have been, because it was good engineering solving a real problem. It had been approved as an automation project. It went through the normal technical governance, it had a business case built on hours saved, and licensing was never consulted because nobody thought of it as a purchase. Four months later the metered line on their Microsoft bill was large enough that finance asked what had changed. We worked it back, and the run rate on that single agent annualised to a number in the mid six figures. Now the useful part is what happened next, because it would have been easy to turn it off in a panic. They did not. They ran the arithmetic properly, found that about sixty percent of the cost came from a retrieval step that was pulling far more context than the task needed, changed that one thing, and kept the agent. What the head of data said afterwards has stayed with me. He said, we have a process for approving a thirty thousand pound piece of software and no process at all for approving something that quietly costs three times that, because it never looked like buying anything.
A good agent, solving a real problem, at a cost nobody had ever approved. Every agent gets the arithmetic. Second check.
Check two, and this is the arithmetic. An agent processes two thousand records nightly with three reasoning steps and two tool calls each. Roughly what does that cost a year? A, a few thousand dollars, it is one agent. B, around three hundred and sixty thousand dollars before discount, because that is roughly ten thousand messages a night and three point six million a year at typical per message rates. C, it is covered by the Copilot subscription. D, around thirty thousand dollars, in line with a small team's licences. Pause it and actually work it through: messages per record, times records, times nights. Do not estimate this one by feel.
The answer is B. Three reasoning steps and two tool calls per record is roughly five messages per record, so two thousand records is about ten thousand messages a night, which is three point six million a year, and at typical per message rates that lands in the order of three hundred and sixty thousand dollars before discount. From one agent, running one job. A and D are the seat based intuition and they are wrong by an order of magnitude, which is exactly why this arithmetic has to be done explicitly rather than estimated. Nobody would approve a three hundred and sixty thousand dollar line item casually, and a great many organisations have approved this one, because it arrived as a technical decision about automating a nightly process rather than as a purchase. C is the assumption that makes the whole thing invisible: execution is metered separately from the subscription, and the subscription grants access rather than paying for the work. Actions per run, times runs per period, times the message weights. Every autonomous agent, before it ships.
Governance is a purchase, three things Agent 365 changes. The agent estate has an identity problem: agents act, and something has to record which agent did what, under whose authority, with access to which data, and identity, audit, and lifecycle across the agent estate is what the governance plan covers. It is broader than most buyers assume before they read it. Three SKUs, not one: per user assignment for agents operating in a single user's context, a per agent line metered on message units, and the tenant level governance plan. Three different shapes of cost, and a proposal quoting one of them is quoting part of the picture. And half of rollouts scoped it late: agent governance was an afterthought in about half the rollouts we saw, which created audit and data exposure risk alongside the unbudgeted cost, and both problems have the same fix which only works if it happens first. The negotiating levers are the meter's standard set: message pool unit price and per agent metered rate, capped at signing.
The agent arithmetic, worked, and this is the template. Actions per run: how many reasoning steps, tool calls, and handoffs, which in our example is three reasoning plus two tool calls, about five messages per record. Volume per run: two thousand records. Runs per period: nightly, indefinitely, and that word indefinitely is doing a lot of work. Messages per year: the product of the three, about three point six million. Cost and cap: about three hundred and sixty thousand before discount, and then the figure that makes this mandatory rather than advisable, which is that agent consumption overran the prepaid message pool by twenty to forty percent across the engagements behind this course. Think about what an overrun means on an automated process. Nobody notices. A person who spends more than expected knows they did it. An agent that overruns a pool produces no signal at all until it appears on an invoice, which is typically a quarter later.
Last check. A cowork demo lands well and the account team proposes expanding Copilot to enable it. What is the buyer side response? A, expand, cowork is where the value is. B, treat cowork as a reason to slow the expansion until base Copilot adoption is proven, because active use sat at twenty five to forty five percent of assigned seats at six months and agentic demos pull buyers straight past that gap. C, decline all agentic capability. D, expand, but only for one department. Pause it, and ask yourself what the demo actually proves about your estate, as opposed to what it proves about the product.
The answer is B, and the distinction in that prompt is the whole thing. A demo is evidence about the product. It is not evidence about your adoption. Across the Copilot engagements behind this course, agentic features became the upsell hook well before customers had proven base value, and measured active use of base Copilot sat between twenty five and forty five percent of assigned seats at six months. Both things are true simultaneously: the capability is genuinely impressive, and your estate has not yet demonstrated it can use the simpler version. Expanding on the strength of a demo commits you against evidence you do not have. A treats capability as adoption. C overcorrects and forfeits real value, and it is not the buyer side position. D is closer, and it is only sound if that department is chosen from usage evidence rather than enthusiasm, because the department that most wants the demo is frequently not the one with the strongest case. Prove the base, earn the expansion, negotiate the metered rates before either.
The agent estate method, three rules before the first agent runs, and none of them slow a good project down. One, every agent gets the arithmetic: actions per run, times runs per period, times the message weights, written down and signed off by whoever owns the budget it lands on. No autonomous agent ships without it, and the rule applies to the small ones too, because small agents multiply. Two, governance before deployment: the identity, audit, and lifecycle position agreed and licensed before the agents run rather than after, because half of rollouts got this backwards and paid for it twice, once in unbudgeted licence cost and once in exposure. Three, cap the rates at signing: the message pool unit price and the per agent metered rate, capped at signature inside the Microsoft 365 line of the agreement, because these are negotiable while you have not yet committed and considerably less so afterwards. And a fourth habit for whoever runs the estate: review consumption by agent, monthly.
Session eighteen, three sentences. One: cowork is not a separate SKU, it rides on an active Microsoft 365 Copilot licence through the Frontier program, so there is no cowork price to negotiate and all the leverage sits in the underlying Copilot commitment. Two: actions bill in messages, and a single nightly agent over two thousand records works out at roughly three point six million messages and around three hundred and sixty thousand dollars a year before discount, which no seat based intuition would ever have predicted. Three: Agent 365 governance is a separate entitlement rather than part of Copilot or E5, and assuming otherwise added ten to twenty five percent of unbudgeted cost, so scope it before the agents ship rather than at the true up. Next session takes everything from these three and turns it into a negotiation.
Homework, about an hour, and this week you inventory the agents. One, find out what is running: every agent or automation in the tenant, who built it, and what it does, and in most estates nobody currently holds this list, which is itself the first finding. Two, flag the scheduled ones: anything running on a timer rather than on a person's request, because those are the ones with no natural ceiling. Three, run the arithmetic on the biggest: actions per run, times volume, times frequency, one agent, one number, and compare it against whatever anybody assumed it cost. Four, check the governance position: do you hold Agent 365, and if not, who assumed you did, and ask that before the answer arrives on an invoice. Five, ask for the rate caps: message pool unit price and per agent metered rate, capped at signing, on the list for the next negotiation even if agents are still only a pilot in your estate.
Five reads before next session, all free on redress compliance dot com. First, the Microsoft Copilot cowork licensing guide, covering what cowork is, what it requires, and the buyer side risks in full. Second, the Agent 365 licensing guide, which carries the three SKUs, the message meter action by action, and the worked agent cost we walked through. Third, Copilot Credits cost per task, for the task tier model sitting behind the execution line. Fourth, Copilot Credits governance at the EA, on the rate caps and pool terms to secure at signature rather than request later. And fifth, capping the AI consumption overage cliff, for controls on a line that an automated process can move overnight without telling anybody. Next session is negotiating Copilot: discounting, term alignment with the EA or the MCA, ramps, pilots, and the specific traps in a product Microsoft is pushing extremely hard. See you there.