Platform or Agent? The Two-Layer Pricing Decision Every GaaS Vendor Gets Wrong

Table of Contents

• The Two Things You Are Actually Selling
• Why the Distinction Matters More in Agents Than in SaaS
• Pricing the Platform: What Buyers Pay to Access and Control
• Pricing the Agents: What Buyers Pay for Work Done
• The Cost Allocation Trap
• Four Common Architectures and When Each Wins
• How the Split Changes as You Scale
• Insights Most People Overlook
• References

The Two Things You Are Actually Selling

Walk into any agentic AI company and ask the founders what they sell. You'll usually hear one answer, "we sell an AI sales development rep" or "we automate claims processing." But look at the codebase and the cloud bill and you'll find two distinct things.

The first is a platform: the orchestration layer, the agent runtime, the memory store, the tool-connection plumbing, the permissioning and audit logs, the dashboards a human uses to watch what the agents do, the evaluation harness that catches regressions. This is infrastructure. It exists whether an agent runs once a day or ten thousand times.

The second is the agents themselves: the configured, deployed workers that read an email, draft a reply, file a ticket, reconcile an invoice, or book a meeting. These produce the thing the customer actually bought. Each run consumes tokens, calls tools, and, if it works, delivers an outcome.

The reason this matters for pricing is that those two layers have completely different cost structures and completely different value to the buyer. The platform is a fixed-ish cost to you and a capability to them. The agents are a variable cost to you and a result to them. Pricing them as if they were one product is the original sin of GaaS monetization, and it shows up on the invoice as a number nobody can explain.

This piece sits inside the broader GaaS pricing taxonomy, per-task, per-outcome, per-seat, but it asks a more structural question that comes before you pick a meter: which layer are you metering at all?

Why the Distinction Matters More in Agents Than in SaaS

Traditional SaaS didn't force this question because the marginal cost of one more user clicking around was effectively zero. You priced per seat, the seats covered the servers with room to spare, and everyone moved on. The product was the platform, and "usage" was just login frequency.

Agents break that model in two places.

First, the marginal cost of an agent doing work is not trivial. A single complex agent run can chew through hundreds of thousands of tokens across multiple model calls, retries, and tool invocations. Andreessen Horowitz has written about how AI's variable cost structure inverts the classic software margin curve, and that inversion is exactly why you can't treat agent execution as a free byproduct of platform access. If you bury agent cost inside a flat platform fee, your gross margin becomes a hostage to your customers' behavior.

Second, the value moment shifts. In SaaS, value accrued from a human using a tool well. In GaaS, value accrues when an agent completes a unit of work the customer would otherwise have paid an employee or vendor to do. That value is countable, resolved tickets, qualified leads, reconciled accounts, which is precisely why outcome and per-task meters make sense at the agent layer and feel absurd at the platform layer. Nobody wants to pay per outcome for the privilege of having a dashboard.

So the structural truth is: the platform is where you charge for the right to operate, and the agents are where you charge for operation. Conflating them is how vendors end up with pricing pages that buyers literally cannot reason about.

Pricing the Platform: What Buyers Pay to Access and Control

The platform fee is your floor. It's the predictable, committed revenue that makes the business fundable and the customer relationship sticky. What buyers are actually paying for here is rarely the agents themselves, it's everything around the agents that lets a serious organization trust them.

Think about what an enterprise buyer needs before they let an autonomous agent touch production systems:

• Governance and permissioning, who can deploy which agent, against which systems, with what spending or action limits.
• Observability, traces of every decision, every tool call, every prompt, so a human can audit a failure after the fact. This connects directly to the agent reliability and audit themes running through the cluster.
• Security and isolation, credential vaulting, data residency, the controls a CISO signs off on.
• Integration surface, the connectors to Salesforce, NetSuite, Zendesk, internal APIs.
• Human-in-the-loop tooling, the approval queues and override controls.

None of that scales linearly with agent runs, so none of it should be metered per run. Price it as a platform subscription, often tiered by number of connected systems, number of distinct agent types deployable, level of security and compliance (SOC 2 vs. HIPAA vs. FedRAMP), or seats for the humans who supervise. This is where per-seat pricing still legitimately lives: not for the agents, but for the operators who govern them. (For why per-seat dies at the agent layer, see the case against per-seat pricing.)

