"What's your uptime guarantee" is a fair question to ask about any production system, and for AI agents it needs a slightly different answer than the one you'd expect from traditional software, because an AI system has more than one thing that can mean "down."
Uptime for an AI system isn't just one number
Traditional software uptime usually means one thing: is the service responding? An AI agent has at least three distinct failure categories worth tracking separately, because they have different causes and different fixes.
- Infrastructure uptime: is the service itself reachable and responding at all? This is the same category traditional uptime monitoring covers.
- Model provider availability: is the underlying model API you depend on responding? If you use a managed model provider, this is outside your direct control and needs its own monitoring and fallback plan.
- Quality degradation: the system is technically up and responding, but its answers have gotten meaningfully worse because of model drift, a stale knowledge base, or a configuration change. This is the category traditional uptime metrics don't capture at all, and it's arguably the more important one for whether the system is actually delivering value.
What a realistic SLA conversation should actually cover
Infrastructure and response-time commitments
This is the most straightforward part and maps closely to standard software SLA practice: a target response time, a target percentage of successful requests, and a defined escalation path when either isn't met.
Provider dependency and fallback behavior
If your system depends on a third-party model provider, ask what happens when that provider has an outage or degraded performance. A well-built system should have a defined fallback (a secondary model, a graceful degraded mode, or at minimum fast, clear detection and alerting), not just silent failure until someone notices.
Quality monitoring, not just infrastructure monitoring
Ask specifically how quality degradation gets detected, not just whether the system is technically responding. We've written about what to actually monitor in production, and confidence drift, cost anomalies, and accuracy against a real baseline all matter here, separate from whether requests are succeeding at the infrastructure level.
What "recovery" actually means for this specific system
For a traditional service, recovery usually means restarting or redeploying. For an AI agent, recovery might also mean rolling back a model version, a prompt change, or a knowledge base update that introduced a quality regression. That's a different kind of rollback from a typical software deployment, and it needs its own defined process.
What's reasonable to expect, and what isn't
A reasonable vendor or internal team should be able to commit to infrastructure uptime and response-time targets with real confidence, since those are largely within their control. They should be honest about provider dependency risk, since that's genuinely outside anyone's direct control except the model provider itself. What's not reasonable is a vague answer to the quality-degradation question. That category is the one most within a well-built system's control (through monitoring, evaluation, and a defined response process), and it most directly affects whether the system is still doing its job well.
How we approach this
We build infrastructure monitoring, provider fallback behavior, and quality-degradation detection as three distinct, explicitly designed parts of any production deployment, each with a defined recovery process. A single uptime number only covers part of what "reliable" actually means for an AI system.