Salesforce Booked $800M in AI Revenue Last Quarter. That Money Came From You.

Salesforce just reported that agent force their agent product hit $800 million run rate in AR up 169% year-over-year with 2.4 4 billion agentic work units process 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 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 are 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 building costs. increasingly is going to be other players involved who are 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 versus one that's just effectively SAS 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 costear agent look like in production? Because that's the thing that's going to matter long term. For two decades, SAS pricing ran on a very simple trick. You turn work into seats which leads to predictable revenue which leads to predictable growth in multiples. And because we continued to need to introduce more work to computers, do more work on computers, have specialized software for the workforce using computers, that whole model turned into an absolute bonanza of cash flow for SAS 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 HubSpot, IT on Service Now. Everybody's having to rethink their business models. And the companies I just named are at very different spots on that rethinking Agentic spectrum. 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, update a support ticket, grab a Service Now 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 SAS 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 decisions about the real cost of aentic 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, 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 obviously a massive scale, right? Microsoft 365 C-pilot absolutely still uses SE pricing, but Copilot Studio pricing makes that second agentic meter extremely explicit. C-pilot credits measure agent usage and different features consume credits at different rates, right? Answers, generative answers, agent actions, uh, grounding in the graph, flow actions, premium reasoning, whatever that means. And so the realistic monthly cost for a 100C 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 pricing complexity in what used to be a very clear per se cost. Do I use premium reasoning for co-pilot? How much do I use? 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. Eight billion in a month. That was not the case in 2025. We are scaling token usage really, really fast and it makes it difficult to plan when the SAS survival model is to charge you 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. Service Now comes at this from the operational side. It's our third example. The action fabric reframes Service Now 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 opens a change request, then service now has a claim that it is providing the workflow substrate and the operational reliability around that action and it can charge accordingly. So these three vendors, right, Microsoft, Salesforce, Service Now, they are all making kind of the same move, right? The seed 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 Zenesk's outcome pricing, HubSpot's per resolution model, Workday's agent system of record, and Atlassian 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- aent. SAP's 2026 API policy draws a very hard line around how customers and thirdparty 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. 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. Because 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 policy language to push back for vendors in the Substack here. If you're in an active negotiation, I' 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 clawed 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 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 customer relationship workflow. Service Now meters governed operational actions because Service Now defines a large part of the enterprise action layer. Microsoft wants co-pilot 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 agents economics end up belonging to somebody else. So, what does a fair agent license actually look 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 built 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 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 does a rent seeking version look 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 rentse seeeking 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 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 lockins 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 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 license and 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 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 because 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, 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 co company assigned permits autonomous execution. You need to ask yourself what is the billing unit. Is it successfully completed work? Is it incompleted work? Is it attempts at work? 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 energetic 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 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 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 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 upfront before agent usage becomes missionritical. Be very clear what is included 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 the agent reduces human seats because that question cuts at the SAS 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 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 agents 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. 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 bill builds and how human work bill builds 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 the Substack. Happy building. Make sure you understand what you're signing when you get those contracts. Cheers.