The platform tier is also your natural home for floor-and-ceiling guarantees and minimum commitments. Enterprise procurement wants a number it can budget; the platform fee gives them one even when agent consumption is variable.

Pricing the Agents: What Buyers Pay for Work Done

This is the layer where the interesting, contested pricing lives, per-task, per-outcome, per-resolution, credits, prepaid pools. The agent layer is where consumption happens, and consumption is what your variable cost tracks.

A few principles that hold up across deployments:

Meter the agent on something the customer recognizes as work. Tokens are your cost unit, not the customer's value unit. A buyer doesn't experience "1.4 million tokens", they experience "47 support tickets resolved." Whenever you can, translate the meter into the customer's currency of value: tasks completed, tickets resolved, documents processed, meetings booked. The currency-of-value question, time saved vs. revenue gained vs. cost cut, should drive which unit you expose.

Let the meter follow the margin, not the other way around. If your model and tool costs per task are volatile (and with model routing and provider price swings, they are), don't expose a raw cost-plus number that fluctuates. Use credits or a fixed per-task price you've stress-tested against the worst-case run. Passing through volatile inference costs directly is how you turn every model price change into a customer-facing crisis.

Cap the downside for both sides. Usage caps and credit pools protect the customer from a runaway agent racking up a five-figure bill overnight, and they protect you from a customer whose workload silently 10x's while they're still on last quarter's commit.

The agent layer is also where the philosophical fights happen, outcome-based pricing assumes you and the customer can agree on and audit what the outcome even is, which is harder than the pitch deck admits. But the structural point stands: this layer flexes with usage, so its pricing must flex too.

The Cost Allocation Trap

Here is the mistake that quietly kills GaaS gross margin, and almost nobody talks about it: misallocating costs between the two layers.

Founders love to price the platform fee to cover "the product" and then treat agent execution as a thin markup on inference. The trap is that a huge share of your real cost lives in the gray zone between layers, and they bill it to the wrong one.

Consider evaluation and monitoring. Every serious agent product runs continuous evals: replaying tasks, scoring outputs, catching regressions when a model updates. Those eval runs burn tokens. Is that a platform cost (it's reliability infrastructure) or an agent cost (it's per-agent quality)? If you call it platform and bake it into the flat fee, a customer running fifty agent types is consuming far more eval compute than your flat fee assumed, and you're subsidizing them. If you call it agent and meter it, the customer sees a charge for work they didn't ask for.

Retries are the same story. A task that fails and retries three times costs you 3x the tokens but delivers one outcome. If you price per outcome, you eat the retries, fine, as long as you priced the outcome to absorb a realistic retry rate. If you price per task and count retries as tasks, the customer feels nickel-and-dimed for your unreliability. McKinsey's work on capturing value from enterprise AI repeatedly lands on the same point: the firms that profit are the ones with disciplined unit economics, not the ones with the cleverest meter.

The discipline that saves you: draw an explicit line for every cost. Fixed-regardless-of-volume costs (orchestration, dashboards, storage of audit logs, the humans who keep it running) go to the platform fee. Costs that scale with the work the customer asked for go to the agent meter. Costs that scale with your operational choices, retries, evals, model routing overhead, graceful-degradation fallbacks, must be priced into one layer or the other deliberately, never left to fall wherever the accounting lands. A margin you didn't decide on is a margin you'll lose.

Four Common Architectures and When Each Wins

There's no universal split. The right architecture depends on who your buyer is and how predictable your costs are. Four patterns dominate.

Platform fee plus pure consumption

A committed platform subscription plus per-task or per-outcome agent charges. This is the hybrid model done right, and it's the default for a reason: predictable floor, usage-aligned upside. Best when buyers are mid-market to enterprise and want both budget certainty and pay-for-value. The risk is bill complexity, so the platform fee has to clearly "buy" something the customer values on its own.

Platform-only (flat, agents included)

One price, unlimited (or generously capped) agent usage. Some vendors are returning to flat pricing precisely because buyers are exhausted by metered anxiety. This works when your per-task costs are low and predictable, when usage is naturally self-limiting, and when simplicity is a competitive weapon. It fails catastrophically if a few power users can drive consumption to the moon, flat pricing is a bet on your usage distribution being well-behaved.

Agent-only (no platform fee)

