Refunds and SLAs When an Agent Fails the Task

Table of Contents

• Why Agent Failure Breaks the SaaS SLA Playbook
• Defining "Failure" Before You Can Refund It
• The Refund Mechanics: Credits, Clawbacks, and No-Charge Runs
• Who Pays for the Wasted Inference?
• Writing an Agent SLA That Actually Means Something
• The Dispute Problem: Adjudicating Failure at Scale
• Tiering Refund Generosity by Autonomy and Stakes
• Insights Most People Overlook
• References

Why Agent Failure Breaks the SaaS SLA Playbook

For two decades, the SaaS service-level agreement has been a settled genre. You promise 99.9% uptime, you define a measurement window, you offer a sliding scale of service credits when you miss, and everyone signs. The thing being measured, is the system reachable and responsive, is binary and machine-verifiable. Nobody argues about whether the API returned a 200.

Agentic AI-as-a-Service detonates that tidy arrangement. An agent can be up 100% of the time, respond in 800 milliseconds, and still be wrong. It can file the expense report to the wrong cost center, summarize a contract while silently dropping the indemnification clause, or email a customer a refund policy that your company abandoned in 2023. None of those failures register on an uptime dashboard. The agent did something. It just did the wrong thing, fluently and on time.

This is the gap that every GaaS pricing conversation eventually falls into. The moment you charge per task or per outcome, which most vendors in this cluster now do, as I covered in the broader GaaS pricing taxonomy, you've made an implicit promise about correctness, not just availability. And correctness is messy. It's contextual, sometimes subjective, and frequently only detectable hours or weeks after the run completed. The buyer's mental model is "I paid for a result," so when the result is bad, "the service was technically operational" is not an answer they'll accept.

So the failure clause is no longer boilerplate you copy from your last vendor agreement. It's the load-bearing wall of the whole commercial model.

Defining "Failure" Before You Can Refund It

You cannot refund a failure you haven't defined, and this is where most early GaaS contracts are quietly broken. Vendors write "the agent will complete the task" and assume everyone shares an intuition about completion. They don't.

Useful agent SLAs separate failure into at least three categories, because each demands a different remedy:

Non-completion. The agent gave up, errored out, hit a tool it couldn't use, or looped until it timed out. This is the easiest to detect and the easiest to refund, there's a clear "it didn't finish" signal. Most vendors auto-credit these without argument, because fighting them destroys trust over pennies.

Incorrect completion. The agent returned a confident, complete-looking output that is wrong. This is the expensive category. It includes hallucinated facts, wrong calculations, and actions taken against the wrong record. Detection often requires a human or a downstream system to catch it, sometimes long after billing.

Partial or degraded completion. The agent did 70% of the job, drafted the email but couldn't pull the attachment, reconciled 90 of 100 invoices. Whether this counts as success, failure, or a pro-rated charge is a genuine design decision, and it's involved enough that it deserves its own treatment (the dedicated piece on pricing for partial completion and graceful degradation goes deeper than I can here).

The sharpest GaaS contracts I've seen define success positively and verifiably rather than defining failure negatively. Instead of "we'll refund if it fails," they write "a task is deemed successful when [specific, checkable condition] is met within [time window]." That inversion matters legally and operationally: it puts the burden on a defined success criterion rather than an open-ended argument about what "failure" encompasses. Sierra, Intercom's Fin, and other support-agent vendors lean on exactly this, a resolution is defined, measured, and only billed when the definition is satisfied, an approach worth studying in the per-resolution pricing playbook.

One hard rule from the field: the failure definition has to be observable by both parties from the same data. If only the vendor can see whether the agent succeeded, the buyer will never trust the bill. Shared, auditable logs are not a nice-to-have here, they're the precondition for the refund clause to function at all.

The Refund Mechanics: Credits, Clawbacks, and No-Charge Runs

Once failure is defined, you need a mechanism to make the customer whole. There are three common patterns, and most mature vendors use a blend.

No-charge runs (the meter never starts). The cleanest model: if the agent doesn't meet the success criterion, the task simply isn't billed. No refund, no credit, no invoice line. This is psychologically powerful, it maps perfectly onto the "we only charge when it works" positioning that's become a marketing battleground across GaaS. The catch is operational: you need real-time failure detection to suppress the charge before it's ever rendered, which is hard for the "incorrect completion" category that surfaces late.

