Defining SLAs for Agent-Powered SaaS Products

A support agent tells a customer their refund is processed. The refund never happened. The agent picked the wrong tool call, moved on, and nothing in the SLA caught it, because nothing in the SLA was built to catch it.

Why uptime guarantees fail when the software acts autonomously

Traditional SaaS SLAs answer one question: is the server responding. If the API returns 200, the service counts as functional. That logic held up fine for years of deterministic software, where a responsive server meant the code behind it was doing its job. Agentic products break that link.

A platform can be fully available while the agent inside it actively fails the customer. The agent can be online, the API can return 200, and the agent can still choose the wrong tool, invent a detail that was never in the source data, or take 90 seconds to finish a task that should feel instant. None of those failures appear on an uptime dashboard. The server ran the agent, which is what it was asked to do. Whether the agent did the right thing is a separate question, and it's one that infrastructure monitoring was never built to answer.

Treating uptime as a stand-in for agent correctness is a category error. Uptime measures whether the pipes are open. It says nothing about whether what flows through them is correct, complete, or fast enough to matter. Any SLA framework built only on availability is, by construction, blind to the failures that actually cost agent-powered products their customers.

Contracting model for AI agents shifting away from SaaS norms

The legal and commercial paperwork behind these products is already catching up to that gap. Standard SaaS contracts put the responsibility for outcomes on the customer: the vendor supplies a platform, and how it gets used is the customer's problem. That split worked when the product was a co-pilot, a suggestion engine sitting next to a human who made the final call.

Mayer Brown's analysis lays out why that split stops working once the software starts acting on its own: as agentic AI takes autonomous action on a company's behalf, the vendor's role shifts from licensing a tool to delivering a service, and the contract has to reflect that shift. The result borrows from business process outsourcing, combining explicit service definitions, delegation-of-authority clauses spelling out what the agent can and can't do on its own, policy guardrails, mandatory escalation triggers for human approval, and outcome-based SLAs.

The old warranty language, "provided as-is, with all faults," doesn't hold up once the agent is the one sending emails, drafting contracts, updating CRMs, or placing orders. Faults in a static tool are annoyances. Faults in an autonomous actor are liabilities, and buyers are already negotiating contracts that treat them that way. The lack of accuracy and completion guarantees isn't a future contracting problem: buyers are already writing it into deal terms right now.

The three dimensions traditional SLAs omit: task accuracy, completion rate, and recovery behavior

An agent SLA has to commit to three things infrastructure SLAs are structurally incapable of promising: whether the task got done correctly, whether it got done at all, and what happened when it didn't.

Task accuracy measures outcome, not confidence. The unit here isn't a model's internal confidence score or an embedding similarity number, it's whether the task was done right from the customer's seat. A support agent answered the question correctly or it didn't. A bookkeeping agent categorized the transaction correctly or it didn't. A research agent cited the right source or it didn't. Accuracy definitions should shift by task type: structured workflows get checked through state-machine validation and tool-call auditing, knowledge answers get checked against approved sources through retrieval audit, judgment calls need human review sampling. If a team can't measure agent accuracy consistently, that team has no business putting a specific accuracy number into a contract. The SLA should only carry promises the team can actually defend with real measurement.

Completion rate captures something accuracy can't: whether the agent finished the job, independent of whether it got the answer right. A workflow agent that says "I can't finish this now, but I saved the inputs and queued it for review" hasn't delivered full availability, but it hasn't gone dark either. The SLA needs language for that middle state, distinguishing hard failure from graceful degradation. Scoping completion by task class does more work than one blended number: chat availability, tool availability, workflow availability, and degraded availability each describe a different failure surface. Downstream dependencies need explicit treatment: excluding every downstream failure makes the SLA meaningless, and including every downstream failure makes it impossible to sign. The fix is naming, in writing, which dependencies are covered, which are excluded, and what the customer experiences during a partial outage.

Recovery is the commitment most SLAs omit entirely, even though it is the moment that most shapes customer trust. Recovery commitments need to specify whether state gets preserved before a retry or handoff, what triggers escalation and who receives it, and what the customer gets told and when. BPO contracts already define the exact threshold where an outsourced process has to stop and get human sign-off. Translate that into SLA language and a mandatory escalation clause becomes a recovery commitment in its own right, not just a compliance checkbox.

Building SLIs and SLOs before writing a customer-facing SLA

The SLA should be the last document a team writes, coming after the numbers have survived contact with real production data. Writing it first means guessing at numbers. Writing it last means the numbers already survived contact with real production data.

Google's SRE book lays out the hierarchy cleanly: a Service Level Indicator is what gets measured, a Service Level Objective is the internal target set against that measurement, and a Service Level Agreement is the external promise built on an SLO the team can actually stand behind. Applied to infrastructure, that's a familiar pattern. Applied to agents, the same pattern holds, but with more axes to track, because agent reliability isn't a single number the way server uptime is.

The core SLIs for an agent product are task success rate, tool-call error rate, end-to-end latency broken out per task class, cost per successful task, guardrail hit rate, and escalation rate. Each one only earns a spot in a customer-facing SLA once the team has measured it consistently enough to trust it. Error budgets turn those SLOs into operating decisions rather than static targets sitting in a doc no one reads. When the budget for task failures burns down faster than the plan allows, the team pauses autonomy or freezes releases until the numbers recover. That turns the SLA from a legal artifact reviewed once a year into a live signal reviewed weekly.

