The AI-App SLA: A Four-Layer Framework for Agency Support Tiers (2026)

Quick Answer

An AI-app SLA is the service-level agreement an agency hands a client after shipping an application built on an AI app builder. As of 2026, the classic uptime-plus-response-time template is no longer enough, because an AI app also leans on third-party model APIs, token budgets, and model versions that get deprecated on someone else's schedule. This framework splits the agreement into four layers (availability, response and resolution, AI behavior, and change and continuity) and maps them to a three-tier support ladder (Essential, Managed, Partner). The point is simple: price recurring work against named risks, not against a gut feeling.

Most agency retainers still describe an app as if it were a static WordPress site with a database. AI builds broke that model quietly. The moment your build calls a hosted model, streams tokens, or ships an agent, you have inherited a dependency you do not control and a failure mode your old SLA never named. This is the framework we use to write agreements that survive contact with a real production incident.

Why the old SLA template quietly broke

A traditional software SLA answers three questions: is it up, how fast do you respond, and how fast do you restore. Those questions still matter. They are just no longer sufficient.

Consider a single client app that summarizes support tickets with a hosted language model. Nothing in the codebase changed overnight, yet on Tuesday the summaries came back truncated. The cause was upstream: the model provider rotated a default version and the new one returned a different token limit. Your uptime monitor stayed green the entire time. Your response-time clause never triggered, because the site was technically up. The client, reasonably, still felt the product was broken.

That gap is the whole problem. An AI feature can degrade without the app going down, without any code shipping, and without a single alert firing. If your SLA only measures availability, you have written an agreement that cannot see the most common way modern builds fail.

The four-layer AI-app SLA

Treat the agreement as four stacked layers. Each layer names a distinct failure surface, and each maps to a measurable commitment. The novelty is layer three; the other three are the mature service-management basics adapted to AI builds. For the classic layers, a solid public reference on how to structure availability and severity commitments is the Atlassian ITSM guide to SLAs (2026).

A word on layer one. Because the app depends on the builder's hosting and on third-party model APIs, your real availability is the product of dependencies you partly do not own. Write the clause as shared-dependency uptime and exclude documented upstream provider outages, the same way infrastructure vendors exclude force majeure. Promising 99.9% on a stack whose model provider only offers 99.5% is a clause you cannot honor.

Layer three, the part worth getting right

The AI-behavior layer is where agencies either look like professionals or get blindsided. Break it into four named commitments.

Model deprecation. Hosted model versions retire on a published cadence. Your SLA should state that you monitor the provider's deprecation notices and that, once a notice affects a client feature, you migrate within the tier's window. Without this clause, a provider's routine version sunset becomes an emergency the client blames on you.

Output-quality regression. Define what "the AI feature is broken" actually means before you are arguing about it at 11pm. Split it in two. Structural regression, where the output stops matching the expected schema or format, is objective and belongs at P2. Subjective quality, where answers feel worse, is real but must be tied to a reproducible evaluation set, not to vibes. Ship every AI feature with a small saved eval so "worse" has a number attached.

Latency and cost drift. Token cost and latency are variable inputs, not fixed ones. Set a monthly token-budget threshold with an alert, and state in writing who absorbs overage when usage spikes. An agency that eats unbounded token cost on a fixed retainer is running an uninsured position.

Safety and abuse. Name who handles prompt-injection reports, moderation gaps, and abusive inputs, and at what severity. For most business apps this is a P2 with a defined containment step, not a silent gap.

The three support tiers

Layers describe what you promise. Tiers describe how much of it the client is paying for. Map the four layers onto a three-step ladder and attach each tier to a retainer band. This keeps pricing honest, because the client is buying a named response window, not a vague sense of being looked after.

The ladder does double duty. It gives the client a clear upgrade path when their app matures, and it gives you a defensible reason to charge more than a flat "maintenance" line item. This is the same logic behind a productized maintenance retainer, applied to service levels instead of scope.

A worked example

A boutique agency ships a client-facing quoting tool with an AI drafting feature. They put it on the Managed tier at a monthly retainer. Two months in, the model provider announces a version deprecation. Because the SLA named a 10-business-day migration window, the agency schedules the swap calmly, runs the saved eval to confirm the drafts still match the required format, and sends a one-line change note. No fire drill, no awkward invoice, no eroded trust.

Six months later the client's volume triples and token cost drifts past the alert threshold. The overage clause already said the client covers usage above the named budget, so the conversation is a routine tier upgrade to Partner, not a dispute. The SLA did what a good SLA does: it turned two predictable surprises into scheduled, priced work.

How the build platform shapes your continuity clause

Layer four depends heavily on what your build platform actually hands you. If you cannot deliver the source, your continuity clause is fiction. Builders differ sharply here as of 2026, so evaluate this before you sign an SLA, not after.

The practical rule: a platform that gives you the full source, like an AI app builder that hands over a downloadable Next.js project, lets you write a genuine exit runbook in layer four. A platform that keeps you inside its runtime forces a weaker continuity clause, which you must disclose to the client rather than paper over. This is the same ownership question that drives how you write change orders on fixed-price AI builds.

The action checklist

• Rewrite layer one as shared-dependency uptime and exclude documented upstream provider outages.
• Add the four layer-three clauses: deprecation notice window, structural-regression severity, token-budget threshold, and abuse handling.
• Ship every AI feature with a small saved eval so "the quality dropped" has a number.
• Put an overage clause in writing so token spikes are a tier conversation, not a dispute.
• Match each client to a tier, and review the match quarterly as their app matures.
• Confirm your build platform can actually deliver source before you promise a continuity clause.

If you take one thing from this: an AI-app SLA is not an uptime promise with an AI paragraph bolted on. It is a four-layer risk map, and the layer that pays for itself is the one that names how the AI feature can quietly stop doing its job.