Nate B Jones
Tu factura de SaaS acaba de incorporar un segundo contador. Estás a punto de pagarlo
Pregúntale al tutor sobre este vídeo
Entra con un email verificado y pregúntale al tutor lo que quieras sobre este vídeo.
TL;DR
Resumen de investigación
▶ El trabajo de los agentes introduce nuevos cobros
El narrador abre con cifras atribuidas a Salesforce: Agentforce habría alcanzado una tasa anual de ingresos (ARR) de 800 millones, un aumento interanual del 169 % y 2.400 millones de unidades de trabajo agéntico procesadas. Aclara que son unidades de trabajo, no tokens, y dice que Salesforce mide acciones completadas dentro de la plataforma. También menciona que Microsoft Agent 365 pasó a disponibilidad general esa semana, con un precio de 15 dólares por usuario al mes; describe su licencia de gobernanza como una forma de gestionar las acciones de agentes en el entorno Microsoft, que funciona como plano de control. Advierte que los costos de flujos de trabajo agénticos a escala incluirían otros proveedores además de los modelos. Plantea cuatro preguntas para las renovaciones: qué unidad se cobra y si conviene al negocio; qué sería una licencia justa frente a una protección de asientos SaaS; si el lenguaje de políticas puede bloquear agentes; y cuál será el costo de operar un agente en producción.
▶ Por qué el modelo por asiento está en cuestión
El narrador describe el modelo SaaS de las últimas dos décadas como una conversión del trabajo en asientos, que produjo ingresos y crecimiento previsibles para las empresas de software. Sostiene que ese esquema está en riesgo cuando, por ejemplo, se cuestiona cobrar diez asientos de CRM para diez personas. Nombra Workday para RR. HH., Jira para ingeniería, HubSpot para marketing y ServiceNow para TI, y dice que estas empresas están en distintas etapas de adaptación a los agentes. Explica que antes los proveedores podían cobrar por el acceso de cada persona, pues el humano era la unidad de valor; ahora, un agente puede leer un CRM, actualizar tickets o incidencias y activar flujos sin que una persona use directamente el software. Según el narrador, el sistema sigue almacenando datos, permisos y registros de auditoría, pero el asiento ya no representa por sí solo el intercambio de valor. Por eso, afirma, los proveedores desarrollan nuevos modelos de precios para el trabajo agéntico.
▶ Tres modelos de cobro por trabajo delegado
El narrador presenta Salesforce como un ejemplo explícito: Agentforce usa créditos flexibles y unidades de trabajo agéntico; actualizar un registro, resumir un caso, responder una consulta, ejecutar un prompt o iniciar un flujo consume del mismo medidor. El asiento puede seguir existiendo, pero también se cobran créditos por acciones del agente. En Microsoft, Microsoft 365 Copilot conserva precios por asiento, mientras Copilot Studio agrega créditos de uso del agente. Menciona distintas tasas de consumo para respuestas, respuestas generativas, acciones de agente, fundamentación en el grafo, acciones de flujo y razonamiento premium; expresa incertidumbre sobre el significado de este último. Dice que el costo mensual real de una empresa de 100 asientos con cargas de trabajo agénticas modestas puede aumentar con los créditos de ejecución y que el uso de opciones premium puede elevar la factura. Relaciona esta complejidad con la dificultad de planificar, e informa que habló con un desarrollador que había usado 8.000 millones de tokens en un mes; afirma que el uso de tokens crece rápidamente y que algunos responsables de tecnología están frustrados con las compras. Como tercer ejemplo, describe la capa de acciones de ServiceNow como una vía gobernada para que los agentes ejecuten trabajo operativo con identidad, permisos y auditoría; sostiene que la empresa cobra por unidades de trabajo operativo, no por llamadas API. Resume que Salesforce, Microsoft y ServiceNow mantienen el asiento y añaden un segundo medidor para el trabajo delegado.
▶ Políticas de acceso, contratos e incentivos de plataforma
El narrador dice que su publicación de Substack presenta un análisis de ocho proveedores, incluidos los precios por resultado de Zendesk, el cobro por resolución de HubSpot, el sistema de registro de agentes de Workday y el patrón de créditos de Rovo de Atlassian. Advierte que las reglas de cobro podrían sentirse contrarias a desarrolladores y agentes. Atribuye a la política de API de SAP para 2026 restricciones sobre el uso de sus API por clientes y terceros, incluidos sistemas de IA que planifican, seleccionan o ejecutan secuencias de llamadas fuera de arquitecturas avaladas por SAP. Por ello, afirma que antes de conectar un agente a datos de SAP habría que comprobar si el contrato lo permite; SAP podría cobrar por el acceso o no permitirlo. Recomienda abordar en la negociación qué proveedores de agentes se usarán, qué acceso necesitan, cómo limitar costos y cómo asegurar una experiencia de desarrollo útil; dice que esas conversaciones no ocurren a menudo. Expone su interpretación de los incentivos: quien define la unidad de trabajo busca fijar su precio. Vincula Salesforce con acciones de CRM, ServiceNow con acciones operativas, Microsoft con el grafo de productividad y SAP con vías autorizadas para controlar riesgos operativos en sistemas de altas consecuencias. Advierte que, sin comprender esos incentivos y medidores, la economía de los agentes puede quedar en manos del proveedor.
▶ Criterios para una licencia justa
El narrador propone que una licencia justa tenga un medidor visible, una unidad comprensible y transparente, y permita al cliente pronosticar el uso. Dice que el trabajo fallido o de poco valor no debería cobrarse igual que el trabajo completado; los agentes de terceros deberían tener una vía gobernada; y el proveedor debería distinguir entre leer, redactar, escribir, aprobar y ejecutar al facturar. Añade que el comprador debería poder fijar límites, exportar los datos de uso y conservar la tarifa acordada después de adoptar agentes. Aclara que no acusa de prácticas deshonestas a ninguno de los proveedores mencionados, aunque dice haber visto patrones similares en otras empresas. Describe esos patrones como cobrar por acceso ambiguo a IA sin explicar el consumo, favorecer el agente propio, cobrar al cliente por usar sus datos en sus flujos, facturar intentos fallidos, ocultar el medidor hasta la renovación, vender créditos que vencen mientras se cobran excesos de inmediato y presentar bloqueos comerciales como seguridad. Sostiene que contratos confusos y pilotos dispersos impiden conocer el costo de llevar flujos a producción. Menciona una lista de verificación de nueve rasgos en Substack y recomienda hacer preguntas contractuales específicas ante el crecimiento previsto de los flujos agénticos. Reitera que conoce a otros desarrolladores que también consumieron 8.000 millones de tokens.
▶ Costos y diseño de agentes para producción
El narrador se dirige a los desarrolladores y dice que muchos equipos no prestan suficiente atención a la estructura de costos de sus agentes, que puede incluir unidades de flujo además de tokens y depender de los contratos. Recomienda comprobar si la política de API firmada por la empresa permite ejecución autónoma y determinar si se factura el trabajo exitoso, cualquier trabajo completado, los intentos o los tokens. Señala que la dirección de tecnología preguntará cómo controlar los costos de la expansión, cuál es el límite presupuestario y si el gasto genera suficiente resultado. Propone clasificar las operaciones para saber cuánto se gasta en leer, escribir, aprobar y ejecutar, y evaluar el valor y el alcance del impacto de cada acción, pues esas diferencias podrían afectar el precio del proveedor. Considera más aptos para producción a los agentes que reconocen qué herramientas son costosas y qué acciones son reversibles, y que eligen cuándo leer o escribir; describe como riesgo de incidente a un agente que trata igual todas las llamadas sin considerar el presupuesto. Menciona que preparó en Substack una taxonomía de operaciones y un panel de costos para un producto empresarial. Concluye que los desarrolladores deben pensar más allá de los tokens y hablar de los contratos con los equipos legales y de tecnología.
▶ Qué negociar antes de renovar
El narrador recomienda negociar el acceso de los agentes antes de que su uso quede integrado en procesos cotidianos o críticos, porque entonces habría menos margen de negociación y desactivarlos perjudicaría el trabajo. Sugiere aclarar qué incluyen los asientos actuales y preguntar si cubren agentes que actúan en nombre de usuarios, si un agente independiente necesita una licencia propia y si los agentes externos pueden seguir la misma vía gobernada que los del proveedor. También recomienda preguntar qué acciones consumen créditos, si se cobran las fallidas, si la tarifa queda fija durante el plazo, si se pueden exportar registros de uso y establecer límites por departamento, flujo o agente. Pide preguntar cómo cambia el modelo comercial si un agente reduce la necesidad de asientos humanos. Lo ilustra con preguntas sobre agentes que resuelven solicitudes de soporte, mantienen registros de ventas o contestan consultas rutinarias de vacaciones; reconoce que puede haber razones válidas para mantener los niveles de acceso, pero dice que la cuestión debe plantearse. De lo contrario, advierte, podría persistir el conteo antiguo de asientos junto con una factura agéntica nueva y poco transparente. Menciona una lista de 15 preguntas en Substack y aclara que sustituir trabajo humano no equivale necesariamente a reemplazar empleos.
▶ La unidad comercial del software está cambiando
En el cierre, el narrador sostiene que la era de los agentes cambia la unidad comercial del software, además de su interfaz. Presenta el asiento como una medida indirecta del trabajo humano y el valor creado, y la licencia de agente como un medidor de ese mismo valor cuando el trabajo se delega. Afirma que quienes comprendan la diferencia entre la facturación del trabajo de agentes y la del trabajo humano podrán diseñar y negociar mejores acuerdos y evitar lanzar agentes que funcionen hasta que llegue la factura. Invita a suscribirse y consultar su Substack para aprender más, y termina recomendando entender bien los contratos que se firman.
Transcripción completa
[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.