There's an honest admission every team has to make before publishing any of this: if task accuracy gets checked through manual review sampling, the SLA's granularity is limited by how often that review happens. A weekly review cadence can't support a claim of real-time accuracy guarantees. The fix isn't to fake more precision, it's to put the review frequency itself into the SLA, next to the accuracy number, not instead of it.

How per-user agent isolation changes recovery and accuracy commitments

None of the commitments above mean anything if the underlying architecture can't support them at the level of an individual customer. Whether a provider can keep accuracy and recovery promises at scale comes down to whether each customer's agent runs in its own isolated environment. Shared environments make per-customer SLA enforcement structurally impossible, full stop, because a failure in one customer's session can bleed into another's.

In a shared agent environment, one customer's runaway task, corrupted memory, or failed tool call can degrade or contaminate a completely different customer's session. Recovery and accuracy commitments can't be made per customer if failures can't be traced per customer. Per-user sandboxing solves that: each sandbox isolated per agent or per user, persisting state across turns so the agent keeps context across multiple interactions. They're load-bearing mechanisms that make SLA measurement possible at the level of a single customer instead of an aggregate average across everyone.

A handful of production-grade sandbox requirements map onto specific SLA commitments almost one-to-one: multi-tenant isolation supports per-customer accuracy tracing, pause and resume with snapshotting supports recovery behavior commitments, leader election supports uptime commitments, and event and metrics logging supports SLI measurement. Skipping any one of those makes the corresponding SLA commitment unenforceable, whatever the contract says.

A security dimension sits in shared or under-isolated environments, where an attacker can publish a malicious tool that carries hidden instructions, instructions that execute the moment an agent invokes that tool. Without sandboxing, that tool inherits whatever permissions the agent process holds, which can mean broad read and write access to the filesystem and network access into internal systems. A security incident like that breaks the SLA before accuracy measurement even gets a chance to run.

For compliance-sensitive deployments, the architecture choice carries governance weight too. Message-driven harnesses running on infrastructure the provider controls, under the provider's own data policies, support a different class of SLA than cloud agents that ship code off to a vendor's virtual machines. Compliance requirements deserve as much weight in that architecture decision as feature checklists do.

How tool-call reliability and integration coverage become SLA variables

For most agent tasks, the binding constraint on completion is the integrations the agent depends on to get anything done.

Take an agent running a sales workflow: reading CRM data, drafting a follow-up email. That's a minimum of two external dependencies. If either one fails quietly, the task looks complete from the agent's point of view and fails completely from the customer's. Completion rate has to account for tool-call outcomes directly, alongside whether the agent's own execution loop finished running.

The integration failures agents run into in production aren't exotic. Authentication failures, OAuth tokens expiring mid-task, rate limiting from the downstream API, error responses worded ambiguously enough that the agent reads them as success. These occur constantly at production scale, not as rare edge cases. Infrastructure providers have built out dedicated layers for handling exactly this: managing OAuth flows, absorbing rate limits, normalizing error handling, so the agent isn't left guessing whether a silent failure was actually a success.

Tool availability deserves its own line in the SLA, separate from general uptime: can the agent reach the CRM, the billing system, the calendar, the database, the ticketing tool it needs for this specific task. That gets specified per task class, not folded into one blended availability percentage that tells a customer almost nothing about the workflow they actually care about. The covered-versus-excluded dependency decision from earlier applies directly here: name which integrations sit inside the task completion commitment, name which sit outside it, and specify what the agent does when an excluded dependency goes down, whether it queues the task, escalates it, or notifies the customer.

Human-in-the-loop approval belongs at this integration boundary too, and it earns its place on both cost and accuracy grounds. A cheap inference call that triggers an expensive real-world action, sending an email, creating a contract, updating a CRM record, should carry a configurable approval step before it fires in production. That approval step functions as both a recovery mechanism and an accuracy check, catching the failure before it reaches the customer instead of after.

Agent SLA tiers in practice for different customer commitments

All of this gets built into a single contract most usefully as a set of tiers, matching the level of commitment to what the provider's cost and architecture can actually sustain at that level. A flat, one-size SLA either overpromises for enterprise buyers or overbuilds for a self-serve customer who never needed the top tier in the first place.

The tiering logic runs in one direction: higher tiers carry more specific accuracy commitments, shorter recovery windows, more dependencies covered, and more audit evidence handed to the customer. Lower tiers can lean on graceful degradation and queuing when something breaks, while higher tiers commit to defined escalation paths and human-review SLAs.

Each tier, in practice, needs to spell out a short set of things clearly:

• Which task classes are covered, and which are explicitly excluded, at that tier
• How accuracy gets measured, whether that's a sampling rate with a set review cadence at lower tiers or continuous automated validation at higher ones
• The completion rate commitment, with a clear line between degraded and failed
• The recovery time objective, meaning how long before a failed task gets escalated, queued, or handed off with its context intact
• Which integrations are covered, and what the agent does when a covered integration goes down
• What audit and observability access the customer actually gets, down to which logs and decision traces they can see

The delegation-of-authority clause from the contracting shift earlier translates directly into tier language here. Each tier defines what the agent can do on its own and what needs a human to sign off first. Higher-consequence actions, sending external communications, moving money, updating a CRM record that other systems depend on, should require approval at lower tiers and only run fully autonomously at higher tiers, backed by audit trails that prove it.

For teams building white-label agent products on top of someone else's infrastructure, the SLA tier offered to customers can only be as strong as the infrastructure SLA the provider itself receives from the platform underneath it. The managed infrastructure layer sets the outer limit on every commitment stacked on top of it, which makes that infrastructure choice, not the contract language, the real foundation of the SLA.