Your AI Agent Has a 95% Success Rate. Your Workflow Has a 36% Success Rate. Here's the SRE Fix. number published this week has been sitting with me since I read it.At 95% per-step accuracy — which is optimistic for current LLMs — a 10-step agent workflow succeeds roughly 60% of the time. At 20 steps, you're at 36%.That math comes from Lusser's Law, which reliability engineers have known since the 1950s. The reliability of a series of components equals the product of their individual reliabilities. We apply it to hardware systems, distributed architectures, deployment pipelines. We have not been applying it to AI agent workflows — and the industry is starting to feel the consequences.Microsoft's Azure SRE Agent team found that problems requiring more than four handoffs almost always failed. That's not a benchmark result. That's a production observation from the team that built one of the most sophisticated AI SRE systems in existence.Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 because of costs, unclear value, or inadequate risk controls.The inadequate risk controls part is what I want to address. Because the risk is calculable. And if the risk is calculable, it can be governed.Why the Demo Number LiesDemos usually hide compounding failure because they only show two or three steps. Production environments are usually five or more steps over messy inputs and edge cases.A demo that shows an agent complete a task in three steps with clean data is showing you 0.95^3 = 0.857 — 85.7% reliability. That looks good. Your stakeholders are impressed.The same agent deployed to a production incident investigation workflow with 10 steps is giving you 0.95^10 = 0.599 — just under 60% reliability. In SRE terms: your agent is failing roughly four out of ten production incident investigations, silently, without throwing an error.This mathematical reality makes autonomous multi-step workflows fundamentally challenging at production scale, requiring teams to rethink how they architect agent systems.Rethinking the architecture is exactly right. But it's not enough to know the math. You need a framework for governing the math — which is what SRE discipline gives you.The Missing SLO LayerWe have SLOs for services. We have error budgets for APIs. We have reliability targets for databases.We have almost none of that for agent workflows.A microservice either returns a 200 or it doesn't. AI agents return responses on a spectrum from correct to confidently wrong. Everyone's shipping agents. Almost nobody has a framework for deciding how much failure is acceptable.That's the gap. And it's the same gap SRE filled for microservices fifteen years ago.The answer isn't "make every step more reliable." At scale that's impossible — you can't prompt-engineer your way to 99.9% per-step accuracy across a complex incident investigation workflow. The answer is what SRE has always done: define an acceptable failure rate, measure against it, and design the system to fail gracefully when it breaches.Introducing the Workflow Reliability BudgetA Workflow Reliability Budget (WRB) applies error budget thinking to multi-step agent workflows rather than to individual services.The calculation:WRB = R_target / R_actual
where R_actual = (P_step)^n (Lusser's Law for the full workflow)
and R_target = your acceptable success rate for this workflow classFor an incident investigation workflow with 8 steps and 95% per-step accuracy:pythonfrom agentsre.slo_burn import AgentSLOBurnTracker, SLOTarget
import math
def calculate_workflow_reliability(
per_step_accuracy: float,
num_steps: int
) -> float:
"""
Apply Lusser's Law to calculate end-to-end workflow reliability.
This is the number your demo hides and your production exposes.
"""
return per_step_accuracy ** num_steps
The math your stakeholders need to see
per_step = 0.95
steps = 8
workflow_reliability = calculate_workflow_reliability(per_step, steps)
print(f"Per-step accuracy: {per_step:.0%}")
print(f"Workflow steps: {steps}")
print(f"End-to-end reliability: {workflow_reliability:.1%}")
Output: End-to-end reliability: 66.3%
Now wire this to your SLO framework
tracker = AgentSLOBurnTracker(
agent_id="incident-investigation-agent-v2",
task_class="multi-step-incident-investigation"
)
Workflow-level SLO — not per-step accuracy
tracker.add_slo(SLOTarget(
metric_name="WorkflowCompletionRate",
target_pct=90.0, # 90% end-to-end success
window_days=30,
good_threshold=1.0, # 1.0 = workflow completed successfully
higher_is_better=True
))
DQR at workflow level — not just per tool call
tracker.add_slo(SLOTarget(
metric_name="WorkflowDQR",
target_pct=85.0, # 85% of completed workflows with correct output
window_days=30,
good_threshold=0.8,
higher_is_better=True
))The key insight: WorkflowCompletionRate is not the same as per-step accuracy. A workflow that completed but produced a wrong final answer counts as a failure against DQR even if every intermediate step appeared to succeed. That's the distinction most teams miss.The Three Architecture FixesThe math points to three specific changes that actually move the reliability number:Fix 1: Shorten the chainAchieving high workflow reliability requires either very high per-step accuracy (above 99%), short workflows (fewer steps), or resilience architecture that detects and corrects errors before they compound.Every step you remove from an agent workflow is a multiplicative reliability improvement. An 8-step workflow at 95% per-step accuracy is 66% reliable. A 5-step workflow at the same per-step accuracy is 77% reliable. That's an 11-point improvement from design alone, not from model improvement.In practice: ruthlessly question every step in your agent workflow. If a step retrieves context the agent has already retrieved in a previous step, remove it. If a step validates something that was already validated, combine them. Shorter chains are not lazy design — they are reliability engineering.Fix 2: Add intermediate checkpointsError budgets force you to confront this compounding math instead of pretending each step is independent.The error doesn't compound uniformly — it compounds through dependency. An incorrect output at step 2 feeds into step 3, which builds on wrong context, which makes step 4 worse. By step 6, the agent is reasoning on top of accumulated wrongness.Intermediate checkpoints break this chain. After every two or three steps, the workflow validates intermediate output before continuing. Not a human checkpoint — a programmatic DQR check on the intermediate result.pythonfrom agentsre.reasoning_trace import AgentDecisionTrace
from agentsre.eval_pipeline import EvalRun, EvalCase
def checkpoint_intermediate_output(
agent_id: str,
step_number: int,
intermediate_output: str,
expected_properties: list,
trace: AgentDecisionTrace
) -> bool:
"""
Validate intermediate output before the next step consumes it.
If this checkpoint fails, the workflow stops and replans
rather than compounding the error through subsequent steps.
Returns True if output passes validation. False triggers replan.
"""
# Check each required property of the intermediate output
failed_properties = []
for prop in expected_properties:
validator_fn = prop.get('validator')
if validator_fn and not validator_fn(intermediate_output):
failed_properties.append(prop.get('name'))
if failed_properties:
# This is a replan event — RTD increments
trace.record_replan(
reason=(
f"Step {step_number} intermediate output failed "
f"properties: {failed_properties}. "
"Replanning rather than compounding."
),
tool_that_failed=f"step_{step_number}_output",
new_plan=f"Retry step {step_number} with corrected inputs"
)
return False
return TrueFix 3: RTD as your workflow health signalRTD (Reasoning Trace Depth) already tells you when compounding is happening. When an agent re-plans three times in a 10-step workflow, it's because earlier steps produced outputs the agent couldn't work with cleanly. RTD rising is your leading indicator of compounding failure before the final output reveals it.The signal chain for workflow reliability:RTD rising → intermediate outputs degrading → DQR declining
↑ ↑ ↑
earliest signal mid-workflow signal lagging signalIf you're watching only DQR at the workflow level, you're watching the lagging signal. Wire RTD monitoring to your intermediate checkpoint layer and you catch compounding before it propagates through the full chain.The Workflow Reliability Dashboard Query# CloudWatch Insights — workflow reliability trend
fields @timestamp, agent_id, reasoning.rtd, outcome.task_completed,
quality.confidence_proxy, outcome.latency_ms
| filter trace_type = 'agent_decision_trace'
| filter agent_id = 'incident-investigation-agent-v2'
| stats
avg(reasoning.rtd) as avg_rtd,
sum(outcome.task_completed) / count() * 100 as completion_rate_pct,
avg(quality.confidence_proxy) as avg_confidence
by bin(1d)
| sort @timestamp ascIf completion_rate_pct is tracking below your WRB target, look at avg_rtd in the same window. Rising RTD before declining completion rate means compounding is starting — you have a window to intervene before the workflow-level SLO breaches.What This Means for Your Agent DesignThe teams that ship design short, checkpointed chains. The teams that stall keep adding steps and hoping.Lusser's Law isn't telling you agents can't work. It's telling you the design constraints for making them work reliably at scale. Fewer steps. Checkpoints between steps. RTD monitoring to catch compounding early. Workflow-level SLOs rather than per-step accuracy benchmarks.The math is the same math reliability engineers have been applying to hardware and distributed systems for decades. The discipline already exists. The application to AI agent workflows is new — but the principles are not.All frameworks referenced in this post are in the agentsre library at github.com/Ajay150313/agentsre. MIT licensed.Ajay Devineni | AWS Community Builder | Senior SRE/Platform EngineerDEV.to Tags:
Top comments (0)