.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
If AI Models Become Interchangeable, What Should Vendors Actually Charge For?
As foundation models become cheaper, more capable, and easier to swap, durable pricing power moves away from the model and toward the system that turns intelligence into reliable work.
The question facing AI software vendors is no longer simply, “What does it cost to run the model?” It is: what, exactly, is the customer buying once the model is no longer scarce?
For the past several years, model access itself has been an understandable proxy for value. A vendor could point to a frontier model, a large context window, multimodal capability, or a proprietary fine-tune and reasonably argue that its product was differentiated by intelligence. That logic is becoming less durable. Model providers continue to improve price-performance, smaller models are closing capability gaps, open-weight alternatives are expanding, and infrastructure providers increasingly make multi-model routing a product feature rather than a bespoke engineering project. Stanford’s 2025 AI Index found that the inference cost of a system performing at the GPT-3.5 level fell more than 280-fold between November 2022 and October 2024.
That does not mean models cease to matter. They remain essential inputs, and for some high-stakes or unusually difficult tasks, model selection will remain consequential. But “we use a better model” is becoming a fragile basis for a software premium. When a competitor can call a comparable model tomorrow—or route the same task across multiple providers today—the model is better understood as an input cost and capability variable than as the product itself.
The defensible product is the harness: the system around the model that makes an agent useful, safe, integrated, observable, and economically viable in a real customer environment.
That distinction changes pricing. Vendors should not charge primarily for access to intelligence that customers increasingly view as abundant. They should charge for the work their harness performs: the governed, reliable execution of valuable tasks inside a customer’s operating environment.
This is the central implication of agentic monetization. As compute becomes a shrinking share of delivered value, pricing must move from inputs—seats, tokens, messages, model names—toward the level at which value is actually created: trusted activity, completed work, and, where attribution is credible, measurable outcomes.
The collapse of model-based pricing power
Model-based pricing fails for a simple reason: it prices a component whose scarcity is eroding.
The foundation-model market is still dynamic. Frontier models differ in reasoning quality, latency, modalities, tool use, safety behavior, and reliability. But for many commercial workflows, the buyer does not care whether an action was completed by one named model or another. A finance leader does not buy “tokens.” A support operations leader does not buy a particular model’s benchmark score. A revenue leader does not buy an agent because it can produce elegant prose. They buy faster case resolution, fewer manual touches, more qualified meetings, cleaner records, shorter close cycles, or more capacity without proportional hiring.
The market is already being designed around this reality. Amazon’s Bedrock AgentCore states that its harness can work with models from Amazon Bedrock, OpenAI, Google Gemini, and LiteLLM-compatible providers—and that providers can be switched mid-session without losing context. Google’s Model Optimizer similarly abstracts model selection behind a meta-endpoint intended to balance cost, quality, and customer preference. These are not minor platform conveniences. They signal a structural shift: model routing is becoming an operational decision that can be optimized continuously, not a permanent product identity.
The economics reinforce the point. Current model catalogs span wide price bands. OpenAI, for example, offers lower-cost and higher-performance models with materially different token rates, while Anthropic’s price lists distinguish standard, batch, cached-input, and regional options. A capable agentic product can therefore reduce cost by routing routine work to smaller or cheaper models, reserving premium inference for difficult moments, retrying selectively, caching repeated context, and narrowing tool payloads.
That creates a paradox for vendors that sell the model rather than the work. If a product’s price is explicitly tied to premium model access, its revenue logic is exposed every time a cheaper equivalent appears. If the vendor passes the savings through, revenue per unit falls. If it does not, buyers increasingly ask why they are paying a premium for an input that is widely available. Either way, the model layer exerts downward pressure on price.
This does not imply that all AI software becomes cheap. It means the source of premium pricing must change.
A useful analogy is cloud infrastructure. Few businesses pay a strategic premium because a vendor owns a processor. They pay for the reliability, security, integrations, workflow fit, control plane, and operational outcomes built on top of infrastructure. Foundation models are moving in the same direction. The more interchangeable the intelligence layer becomes, the more valuable it is to own the workflow layer that converts intelligence into dependable execution.
The mistake is to confuse a falling cost curve with a falling value curve. Compute costs may decline sharply while the value created by a well-designed agent rises. The question is whether the vendor has built the surrounding system necessary to capture that widening gap.
The harness is the product customers learn to trust
An agent is not a model with a chat interface. It is a model operating inside an environment: reading context, making decisions, calling tools, taking actions, checking results, escalating exceptions, and leaving behind an auditable record.
The harness is the layer that governs this work.
At a minimum, a production harness includes:
- Orchestration: deciding what steps to take, in what order, with which model, tools, and fallback paths.
- Context management: selecting the relevant customer data, policies, histories, and documents without flooding the model with irrelevant information.
- Permissions and identity: determining what the agent is allowed to see, change, approve, or send—and under whose authority.
- Integrations: connecting the agent to systems of record such as CRM, ERP, ticketing, support, communications, analytics, payments, and internal databases.
- Memory and state: retaining the right information across a task, across sessions, and across a customer relationship, while respecting governance requirements.
- Verification and guardrails: checking whether work was completed correctly, identifying failure modes, and routing sensitive cases to a human.
- Observability and auditability: recording what the agent did, why it did it, what it accessed, what it changed, what it cost, and where intervention was required.
- Feedback loops: converting corrections, exceptions, user feedback, and business results into improved prompts, policies, routing, retrieval, workflows, and evaluations.
This is not theoretical infrastructure. Google describes orchestration as the operational core of multi-step agent work and identifies long-term memory, transaction records, security controls, error handling, and monitoring as core agent-system requirements. AWS similarly defines the agent harness as the combination of the orchestration loop and the production infrastructure beneath it: tool connections, sandboxing, memory, identity, observability, networking, and compute.
Each component is materially harder to replace than a model API call.
A competitor can copy a prompt. It cannot instantly replicate years of embedded workflow knowledge: the approval rules that distinguish a routine refund from a fraud risk; the sequence of systems a claims analyst must inspect; the exception taxonomy a revenue-operations team has built; the logic for resolving conflicting customer records; the confidence thresholds that determine whether an agent acts, asks, or escalates.
Nor can it easily replicate trust. In a low-consequence setting, an agent can draft a note and let a person decide whether to use it. In a consequential setting, the product must prove that the agent used the right data, followed the right policy, operated within authority, and left an adequate audit trail. Those requirements create implementation depth—and that depth can become a moat.
The harness is also where customer-specific learning accumulates. A model may be broadly capable, but an agent becomes commercially useful through increasingly precise knowledge of a customer’s data model, taxonomy, operating rules, preferred outputs, exceptions, and approval patterns. The vendor that captures feedback from completed work can improve not just language quality but operational performance: fewer handoffs, fewer retries, fewer false escalations, higher completion rates, and better economics.
This is why the best moat is not “our model is smarter.” It is: our system is better at getting this category of work done, within this customer’s constraints, with evidence that it was done correctly.
That is a much stronger thing to price.
From model consumption to the Agentic Monetization Spectrum
Once the harness is recognized as the value-creating layer, the pricing question becomes more precise. A vendor should not ask, “Should we use seats or usage?” It should ask, “What is the customer actually buying from this agent, and how much work is the agent completing without a human?”
Monetizely’s Agentic Monetization Spectrum offers a useful framework for answering that question. It evaluates an agent across three dimensions: Zero-Human Ability, Operational Domain, and the Output/Cost Curve. The framework’s core insight is that the appropriate pricing metric changes as human involvement falls, the agent’s scope broadens, and output value grows faster than compute cost.
The first dimension, Zero-Human Ability, asks how much of the work remains human-led.
When a human is doing most of the work and the AI assists—drafting, summarizing, recommending, or accelerating a narrow task—the seat can still be a useful anchor. The buyer is effectively purchasing a better tool for an employee. The value is tied to the worker’s access, adoption, and productivity.
When the human delegates, reviews, and handles exceptions, the unit should move closer to a defined activity or completed job. Here, the agent is doing meaningful work, but oversight remains part of the operating model. Examples might include a completed customer interaction, a reconciled transaction, a processed document, a qualified record, or a prepared compliance packet.
When the agent does most of the work and human intervention is rare, pricing should move toward output or outcome. At that point, the customer is not primarily buying software access. They are buying a digital operating capability.
The second dimension, Operational Domain, asks how broad the agent’s responsibility is. A narrow task assistant is not priced like an end-to-end workflow agent. And a cross-functional agent that coordinates activity across support, billing, operations, and finance cannot be priced like a simple point feature.
The third dimension, the Output/Cost Curve, is especially important in a world of falling inference costs. If output value rises roughly in line with cost, a usage-oriented pricing model may be appropriate. If output value begins to outpace compute by multiples, the vendor has more room to price against customer value rather than cost. And if an agent produces output whose value is orders of magnitude greater than its operating cost, anchoring price to tokens becomes strategically absurd.
A well-designed contract can still account for cost. It should not ignore cost floors, especially for long-running, multimodal, or tool-intensive agents. But the customer-facing price should be anchored to the highest defensible layer of value—not to the vendor’s cheapest measurable input.
This is where many vendors leave money on the table. They measure what is easy—messages, tokens, API calls—rather than what customers value: work completed with autonomy and reliability.
Why seats and usage both mis-price a harness-driven product
Seat-based pricing is not dead. It is simply incomplete.
Seats work best when the user is the unit of value: a salesperson using a copilot, a developer using coding assistance, an analyst using a research tool. They make procurement easy, create predictable budgets, and match familiar SaaS buying behavior. But seats become less representative of value when one employee can supervise many agents, when agents work asynchronously, or when the software completes tasks while nobody is actively logged in.
In fact, agentic AI can compress the very seat base on which traditional SaaS monetization depends. BCG reports that 40% of IT buyers cite seat reduction as their primary lever for lowering software spending, a pressure likely amplified when agents absorb portions of user work. If a product helps a team do the same work with fewer people, charging exclusively per employee can create a contradiction: the more value the product creates, the smaller its revenue base becomes.
Pure usage pricing has the opposite problem. It protects the vendor’s variable margin but often asks the customer to pay for technical activity that does not map cleanly to business value. Token charges, model calls, and even generic “agent actions” can feel arbitrary. A simple task and a complex task may consume very different amounts of compute without producing proportionally different business value. Conversely, a highly valuable action may require little compute.
Usage-only pricing can also generate budget anxiety. Buyers do not want to discover that an agent’s exploratory reasoning, retries, long context windows, or failed tool calls produced a surprise bill. Gartner has warned that unpredictable cost is undermining buyer confidence in agentic AI ROI and expects outcome, volumetric, and predictability-oriented models to overtake technical metrics for many agentic solutions.
The answer is usually a hybrid structure built around three protections.
First, protect the customer’s predictability. Establish a recurring platform or access fee that covers the durable value of the harness: governance, integrations, administration, permissions, configuration, reporting, support, and a clear baseline of capacity. This is not a disguised token bundle. It is payment for an operating layer the customer relies on whether the agent is busy every minute or not.
Second, protect the vendor’s margin. Define billable work units that absorb meaningful variations in activity and align with value. Depending on the use case, that might be resolved cases, completed reconciliations, processed claims, qualified opportunities, active managed workflows, approved documents, booked jobs, or successfully completed onboarding journeys. Include sensible fair-use boundaries, capacity bands, and protections for unusually expensive workloads.
Third, protect the value exchange. Where attribution is clear and the vendor can influence the result, add an outcome-based component: a share of verified savings, revenue, recovery, conversion, or cycle-time improvement. But outcome pricing should be underwritten selectively, not treated as a universal badge of sophistication. It works only when definitions, baselines, data access, and attribution are credible.
BCG’s research reaches a similar practical conclusion: hybrid models are likely to combine an agent or subscription component with payment for completed jobs, while financial-outcome pricing remains most suitable where vendors can manage attribution and risk.
The goal is not to choose a philosophical side in the seats-versus-outcomes debate. It is to choose a commercial structure that reflects where the agent sits on the spectrum.
Monetization Engineering: making “work performed” billable
Changing the pricing metric is easy on a slide. Making it operational is much harder.
If the billable unit is no longer “a person with access,” the company needs a system that can measure, explain, forecast, quote, invoice, and govern the work the harness performs. This is Monetization Engineering: treating pricing logic, cost architecture, product telemetry, and operational controls as an integrated discipline rather than a finance exercise performed after launch.
The first requirement is a rigorous work taxonomy. Product, engineering, finance, sales, and customer success must agree on the hierarchy of activity: model call, tool call, step, task, workflow, completed job, and business outcome. Not every level should be billable. But every level should be observable. Without a shared taxonomy, finance cannot model margins, product cannot create understandable entitlements, and customers cannot audit invoices.
The second requirement is a clear definition of completion. An agent opening a ticket is an activity. Resolving the ticket may be a completed job. Reducing repeat contacts may be an outcome. These are not interchangeable. The contract must specify what qualifies, what evidence is retained, which exceptions are excluded, when a human takeover changes the classification, and how disputes are handled.
The third is unit economics at the harness level. Teams must understand not just average model cost, but cost per successful work unit by customer, workflow, model route, tool chain, and exception type. Averages conceal danger. One account may use a short, standardized path while another triggers long reasoning chains, repeated searches, document parsing, expensive tools, and manual review. BCG notes that variable AI costs can create dramatic margin variance across accounts; treating all usage as economically identical is a recipe for accidental unprofitability.
The fourth is entitlement architecture. Customers need clear answers to practical questions: What is included? What happens at the limit? Can the agent continue at a different rate? Can administrators set spend caps? Which teams, workflows, connectors, environments, or levels of autonomy are enabled? Pricing is only credible when the product can enforce the commercial promise.
The fifth is real-time transparency. Agentic systems should expose a customer-facing work ledger: jobs attempted, jobs completed, human escalations, success rates, latency, exceptions, and usage against contractual allowances. A token dashboard is insufficient. Customers should be able to see the business activity they are paying for.
Finally, Monetization Engineering requires a cross-functional operating cadence. Engineering decisions become P&L decisions when they determine model routing, retrieval depth, retry behavior, tool selection, caching, and escalation. The public framing of Monetizely’s work makes this point directly: in agentic businesses, design choices inside the harness become cost decisions at transaction scale, making monetization a first-class system discipline alongside model and harness design.
This is the operational consequence of commoditized models: pricing cannot be static because the production system is not static. As models improve and costs shift, the vendor should be able to change the underlying routing and architecture without forcing a commercial reset for customers. That is another advantage of pricing work rather than named-model access.
Pricing power moves to reliability, accountability, and embedded workflow
The deepest implication is that pricing power will increasingly belong to the vendor that owns the accountable execution layer.
A generic model produces possibility. A harnessed agent produces work. The difference is not merely technical. It is commercial.
Customers will pay premiums when an agent does one or more of the following:
- Completes a costly or time-sensitive job that previously required human labor.
- Operates reliably within a specific domain, using the right data, rules, and tools.
- Reduces risk through permissions, controls, verification, audit trails, and human escalation.
- Improves with use because feedback and operating knowledge accumulate in the system.
- Integrates into the customer’s system of record, making replacement operationally disruptive rather than merely technically possible.
- Proves value transparently, with metrics that connect activity to customer outcomes.
The moat, then, is not model ownership alone. It is a combination of workflow depth, proprietary operating data, trusted integrations, domain evaluation, accumulated feedback, embedded governance, and customer confidence that the agent can act without creating unacceptable risk.
This is also why the most valuable agentic products will not look like generic chatbots with expensive wrappers. They will look like specialized operating systems for categories of work. Their commercial model will reflect that reality: a stable fee for the trusted platform, a variable fee for meaningful work performed, and an outcome component only where the vendor can credibly stand behind the result.
Foundation models may become interchangeable. Compute may continue to get cheaper. Neither development eliminates pricing power.
It simply relocates it.
The vendors that win will be the ones that stop charging for the intelligence they rent and start charging for the reliable, governed, economically valuable work their harness makes possible.