Your Happy Path Is Your Expensive Path: The Agent That Costs More When It Wins

A failed agent run is cheap. It misroutes a query, hits a dead end, returns "I couldn't help with that," and burns maybe a few hundred tokens doing it. A successful run is the disaster. It retrieves context, reflects on it, calls three tools, reflects again, and stitches together a confident multi-paragraph answer — fifty times the token spend of the failure that cost you nothing.

This is the uncomfortable shape of agent economics: your happy path is your expensive path. The outcome you are selling, the one your marketing page promises, the one users thank you for, is the single most costly thing your system can do. And if you priced the product the way SaaS has been priced for fifteen years — a flat monthly fee per seat — then every time the agent does its job well, it quietly erodes your margin.

Most teams discover this backwards. They watch cost dashboards, see failures are cheap, and conclude that reliability work will save money. It won't. Raising your success rate raises your bill.

Why the Successful Run Costs Fifty Times More

Start with the mechanics, because the intuition here is genuinely counterintuitive and worth making concrete.

A single-shot chat completion is one prompt in, one response out. An agentic run is a loop. Each turn re-sends the accumulating context — the system prompt, the conversation history, the tool definitions, every prior tool result — back to the model. The context does not stay flat. It grows with every step, and you pay for the whole thing on every turn.

The numbers are not subtle. Industry measurements put agentic workloads at roughly 50x the token consumption of a comparable chat interaction. On a simple five-step loop, one analysis found the agent path costs about 3.2x more than a direct call for the same outcome. Push to fifty steps and the multiplier exceeds 30x. At two hundred steps — a not-unusual autonomous debugging or research session — it crosses 100x. The later turns are the expensive ones, because by then the context window is fat with history.

Now overlay the success/failure split. A failure tends to be a short loop: the agent can't find a tool, can't ground an answer, gives up early. Few turns, thin context, small bill. A success is a long loop precisely because it did the work — it gathered evidence, made tool calls, checked itself. The thing that makes an answer good is the thing that makes it expensive.

This is why "the unit price of intelligence is falling" is a misleading comfort. Per-token prices drop every quarter. But the units consumed per outcome are rising faster, because we keep asking agents to do harder, longer, more thorough work. Cheaper tokens, more tokens, bigger bill.

Why a Rising Success Rate Can Shrink Your Margin

Here is the trap that catches finance teams off guard.

Suppose your agent resolves 60% of incoming tasks today, and you ship a round of improvements — better retrieval, a stronger model on the reasoning step, an extra reflection pass — that pushes resolution to 85%. Unambiguously a better product. Users are happier. Churn drops.

Your cost per task just went up.

Two things happened at once. First, the tasks that used to fail fast now succeed slowly: they moved from the cheap short-loop bucket into the expensive long-loop bucket. Second, the improvements themselves — the extra reflection pass, the bigger model — added token cost to every run, including the ones that were already succeeding. You didn't make success cheaper. You manufactured more of your most expensive event and made each instance pricier.

If your revenue per task is fixed — and under per-seat pricing it effectively is — then margin is revenue minus cost, and you just raised cost while holding revenue flat. A genuine product win shows up in the P&L as margin compression. Engineering ships the improvement, celebrates the resolution-rate chart, and the CFO sees gross margin slide a point. Nobody is lying; they are looking at different metrics.

The only way to see this coming is to stop measuring cost per call and start measuring cost per outcome — cost per resolved task, specifically. Cost per call tells you tokens are cheap. Cost per resolved task tells you whether shipping a better agent made you poorer.

The Pricing Mismatch Nobody Signed Up For

The deeper problem is structural, and it predates your agent. SaaS pricing was built on a seat. A seat is a human, a human has bounded throughput, and a flat fee per human worked because the cost to serve one user was roughly the cost to serve the next.

Agents break the bound. An agent does not occupy a seat. It executes work — sometimes thousands of tasks — and its cost scales with how hard the work is, not with how many people are logged in. Under per-seat pricing, two customers paying the identical amount can impose wildly different costs on you. The data here is stark: under flat pricing, power users routinely consume 100 to 1,000 times more resources than light users. That is not untapped upside. On your heaviest accounts, it is a real, recurring loss on every invoice.

