Your SaaS Bill Just Got a Second Meter. You’re About to Pay It.

[00:00] Salesforce just reported that Agent Force, their agent product, hit $800 million run rate in ARR, up 169% year-over-year with 2.4 billion agentic work units processed. That is not tokens, that is work units. Salesforce is now counting the actions agents complete inside the platform and billing according to those actions, not the token. Similar patterns are cropping up other places. In the same week, Microsoft Agent 365 went generally available. It costs $15 per user per month, and the governance license
[00:31] specifically manages how agents act inside your Microsoft environment, and the Microsoft environment acts as the control plane. So, if you're building agents that touch Salesforce, that touch Microsoft systems, you're going to start to see this price tag show up. Most builders are going to start to need to face what it costs to implement agentic workflows across larger context systems at scale. And it won't just be model billing costs. Increasingly, it's going to be other players involved who are
[01:01] effectively setting up toll booths along the way to make sure that they get their piece of the value you're creating. So, the question you need to answer before your next vendor renewal is this. What are you paying for when the work moves from a person to a machine? Because a machine can do it now, but the toll booth, the pricing looks different. I want to open up four questions that are underneath that big overarching question. Number one, what is the pricing meter here, and does it make sense for your business? Number two, what counts as a fair agent license
[01:32] versus one that's just effectively SaaS seat protection in a new costume? Number three, where is a vendor using policy language that might lock out your agents? And number four, what does a cost to wear agent look like in production? Because that's the thing that's going to matter long term. For two decades, SaaS pricing ran on a very simple trick. You turn work into seats, which leads to predictable revenue, which leads to predictable growth in and and because we continued to need to introduce more work to computers, do more work on computers, have specialized
[02:02] software for the workforce using computers, that whole model turned into an absolute bonanza of cash flow for SaaS companies. We all know that is in jeopardy at this point. The model of having 10 people sitting on a CRM and billing for 10 seats is in question. And this affects some of the biggest names in the business, right? HR can run on Workday, engineering on Jira, marketing on Hub Spot, IT on ServiceNow. Everybody's having to rethink their business models, and the companies I just named are at very different spots on that rethinking agentic spectrum.
[02:33] Some are much farther along, some are not. But regardless, before the agentic workflow revolution started, every vendor could point to a group of humans and say, "These are the people who use our software, so these are the people that need licenses." And that model worked because the human was the unit of software value. A person logged in and clicked and updated records and did workflows, and the vendor charged for that person's access, and now that doesn't work anymore. AI agents just break that entirely because an agent can use software without sitting in the software. It can read from the CRM,
[03:03] update a support ticket, grab a ServiceNow workflow, update a Jira issue. You get the idea, right? The work still happens, the vendor's system still carries the data and the permissions and the audit trail, but the idea of using the software just doesn't capture the value exchange anymore, and companies are getting savvy to that. And that is why all the vendors out there are effectively the vendors formerly known as SaaS at this point, and they're all building toward different versions of a new pricing model. And we need to understand what that pricing model is in order to make sure we make smart
[03:33] decisions about the real cost of agentic workflows going forward. Let me walk through three versions so you can start to see the pattern here. First, Salesforce is the cleanest example because they're not hiding the shift at all. Agent Force pricing uses flex credits and agentic work units. You update a record, you summarize a case, you answer an inquiry, execute a prompt, run a workflow, whatever. Each one draws from the same meter. The old model was the service rep has a seat, and the new model is, at least according to Salesforce, the rep might have a seat,
[04:04] but the agent that identifies the customer and retrieves prior cases and triggers the workflow also burns credits. The seat is still there, it just isn't the whole bill anymore. Now, Microsoft is example two, and I think it's a hybrid model like this, but it's at obviously a massive scale, right? Microsoft 365 Copilot absolutely still uses seat pricing, but Copilot Studio pricing makes that second agentic meter extremely explicit. Copilot credits measure agent usage in different features, consume credits at different rates, right? Answers, generative
[04:35] answers, agent actions, uh grounding in the graph, flow actions, premium reasoning, whatever that means. And so, the realistic monthly cost for a 100-seat company running modest agent workloads starts to scale up as you run these runtime credits. It's not necessarily going to be a very low bill for you if you are running premium credits and premium reasoning and premium workflow. Again, someone who's trying to figure out how to plan agentic workflows is facing this this forest of
[05:05] pricing complexity in what used to be a very clear per-seat cost. Do I use premium reasoning for Copilot? How much do I use reasoning? And and and no one's ready to answer that because everything is changing so quickly. I was talking to a developer just this past week who has used 8 billion tokens in the last month. 8 billion in a month. Uh that was not the case in 2025. We are scaling token usage really really fast, and it makes it difficult to plan when the SaaS survival model is to charge you
[05:37] per token and hope that you'll figure it out. This is part of why I talked to a lot of CTOs and CIOs who are very very frustrated with the procurement landscape right now. ServiceNow comes at this from the operational side. It's our third example. The action fabric re-frames ServiceNow from a place where employees click around into a system where agents trigger real operational work through governed pathways with identity and permissions and audit all sort of attached. These are units of operational work, not API calls. If an agent provisions access and escalates an incident and kicks off onboarding or
[06:07] opens a change request, then ServiceNow has a claim that it is providing the workflow substrate and the operational reliability around that action charge accordingly. So, these three vendors, right? Microsoft, Salesforce, ServiceNow, they are all making kind of the same move, right? The seat is staying and they're turning on a second meter for delegated work. Now, I have a full eight-vendor breakdown in the Substack post for today including Zendesk outcome pricing, HubSpot's per resolution model, Workday's agent system of record, and
[06:38] Atlassian's soft launch credit pattern with Rovo. And with that pricing model comes new pricing rules. And I want you to watch this carefully because the new pricing rules are going to feel, in some cases, anti-developer and anti-agent. SAP's 2026 API policy draws a very hard line around how customers and third-party systems can use SAP APIs. This made the news recently. I talked about it briefly, including restrictions on AI systems that plan, select, or execute sequences of API calls outside of SAP endorsed architectures.
[07:08] Translation, if you want an outside agent, an internal agent, another vendor's assistant to act on your SAP data, the first question is going to be contractual, not technical, cuz contractually you're going to have to ask, "Is this even allowed under the under the terms of the engagement that we signed?" And so, if you're building agents that need to touch SAP data systems, you have to understand that SAP is at minimum going to want a toll booth, but may not even allow you to at all. And so, I think that the question I have for you is, "How do you think about pushing back?" And I have some suggested
[07:38] policy language to push back for vendors in the Substack here. If you're in an active negotiation, I've got some suggested language. But, the larger conversation you need to have is you need to talk during the procurement and negotiation process with the vendor and say, "Look, our agents are from X or Y provider, right? Claude, OpenAI, whatever. We need to have them be able to access your system in X, Y, and Z ways. How do we make sure that that's something that remains inside a particular budget and
[08:09] cost envelope, and how do we make sure that the developer experience is clean enough that we can get value?" And I don't see those conversations happening very often. And part of why they're not happening very frequently is that the vendors don't want them to happen very frequently because pricing follows platform control. The vendor that defines the new work primitive earns the argument that it should price the work. And all of the vendors I'm talking about are thinking about that really actively right now. Salesforce meters agent actions because Salesforce defines many of the actions inside the
[08:41] customer relationship workflow. ServiceNow operational actions because ServiceNow defines a large part of the enterprise action layer. Microsoft wants Copilot credits because Microsoft sits across the productivity graph. SAP wants sanctioned pathways because SAP owns high-consequence systems where uncontrolled agent execution is an operational risk. If you build on these platforms without understanding their incentives and how they're inclined to meter, your agent's economics end up belonging to somebody else. So, what does a fair agent license actually look
[09:12] like, and what does one that's more of a rent-seeking approach look like? I I think let's keep it simple here. A fair version, it the meter has to be visible, and the unit has to make sense and be transparent. The customer has to be able to forecast usage. Failed or low-value work cannot be billed the same as completed work. Third-party agents need to have a governed path, not a blocked path. And the vendor needs to distinguish between reading, drafting, writing, approving, and executing for agents and bill accordingly. The buyer
[09:43] needs to be able to set caps. Usage data needs to be exportable. The rate card cannot shift after you've adopted these agents. Now, what is a rent-seeking version like? Right? The above is like what the buyer is going to want. A an unscrupulous vendor, and I'm not saying any of these vendors are unscrupulous, just to be clear. But but I have seen patterns like this from other vendors. A rent-seeking version from a vendor looks like this. It charges for vague AI access without explaining what's consumed. It makes the vendor's own agent the only practical route while treating outside agents as hostile. It
[10:14] charges customers to use their own data in their own workflows. It will count failed work as billable work. It will hide the meter until renewal. It will bundle credits that expire unused while billing overages right away. It'll dress up commercial lock-ins in security language. Look, if you have a confusing mess of a contract with seat counts and API clauses and bot policies and a pile of AI pilot scattered across departments, you don't have a solution that touches production workflows, and you don't have any kind of cost envelope
[10:44] that lets you figure out how much that's going to be. I've put together a full checklist in the Substack with nine different traits around agent licenses, specific flags that you can look at that pick out these rent-seeking clauses, but I want the larger point to be this. You need to be aware that the agentic revolution looks like dollar signs to a lot of companies who are going to be selling you agentic solutions. Many of those are going to be good, and some of those are going to be rent-seeking. And
[11:15] you need to start asking very, very specific questions in the conversation to ensure that the pricing model used contractually reflects the likely scale-up in agentic workflows that you will experience over the next 12 months, because it is absolutely exploding. That 8 billion token conversation, you know, the best part of that is I wasn't even surprised cuz I know other developers who burnt 8 billion tokens, too. That's just how it goes now. And this is the part where I want to talk to developers. Because if you're building agents,
[11:45] most agentic teams do not pay enough attention to the actual cost structure of their agents. It's not just tokens anymore. If you heard the first part of this video, it's workflow units. It depends on your contracts. Your prototype may work because you built it and you know how it works and the volumes are tiny. You need to ask yourself as a builder if the API policy your company signed permits autonomous execution. You need to ask yourself, what is the billing unit? Is it successfully completed work? Is it any completed work? Is it attempts at work?
[12:15] Is it tokens? And then you need to optimize for that because I guarantee you your CTO will be asked, how are we optimizing this massive scale up in agentic workflow around costs? What is the budget cap here? Is this a reasonable thing for us to be doing or are we just turning dollars into tokens for little output? And so you need to start to look at your operation classifications in detail. You need to understand where are your agents going to be spending tokens to read versus write versus approve versus
[12:45] execute. What's the blast radius and impact of that from a work value perspective? And those distinctions matter because they may directly impact the pricing on the vendor meter. And all of this, all of this is about deployable agents that matter, right? An agent that knows which tools are expensive, which actions are reversible, when to read versus when to write is an agent that a company can put into production. An agent that treats every tool call the same way regardless of the budget is an incident waiting to happen. So I put together on the Substack a full
[13:15] operation taxonomy for this and a cost dashboard I would use for an enterprise agent product. It is something that as a developer or as a builder, you have to have an eye on if you want to actually deploy these agents in production. And I do know many developers who pay attention to this. This is not all developers, but I just want you to be aware that most developers I'm talking to who are cost-aware still think in terms of tokens. And at the contractual level, it is shifting past tokens now. You have to think more broadly and talk more deeply about the contracts with legal and with your CTO. There's just no
[13:45] other way around it. So, what do you actually do with this before your next renewal conversation? The worst move you could do is to wait until your usage is embedded because you have no leverage then, right? If employees use the agent every day, if customer workflows depend on it, the power dynamic shifts. The vendor knows the work has moved and the value is in the agents and turning it off will hurt and they will charge you accordingly. So, the the better move is to negotiate agent access up front before agent usage becomes mission critical. Be very clear what is included
[14:15] in current seats. Ask whether agents acting on behalf of users are covered. Ask whether an independent agent requires its own entitlement. Ask whether third-party agents can use the same governed path as the vendor's own agent. Ask which actions are going to consume credits or not. Ask whether failed actions count. Ask whether the rate card is fixed for the term. Ask whether usage logs can be exported. Ask whether caps can be set by department, by workflow, by agent. Most importantly, ask how the commercial model changes if
[14:46] the agent reduces human seats. Because that question cuts at the SaaS economics in play here. If an AI agent resolves a huge volume of customer support requests, can you reduce your support seats? If a sales agent keeps your records updated, can occasional CRM users move to lighter access? If an HR agent handles routine questions about vacation, does every employee need the same tier? Sometimes the answer is no for good reasons, but the question needs to be asked. Otherwise, you end up with
[15:16] the worst possible hybrid, an old seat count plus a new and untransparent agent consumption bill. So, I have the full renewal question list over on Substack with 15 questions organized by what to ask before you sign, what to ask about the agent's access path, and what to ask about the commercial model when agent work starts replacing human work in some fashion, which is not the same as replacing jobs, by the way. Anyway, you can go get it. The agent era is changing the commercial unit of software. It's not just changing the interface.
[15:46] The seat was always a proxy for human work and value created, and the agent license is becoming a meter for that same unit of value, except now that it's been delegated. Builders who understand that distinction between how agent work bills and how human work bills are going to design and negotiate much better deals and avoid the trap of shipping an agent that works until the bill shows up. So, if you want to keep learning how to build with AI, hit subscribe, and for that deep version on this one, check out
[16:16] the Substack. Happy building. Make sure you understand what you're signing when you get those contracts. Cheers.