Reliability SLAs: What GaaS Vendors Are Actually Promising (and What They're Quietly Not)

Table of Contents

• The Sleight of Hand at the Center of Most GaaS SLAs
• What "Availability" Actually Means for an Agent
• The Three Tiers of Reliability Promises
• Outcome SLAs: The Holy Grail Almost Nobody Signs
• Why Vendors Resist Hard Accuracy Guarantees
• The Remedies Problem: Service Credits Don't Cover Your Loss
• How to Read a GaaS SLA Like a Buyer Who's Been Burned
• Where SLAs Are Heading
• Insights Most People Overlook
• References

The Sleight of Hand at the Center of Most GaaS SLAs

Here's a test. Pull up the SLA of any Agentic AI-as-a-Service vendor you're evaluating and search the document for the word "correct." Then search for "accurate." Then "success."

In most contracts I've seen, you'll come up empty. What you'll find instead is "available," "uptime," and "response time." That gap is the whole story.

The standard GaaS reliability SLA was copy-pasted from the SaaS playbook, where "99.9% uptime" is a meaningful promise because the software either works or it doesn't. A CRM that's up does what a CRM does. But an agent that's "up" can still confidently misclassify a support ticket, hallucinate a refund policy, or call the wrong API with perfectly valid syntax. The service responded. The outcome was wrong. And under the typical SLA, the vendor owes you nothing.

This is the sleight of hand. Vendors put a reassuring number on the homepage, the "reliability number," as we discuss elsewhere in this cluster, and that number measures the one thing that's easy to guarantee and almost beside the point.

What "Availability" Actually Means for an Agent

Traditional availability is binary and well-defined: did the system accept the request and return a response within the latency budget? For an LLM-backed agent, even this narrow definition gets slippery, because "the system" is a chain.

A single agent task might route through your vendor's orchestration layer, a foundation-model provider (OpenAI, Anthropic, Google), a vector database, three or four external tool APIs, and a retry mechanism. The vendor controls maybe a third of that chain. When OpenAI has an incident, and they publish these on their status page regularly, your agent degrades, but it's often excluded from the SLA as a third-party dependency.

So the first thing to understand: the "99.9%" in a GaaS SLA usually refers to the vendor's own orchestration endpoint accepting requests. It frequently carves out:

• Model-provider outages and rate limits (the agent's brain going dark)
• Third-party tool/API failures (the agent's hands going dark)
• "Degraded performance" that falls short of a hard outage but makes the agent useless
• Scheduled maintenance windows

Each carve-out is defensible in isolation. Stacked together, they mean the headline number describes a sliver of what determines whether the agent actually works for you. We cover the operational side of this in our piece on monitoring agents across model-provider outages, but the contractual point stands: availability of the endpoint is not availability of the capability.

The Three Tiers of Reliability Promises

It helps to think about GaaS reliability promises as three distinct tiers, ordered from "easy to promise, low value" to "hard to promise, high value."

Tier 1, Infrastructure availability. The endpoint responds. This is what nearly every vendor offers and what the homepage number refers to. It's table stakes and tells you almost nothing about agent quality.

Tier 2, Performance and latency. Responses come back within a defined p95 or p99 latency, throughput holds under load, and the system scales. More meaningful, because a slow agent in a live workflow is often a broken agent. The latency-reliability tradeoff is real, and good vendors will commit to latency percentiles, not averages, averages hide the tail failures that actually hurt.

Tier 3, Outcome quality. The agent produces correct, useful results at a defined rate. This is the tier buyers actually care about and the tier vendors fight hardest to keep out of the contract. When a vendor will put a number here, measured task success rate, bounded hallucination rate, defined accuracy on a golden dataset, you've found a serious operator.

Most GaaS contracts in 2026 live entirely in Tiers 1 and 2. The competitive frontier, and the reason reliability is becoming the real moat in this market, is whether a vendor will step into Tier 3 in writing.

Outcome SLAs: The Holy Grail Almost Nobody Signs

An outcome SLA promises something about whether the agent did the job, not just whether it ran. These exist, but they're rare, narrow, and usually reserved for mature vertical agents where the task is bounded enough to measure.

The cleanest examples come from per-outcome pricing models, where the economics force the issue. If a vendor charges you per successfully resolved support ticket or per correctly extracted invoice, they've implicitly taken on outcome risk, they don't get paid for failures. That pricing structure is a stronger reliability signal than any SLA clause, because the vendor's revenue is now correlated with the thing you care about. This is one reason per-outcome pricing is spreading across the GaaS market: it aligns incentives in a way per-seat pricing never could.

But notice what makes outcome SLAs possible: a clear, measurable definition of "success." For invoice extraction, success is checkable against ground truth. For a customer-success agent meant to "improve retention," success is a fog. The narrower and more verifiable the task, the more likely you'll get a real outcome guarantee. The fuzzier the task, the more you'll be handed a Tier 1 uptime number and a smile.

A useful framing from the broader software-reliability world applies here. Google's Site Reliability Engineering practice distinguishes SLIs (the thing you measure), SLOs (your internal target), and SLAs (the contractual promise with consequences). Most GaaS vendors have only fuzzy SLIs for outcome quality, no published SLOs, and certainly no SLA. The maturity ladder runs in that order, you can't credibly sign an outcome SLA until you can reliably measure the outcome, which is why eval infrastructure is upstream of everything in this conversation.

Why Vendors Resist Hard Accuracy Guarantees

It's worth being fair to vendors here, because their reluctance isn't pure cynicism.

First, the model underneath changes without their permission. When a foundation provider ships a new model version or deprecates an old one, agent behavior can shift overnight, the regression-testing problem that haunts every agent team. Guaranteeing a fixed accuracy rate while standing on shifting ground is genuinely hard.

Second, reproducibility is imperfect. The same prompt can yield different outcomes across runs. If a vendor guarantees 95% task success and an unlucky customer sees 91% on a small sample, who's right? Statistical guarantees need volume and agreed measurement, and most contracts don't specify either.

Third, the input distribution is the customer's. An agent that hits 96% on the vendor's test set may hit 80% on your messier real-world data, because public and internal benchmarks systematically overstate field reliability. Vendors know their numbers don't transfer cleanly, so they're wary of promising a number that depends on data they don't control.

These are real constraints. But they argue for better measurement and shared definitions, not for retreating to a meaningless uptime figure. The vendors who'll win the enterprise are the ones treating these as engineering problems to solve, not as excuses to avoid commitment. As a16z has argued about the shift to outcome-based AI businesses, the companies willing to put their margin behind results are the ones that earn durable trust.

The Remedies Problem: Service Credits Don't Cover Your Loss

Even when a GaaS SLA does promise something concrete, look hard at the remedy, what you actually get when the vendor breaches.

In nearly every case, the answer is service credits: a partial refund of your subscription or usage fees for the affected period. If the agent's failure cost you a misfiled regulatory document, an angry enterprise customer, or a five-figure erroneous transaction, your remedy is a few hundred dollars off next month's bill. The mismatch is enormous.

This is the part of GaaS economics buyers underweight. The downside of an agent failure is frequently borne entirely by the customer, while the vendor's exposure is capped at a sliver of fees. For low-stakes tasks that's acceptable. For anything where a wrong outcome carries real liability, finance, healthcare, legal, compliance, you need to think about this asymmetry before you sign, not after an incident. The cost of a false positive versus a false negative varies wildly by vertical, and your SLA should reflect which one will actually hurt you.

A few questions worth raising in negotiation:

• Are there liability caps, and how do they compare to the realistic cost of a bad outcome?
• Does the vendor carry insurance or indemnification for agent errors in your domain?
• Is there a path to escalate or require human review for high-stakes actions, contractually, not just as a feature?

If a vendor won't discuss anything beyond service credits, that itself is information about how much confidence they have in the agent.

How to Read a GaaS SLA Like a Buyer Who's Been Burned

Strip away the marketing and a GaaS SLA comes down to a handful of questions. Run every contract through these:

1. What exactly is being measured? Endpoint availability, latency, or actual task outcomes? If it's not outcomes, treat the reliability claim as Tier 1 and adjust expectations.
2. How is "success" defined, and who measures it? Is there a golden dataset, an agreed eval methodology, a shared dashboard? Or is "reliable" undefined and therefore unenforceable?
3. What's carved out? Model-provider outages, third-party APIs, "degraded" states. The exclusions tell you more than the headline number.
4. What's the remedy, and is it proportional to your risk? Service credits or something real?
5. Can you see the underlying telemetry? Enterprise buyers increasingly demand observability data, traces, success rates, failure breakdowns, before signing. If the vendor can't show you the numbers behind their promise, the promise is decoration.
6. What happens when the model changes? Is there a notification window, a regression-testing commitment, a rollback path?

The single highest-signal move: ask the vendor to show you their own internal reliability dashboard for an agent like yours. Vendors who measure outcomes rigorously will be proud to share it. Vendors selling a Tier 1 number dressed up as a quality guarantee will suddenly get vague. That vagueness is your answer.

Where SLAs Are Heading

The market is moving, slowly, from availability SLAs toward outcome SLAs, pushed by enterprise buyers who've been burned by the gap and by vendors who've realized that a credible outcome guarantee is a powerful differentiator in a crowded field.

Expect three developments over the next couple of years. Standardized outcome metrics, so "task success rate" means something comparable across vendors rather than each defining it to flatter themselves. Tiered SLAs by stakes, where vendors offer stronger guarantees (and higher prices) for high-consequence workflows and lighter ones for low-stakes automation. And continuous, shared measurement, where reliability isn't a number checked at procurement but a live SLO tracked in production with both sides looking at the same dashboard.

The vendors who get there first will own the enterprise segment, because in agentic AI, reliability, not raw capability, is what closes deals and keeps them closed. A more capable agent you can't trust loses to a slightly less capable one you can. The SLA is where that trust gets written down, and right now most of them aren't worth the PDF they're rendered in.

Insights Most People Overlook

1. Per-outcome pricing is a stronger reliability signal than any SLA clause. A vendor who only gets paid when the agent succeeds has bet their margin on reliability. That alignment outweighs paragraphs of contractual language, because incentives are harder to fake than promises. When evaluating vendors, weigh the pricing model as heavily as the SLA document.

2. The most dangerous failures are the ones SLAs can't see. Uptime SLAs catch hard outages. They completely miss "silent failures", the agent that runs, returns a confident answer, and is quietly wrong. These are far more common and far more damaging in production than outages, and almost no SLA addresses them. Your real risk lives in the gap between "the agent ran" and "the agent was right."

3. SLA exclusions for model-provider outages quietly transfer the foundation-model risk to you. When a vendor carves out OpenAI or Anthropic downtime, they've handed you the risk of a dependency you didn't choose and can't control. In a multi-vendor agent chain, these exclusions compound, each link disclaims the others, and the customer is left holding aggregate risk no single party owns.

4. A meaningful outcome SLA is a tell that the vendor has serious eval infrastructure. You can't credibly guarantee a task success rate you can't measure. So when a vendor offers a real Tier 3 promise, it's indirect proof they've built golden datasets, continuous evals, and observability, the unglamorous machinery that actually produces reliability. The SLA is downstream of the eval suite, which is why it's a useful proxy for engineering maturity you otherwise can't inspect.

5. Ask for the remedy math before the reliability number. Buyers fixate on whether it's 99.9% or 99.95%. The more revealing question is what happens on breach. A vendor confident in their agent will discuss proportional remedies and indemnification; one selling a fragile system retreats to service credits. The remedy section reveals the vendor's true confidence more honestly than the guarantee itself.

References

• Google SRE Book, Service Level Objectives
• OpenAI Status Page
• a16z, The Economic Case for Generative AI and Foundation Models