Service credits. Borrowed straight from SaaS. The task is billed, and failures accrue credits against future usage. Easy to administer, friendly to your accounting team, and it keeps revenue recognized. The downside is that credits assume an ongoing relationship, they're worthless to a customer who's churning because the agent failed, which is precisely when they're most aggrieved.

Clawbacks and cash refunds. Actual money back. Rare, reserved for high-value outcome-based deals where a single failed task carries real consequence, a missed filing, a botched trade reconciliation. These are the deals where the success-fee model's legal landmines come home to roost, because a refund obligation on a six-figure outcome is a liability that has to be reserved against, not waved away in a support ticket.

A practical structure that's emerging: no-charge runs for cheap, high-volume tasks; service credits for mid-tier; and contractually capped cash refunds for the expensive, low-volume, high-stakes work. Matching the remedy to the task's economics keeps you from refunding $5,000 in cash over a $0.40 summarization job, while still giving enterprise buyers the financial recourse they'll demand before signing.

Who Pays for the Wasted Inference?

Here's the question that doesn't exist in SaaS and quietly wrecks GaaS margins: when an agent fails, it still burned tokens. Often a lot of them, failed runs tend to be the ones that looped, retried, and called every tool twice before giving up. If you refund the customer, you've now paid for compute and collected nothing. The failure case is doubly expensive.

This is why the failure clause and the margin-safe pricing strategy for volatile inference costs are the same conversation wearing two hats. A vendor who promises generous no-charge-on-failure terms without modeling the cost of failed runs is underwriting an unbounded liability. Three defenses are worth building in:

• A retry/escalation budget per task. Cap how much compute a single task can consume before the agent stops and either escalates to a human or declares failure. This bounds the worst-case cost of any individual failure. It also doubles as a quality signal, an agent thrashing through its budget is usually about to fail anyway.
• Failure-aware unit economics. Price the expected cost of a task, including its failure rate and the wasted compute on failures, not the cost of a clean success. If 8% of tasks fail and each failure burns 1.5x a success in tokens, that's baked into your floor. The minimum viable margin every GaaS startup needs has to survive the failure tax, not just the happy path.
• Model routing on retries. When a cheap model fails and you retry on a frontier model, the failure case is where your inference bill spikes hardest. Smart model routing, and knowing when not to escalate a doomed task, is as much a failure-cost control as a margin lever.

The uncomfortable truth: the more generous your refund policy, the more your reliability engineering becomes a direct P&L line. That's not a reason to be stingy. It's a reason to treat agent reliability as a cost center you actively manage, not a quality aspiration you hope for.

Writing an Agent SLA That Actually Means Something

A real agent SLA has moving parts that a copied uptime SLA simply lacks. The elements worth specifying:

A success rate, not just an uptime number. "The agent will successfully complete at least 95% of in-scope tasks, measured monthly." This is the headline metric buyers actually care about, and it's far harder to commit to than 99.9% uptime because it depends on input quality you don't fully control.

Scope boundaries, the "in-scope" qualifier doing heavy lifting. No agent succeeds on garbage input or out-of-distribution tasks. A defensible SLA defines the task distribution it's guaranteeing against and explicitly excludes inputs outside it. This is the single most negotiated clause, and rightly so: it's where vendors offload the risk of the customer's messy data, and where buyers push back hardest.

Time-to-resolution and escalation guarantees. When the agent can't complete a task, how fast does it hand off to a human, and how fast does the human respond? For many buyers, a reliable, fast escalation path matters more than a marginally higher success rate. Tying SLA tiers to autonomy level is a clean way to price this, a fully autonomous agent carries a different guarantee than a supervised one.

Measurement and audit rights. Who computes the success rate? On what data? The buyer needs the right to audit, or the number is just a vendor's word. This is where outcome-based pricing's central question, who defines and audits the outcome, becomes contractual reality.

A note on what not to do: resist the urge to over-promise success rates to win a deal. A 99% guarantee you miss every month generates more credits, more disputes, and more churn than a 92% guarantee you reliably beat. The SLA is a forecast you're putting money behind. Bad forecasting in this market doesn't just cost reputation, it cost real refund dollars, and it feeds the discounting death spiral when you start trading credits to keep an unhappy account.

For the broader legal frame around indemnification and liability caps in autonomous systems, the analyses coming out of firms tracking AI deployment risk, like the Stanford HAI work on AI accountability, are a useful grounding, even if they predate the per-outcome contracting wave.

The Dispute Problem: Adjudicating Failure at Scale