Pure per-outcome or per-resolution, no base. Intercom's Fin popularized per-resolution pricing with essentially no platform tax. Brilliant for land-and-expand and for lowering the barrier to a first "yes," because the customer pays nothing until the agent works. The danger is that you've given away the platform, all that governance and observability infrastructure, and you only monetize it through volume you don't control. Great for fast adoption, brutal on early-stage cash flow.

Tiered platform with consumption ceilings

Platform tiers that each include a bucket of agent usage, with overages above the ceiling. This is the credits-and-prepaid-pools pattern, and it's emerging as a favorite because it combines the budget comfort of a subscription with consumption alignment. Buyers know their bucket; you know your floor; overage handles the long tail.

The choice between these isn't aesthetic. It's a function of cost volatility and buyer sophistication. Low, stable per-task cost plus simplicity-seeking buyers → lean flat. High, volatile cost plus FinOps-savvy buyers → hybrid with explicit consumption metering and caps.

How the Split Changes as You Scale

The platform-vs-agent split isn't a one-time decision. It migrates as the company grows, and vendors who lock it in early get stuck.

Early on, you almost always under-price the platform and lean on agent consumption to prove value, you need the easy "yes," so you minimize the upfront commitment. That's correct for getting in the door. But it trains customers to see you as a metered utility, which makes raising a platform fee later feel like a price hike rather than a packaging change.

As you mature and move upmarket, the platform fee has to grow into its real job: capturing the value of governance, security, and reliability that enterprise buyers genuinely pay for. The agents become the variable layer on top of a meaningful committed floor. This is also when the annual-contract-versus-unpredictable-usage tension bites hardest, because procurement wants to fix a number against a workload neither of you can forecast.

The trap at scale is repricing as model costs fall. When inference gets cheaper, your agent-layer margin balloons, which is great until a competitor passes those savings through and your customers notice. The vendors who handle this well decouple their agent pricing from raw model cost early (via credits or outcome pricing), so a 10x drop in token cost becomes margin expansion they control rather than a grandfather-clause repricing crisis they're forced into.

The through-line across the whole lifecycle: the platform fee should trend toward capturing strategic value (trust, control, integration), and the agent meter should stay disciplined against variable value (work done). When those two roles blur, when the platform fee tries to capture usage value or the agent meter tries to fund fixed infrastructure, the pricing model starts working against the business instead of for it.

Insights Most People Overlook

The platform fee is your reliability moat, and underpricing it signals you don't believe in your own governance. Founders slash the platform fee to win deals, but enterprise buyers read a near-zero platform price as "this vendor's controls aren't worth much." The governance layer is often the real reason a CISO approves an autonomous agent at all. Charging confidently for it is a trust signal, not a tax.

Retries and evals are the silent margin killers, and they belong to neither layer cleanly. Almost every GaaS pricing model assumes a clean mapping from "task" to "cost." Reality is messier: a single customer-visible task can spawn retries, fallback model calls, and continuous background evaluation that the customer never sees and never asked for. If you don't explicitly assign these costs to a layer and price them in, they migrate straight to your gross-margin line. This is the difference between a 70% and a 40% margin business, and it's invisible until you scale.

Pricing the platform and agents separately lets you run different price-elasticity strategies on each. Because the layers serve different psychological needs, certainty vs. value-for-work, you can hold the platform fee firm (buyers tolerate predictable subscriptions) while aggressively experimenting on the agent meter (where competition and value perception actually move). Vendors who price both as one blob can't run these experiments independently and end up over-discounting the wrong thing in a deal.

Per-outcome pricing at the agent layer structurally favors incumbents, and your platform fee is how a challenger survives that. Outcome pricing rewards whoever has the most data to make agents succeed cheaply, which usually means the incumbent. If you're the challenger, leaning entirely on the agent-outcome meter means competing on exactly the axis where you're weakest. A strong platform layer, superior observability, governance, integration, gives you a value story that doesn't depend on out-executing the incumbent on raw outcome cost.

The "unlimited agents" plan is a platform-layer bet disguised as an agent-layer offer. When a vendor advertises unlimited agent usage, they are not actually giving away the agents, they're betting that platform-layer lock-in (your data, your integrations, your audit trail) will retain the customer long enough to monetize through expansion, upsell, and switching cost. Read every "unlimited" offer as a statement about where that vendor believes their defensible value lives. If their platform layer is thin, "unlimited" is a countdown to a margin crisis.

References

• The Economics of Generative AI, Andreessen Horowitz
• The State of AI, McKinsey & Company (QuantumBlack)