And the inversion is exact. Per-seat pricing charges the most when a customer hires the most humans — and humans are what your agent is supposed to replace. The better your product, the fewer seats the customer needs, the less you earn, and the more agent work you run. Success on the customer's side and success on the cost side both push your margin down. You are penalized twice for the outcome you sell.

This is showing up in aggregate. Analysts now estimate that for every $1 million in AI product revenue a software company books, roughly $230,000 leaves as inference cost before anyone in sales, engineering, or marketing is paid. The 80%+ gross margins that defined the cloud era are no longer the default; AI-heavy products are on a glide path toward margins in the 60s and low 70s. Flat-rate pricing on a variable-cost product doesn't just leave money on the table — it converts your best customers into your biggest liabilities.

Instrument the Thing That Actually Varies

You cannot manage what you do not measure, and most teams measure the wrong granularity. A monthly total token bill is useless for this. You need cost attributed to the units that vary.

Two cuts matter most.

Cost per resolved task. Tag every agent run with its outcome — resolved, escalated, abandoned — and its full token spend, including tool-call overhead. Then divide spend by resolved outcomes, not by total runs. This is the number that moves when you ship a reliability improvement, and it is the number that should sit next to the resolution-rate chart in every review. If resolution goes up and cost-per-resolved-task goes up faster, you shipped a margin regression dressed as a feature.

Cost per user cohort. Bucket customers by agent spend and look at the distribution, not the mean. The average hides everything. You are looking for the long tail — the accounts running 100x the median — because under flat pricing those are the accounts losing you money, and you cannot price or cap your way out of a problem you cannot see. A cohort view turns "our costs are up" into "these eleven accounts are 70% of the overage."

One warning, learned expensively by others: a budget alert is not a budget control. Plenty of teams have an alert that fires at $X of spend and a human who sees it an hour later — by which point a runaway loop has already burned the money. There are documented single agent loops that ran up tens of thousands of dollars. Alerts are observability. Enforcement is a separate system, and it has to be able to stop a run, not just notice one.

Product Levers That Keep Good Outcomes from Eating the Margin

Instrumentation tells you the shape of the problem. Fixing it is a product decision, not just an infrastructure one. Four levers, roughly in order of how much they help.

Effort caps. Put a hard ceiling on tokens, turns, or tool calls per run, enforced inside the orchestration loop — not as an alert, as a wall the run hits and stops at. Every serious agent framework supports a max-iterations cap; use it. The cap protects you from the pathological tail: the run that would have spiraled to $47,000. Most legitimate tasks finish well under the ceiling, so a well-set cap costs you almost nothing and removes your worst-case entirely.

Model routing on the easy path. Most incoming tasks are easy. Do not spend your most expensive model on them. Classify tasks into three to five complexity tiers and assign the cheapest model that clears each tier's quality bar, escalating to the strong model only for the genuinely hard cases. Teams doing this report cost reductions near 87%, because the expensive model ends up handling only the ~10% of work that actually needs it. The discipline is monitoring quality per tier so you notice when a tier's default model starts slipping.

Escalation tiers. Not every task should run to completion autonomously. Some should be detected as low-confidence or low-value early and handed off — to a cheaper deterministic path, to a human, or to a "we can't help with this" that the user prefers over a slow expensive wrong answer. Escalating early is the legitimate version of the cheap failure: you stop spending before the long expensive loop begins.

Pricing that tracks cost. The levers above narrow the gap. They do not close it, because the gap is structural. Eventually pricing has to acknowledge that cost scales with work. The market is already moving — hybrid pricing, a platform fee plus a consumption component that scales with agent activity, is projected to be the majority model among software companies by the end of 2026. Outcome-based pricing goes further: charge per qualified lead, per resolved case, per recovered sale. That model has a property the others lack — when the agent wanders and burns tokens without delivering, the cost lands on you, which is exactly the incentive that forces you to fix it.

The Mindset Shift

The single most useful thing you can do is stop treating tokens as an infrastructure line item and start treating cost-per-outcome as a product metric — one that sits in the same review as resolution rate, latency, and retention.

When those numbers live in different rooms, engineering ships "wins" that quietly cost money and nobody connects the two until the quarterly margin review. When they live in the same room, a proposal to add a reflection pass gets evaluated on what it does to cost per resolved task, not just accuracy. That is the whole game.

Your agent costs more when it succeeds. That is not a bug to be optimized away — it is the physics of the thing you built. The job is not to make success cheap. It is to make sure that every time your agent wins, you win too.