The agent autonomy ratio: one number that shows trust is growing

An agent that needs the same amount of hand-holding in month three as it did in week one is not learning anything, no matter how many tasks it completes. Agent autonomy is supposed to compound: fewer interruptions, fewer clarifying questions, more uptime spent actually working instead of waiting on a human. Most teams running agents in production have no way to see whether that compounding is happening. They track task volume and success rate, and both of those numbers can climb while the agent quietly stays exactly as dependent on a human as it was on day one.

What Anthropic's own data shows

Anthropic's research on measuring agent autonomy in practice gives the clearest public data point on what healthy autonomy growth looks like. Between August and December, the success rate of Claude Code on Anthropic's own internal hardest-task category doubled. Over the same stretch, the average number of human interventions per session fell from 5.4 to 3.3. Those two lines moving together, more success with less intervention, is the definition of an agent earning trust rather than just accumulating usage.

Most teams cannot see this pattern in their own agents because they are not tracking the intervention side at all. A dashboard showing "tasks completed: 1,240 this month" tells you nothing about whether a human had to step in on 1,200 of them.

The autonomy ratio

The fix is one number:

autonomy ratio = (uptime - human wait time) / uptime

Uptime is the total time the agent spent actively working on a task, from trigger to resolution. Human wait time is the portion of that window spent blocked on a human: waiting for an approval, an answer to a clarifying question, or a manual correction after an error. The ratio lands between 0 and 1. An agent that never waits on a human scores 1.0. An agent that spends half its runtime blocked scores 0.5.

The number only matters as a trend. A single snapshot tells you how supervised an agent is today, which is expected to be low for a new deployment. What tells you whether the agent is maturing is whether that ratio is climbing week over week. Anthropic's data shows the shape a healthy trend takes: intervention count falls while the task complexity and success rate the agent is handling goes up, not down. An agent that hits a high autonomy ratio by never being handed harder work is not maturing, it is coasting.

Why success rate alone hides this

Success rate is the metric most teams already track, and it is necessary but not sufficient. An agent can post a 95% success rate while a human silently corrects the other 5% and also nudges half of the "successful" 95% along the way with small interventions that never get logged as failures. Success rate counts outcomes. It says nothing about how much human labor produced that outcome.

This is the same blind spot Galileo's research on human-in-the-loop oversight points to: oversight that happens outside the success/failure boundary is invisible to metrics that only look at final state. A clarifying question, an approval click, a correction mid-run, none of those register as a failure, but all of them are human time spent keeping the agent on track. The autonomy ratio is built specifically to catch that gap, because it measures time, not outcome.

What counts as human wait time

The definition only works if "human wait time" is scoped consistently. Three categories to track separately, because they mean different things:

• Approval waits. The agent proposed an action and is blocked until a human clicks approve. This is the most common form in agent frameworks with a human-in-the-loop gate.
• Clarification waits. The agent stopped itself to ask a question, mirroring the pattern Anthropic found where Claude Code pauses for clarification more often on complex tasks than humans choose to interrupt it.
• Correction time. A human steps in mid-run or post-run to fix something the agent got wrong. This is the most expensive category and the one most worth watching, because a rising correction share means the agent is not just slow, it is wrong.

An agent with a high approval-wait share and near-zero correction time is a trust problem: the process has not caught up to what the agent can actually do unsupervised. An agent with rising correction time regardless of the other two categories is a capability problem, and no amount of loosening the approval gate fixes it.

Instrumenting it without rebuilding your stack

You do not need a new observability platform to compute this. The three inputs, task start time, task end time, and each block-and-resume event with a reason code, are already available in most orchestration layers (n8n's execution log, LangSmith's trace spans, or a custom event log if you built the agent from scratch). The only gap is usually that block-and-resume events are not tagged with a reason, so approval waits, clarification waits, and corrections get logged as one undifferentiated pause.

Tag the pause events, sum the wait time against total uptime per task or per week, and the ratio falls out of data you are already collecting. The alternative, sending a single event at task completion with the outcome and the elapsed time, is the same one-HTTP-call pattern this site tracks: it costs one API call and turns a trace nobody reads into a number a product lead can put in a review deck.

The number to defend in a review

A rising autonomy ratio, paired with a stable or rising success rate on harder tasks, is the case for expanding an agent's scope. A flat or falling ratio, even with a fine success rate, is the case for holding the line: the agent is succeeding because a human is still doing part of the work, and expanding scope on top of that just moves the labor cost around instead of removing it. Track the ratio for a quarter before making either call. One good week does not prove trust; four in a row does.