Refund clauses are easy to write and brutal to operate. Imagine an agent running 50,000 tasks a day with a 5% failure rate. That's 2,500 potential refund events daily. You cannot put a human on each one, and you cannot let the customer self-declare failures without inviting abuse.

So adjudication has to be largely automated, which loops back to the definition problem: only a machine-verifiable success criterion scales. If determining whether the agent succeeded requires human judgment, your refund process collapses under volume the moment you have real traffic. This is a strong, under-appreciated argument for choosing agent use cases where success is objectively checkable, did the data reconcile, did the form submit, did the test pass, over use cases where success is a matter of taste.

When human judgment is unavoidable (legal drafting, creative work, nuanced support), the workable patterns are sampling-based SLAs (guarantee a quality bar on an audited sample rather than every task) and dispute windows (the customer has N days to flag a failed task, after which the charge is final). Both trade some fairness for operational sanity. Both should be explicit in the contract, not discovered during the first billing fight.

Salesforce's own framing of its Agentforce per-conversation pricing is instructive here precisely because it sidesteps the hardest version of this problem, it bills per resolved conversation, a definition that's at least closer to machine-verifiable than "was the answer good." The vendors winning on refund policy aren't the ones with the most generous terms. They're the ones who chose a failure definition they can actually adjudicate at scale.

Tiering Refund Generosity by Autonomy and Stakes

Not every task deserves the same refund policy, and treating them uniformly leaves money on the table or exposes you to ruin. The smart move is to tier refund generosity along two axes: stakes (what does a failure cost the customer?) and detectability (how soon and how certainly can failure be caught?).

Low-stakes, instantly-detectable tasks, a data lookup, a classification, should get the most generous terms. No-charge on failure, no questions. The cost of being generous is trivial, and the trust dividend is large. This is where you can afford the "we only charge when it works" promise without flinching.

High-stakes, late-detectable tasks, anything where a failure surfaces weeks later and carries real financial or legal weight, need the opposite: tighter definitions, capped liability, dispute windows, and often a human-in-the-loop checkpoint that changes the risk profile entirely. In regulated industries with audit overhead, the refund clause is inseparable from the compliance regime, and "we'll just refund it" is rarely an acceptable answer to a regulator.

The mistake is applying enterprise-grade refund caution to penny tasks (you'll feel stingy and lose on experience) or applying penny-task generosity to high-stakes work (you'll eventually eat a refund that bankrupts the account's margin). Matching the policy to the task is the whole game.

Insights Most People Overlook

A generous refund policy is a reliability-engineering forcing function, not a giveaway. The vendors with the most generous no-charge-on-failure terms tend to have the best agents, not because generosity causes quality, but because committing real money to the failure case forces you to drive failure rates down. The refund clause is a self-imposed quality tax that aligns the whole org around reliability. Stingy refund policies are often a tell that a vendor doesn't trust its own agent.

The failure you refund is cheaper than the failure you don't detect. A clean, refunded non-completion costs you one task's revenue. An undetected incorrect completion, the agent confidently did the wrong thing and nobody caught it, can cost you the entire account when the customer discovers it downstream. Investment in failure detection often beats investment in failure prevention on pure ROI, because detection caps your blast radius. Most vendors over-index on prevention and under-build detection.

Refund policy is a moat for incumbents with data, and a trap for startups without it. Knowing your true failure rate, and therefore how generous you can safely be, requires historical task data most startups don't have yet. Incumbents can offer aggressive guarantees because they've measured their distribution; a startup matching those terms blind is gambling. This is one more way outcome and reliability guarantees favor incumbents, and a reason early-stage vendors should start conservative and loosen terms as data accumulates, never the reverse.

"No-charge on failure" can perversely incentivize the agent to under-attempt. If your internal routing logic learns that failed tasks aren't billed but consume compute, the cost-optimal behavior is to bail early on anything hard, quietly shrinking the set of tasks the agent will actually attempt. Watch your decline/escalation rate as closely as your failure rate, or your "we only charge when it works" model degrades into "we only attempt what's easy."

Dispute windows are a hidden pricing lever. A 7-day dispute window versus a 90-day one is a material difference in your refund liability and your revenue-recognition timing, yet it's negotiated as an afterthought. Shortening the window tightens your books; lengthening it builds trust with cautious enterprise buyers. It belongs in the pricing conversation, not buried in the legal appendix.

References

• Stanford Institute for Human-Centered AI, Research on AI Accountability and Deployment Risk
• Salesforce Agentforce, Per-Conversation Pricing Model