I’ve become less interested in asking whether an agent is autonomous.
The question sounds useful until you try to use it for an actual piece of work. An agent can run for an hour, call dozens of tools, recover from intermediate mistakes, score well on a benchmark, and still fail the job you thought you handed over.
Take a boring hypothetical. I ask an agent to update 50 records under a defined rule. It updates 49 correctly, touches nothing else, returns no errors, and says it is done. The run was long. The tool calls worked. The final message is confident.
One record is still wrong.
That is the part I think our usual autonomy language handles badly. We tend to attach the word to the model or the agent, as if autonomy were a permanent property. But the thing I actually need to know is much smaller and much less glamorous: what exact work did I delegate, what counted as done, what help was expected, what side effects were allowed, and what evidence tells me the job really finished?
For me, the useful unit is the delegated job.
Capability is real. It is still not completion.
This is not an argument against benchmarks or difficult capability evaluations. Those measurements answer real questions, and dismissing them would make the argument worse, not better.
The problem starts when one kind of evidence quietly inherits authority over another question.
Cohere Labs’ Agentic Task Ecosystem analysis gives a useful example. Cohere aggregated roughly 696,000 published tools across about 123,000 public MCP servers and mapped them against O*NET task statements. It used a strict end-to-end classification: did a tool perform the named work task, rather than provide information or handle one step while a person continued coordinating the rest?
Under that classification, 2.6% of the public tools in the corpus cleared the end-to-end bar.
That number needs a large fence around it. It does not mean only 2.6% of jobs can be automated. It does not measure workplace adoption or general agent reliability. Cohere describes ATE as a supply-side view of public agent-callable tooling, and private internal MCP infrastructure is not represented in those public directories.
The useful point is narrower: being callable by an agent is not the same thing as owning the task from start to finish.
The same boundary applies to model evaluations. OpenAI’s GPT-6 Astra release presents benchmark and capability evidence across computer use, professional work, coding, science, cybersecurity, and alignment. Those results are evidence for the evaluations OpenAI reports. They are not automatically a completion contract for every later job someone delegates in a different environment.
A benchmark can tell me that a system can perform. I still need to know whether my job got done.
I think autonomy needs three layers of evidence
I find this easier to reason about when I stop trying to compress everything into one score.
| Evidence layer | The question it answers |
|---|---|
| Capability evidence | Can the system perform the relevant operation or class of task under the evaluation’s conditions? |
| Completion evidence | Did the exact delegated unit satisfy its acceptance criteria, with missing work and failure made visible? |
| Operational-autonomy evidence | Did it complete the job inside the allowed authority, intervention, side-effect, time, cost, recovery, and oversight boundaries? |
A system can pass one layer and fail the next. That is not inconsistency; it is a more precise diagnosis.
This is also why I do not think “autonomous” is very meaningful without the task attached. A system might be good enough to research a bounded question with source requirements and an explicit uncertainty handoff, but not good enough to modify production records where identity resolution, authorization, rollback, and side effects matter much more.
Same model. Different job. Different evidence burden.
The completion contract has to exist before the run
The uncomfortable part is that “done” cannot be invented after the trajectory ends.
If I want to evaluate delegation, I need to define the job before I watch the agent perform it. Otherwise the agent, or the reviewer, gets to move the finish line toward whatever happened.
A practical completion contract can stay small. I would want it to answer at least these questions:
| Contract field | Question |
|---|---|
| Delegated unit | What exact piece of work does the system own from start to handoff? |
| Starting state | What context, files, data, credentials, or environment state may it assume? |
| Allowed authority | Which actions, tools, systems, and external effects may it use? |
| Required outcome | What artifact or state must exist when the work is complete? |
| Acceptance criteria | How will someone determine that the outcome is correct and complete? |
| Planned checkpoints | Which human decisions or approvals are part of the intended workflow? |
| Unplanned intervention | What kinds of rescue, redirection, or takeover count against autonomous completion? |
| Failure semantics | How does the system expose blocked, partial, failed, or uncertain states? |
| Side-effect boundary | What must not be changed, spent, sent, deleted, or left behind? |
| Recovery | What can be retried, rolled back, resumed, or escalated? |
| Evidence of done | What tests, logs, source pointers, diffs, checks, or rationale establish completion? |
| Residual uncertainty | What unresolved work must survive the handoff instead of being smoothed away? |
Not every job needs all twelve fields turned into paperwork. The point is to stop important dimensions from disappearing inside one word.
A research task might need a bounded question, source coverage, uncertainty, and a clear handoff. A code change might need the requested behavior, passing tests, a constrained diff, and disclosure of anything that could not be run. A production mutation may need much stronger authority, postcondition, rollback, and audit requirements.
The contract should scale with consequence.
Human involvement is not one thing
One definition of autonomy treats any human intervention as failure. I do not think that survives contact with useful systems.
A workflow can include planned approvals, safety gates, clarifying questions, or final acceptance and still delegate substantial work. In some cases, asking before an irreversible action is exactly what the system is supposed to do.
The distinction I care about is planned intervention versus unplanned rescue.
A planned checkpoint was part of the contract. A rescue happens because the system lost the objective, omitted required work, could not recover from an ordinary failure, or needed a person to reconstruct state and tell it how to continue.
Those are very different forms of “human in the loop.”
A rough intervention record might distinguish:
- planned checkpoint;
- necessary clarification;
- safety or authority gate;
- exception escalation;
- corrective intervention;
- rescue or takeover.
The first four can be compatible with useful autonomy. The last two tell me the delegated unit exceeded the system’s reliable operating envelope, or that the workflow around it was not complete enough.
This also avoids a strange incentive where the agent that confidently does the wrong thing without asking scores as “more autonomous” than the agent that correctly stops on an unresolved ambiguity.
I would rather have the second one.
A clean run can still fail the job
Some of the failures that matter most never become infrastructure errors.
A tool call can return successfully. The process can finish. The artifact can look polished. The system can still have skipped a required branch, used stale evidence, changed only part of the target set, or dropped a material qualification in the final synthesis.
I wrote about the same seam from the production-observability side in The Failure Never Became an Error: execution health and task correctness overlap, but neither proves the other.
For a completion test, that means failure visibility is part of the evidence. I want the system to be able to distinguish states such as:
- completed and verified;
- completed with unresolved qualification;
- partially completed;
- blocked on an external prerequisite;
- failed but recoverable;
- failed and requires escalation;
- completion cannot be established.
The labels can change. The distinction cannot.
If “done” just means “the agent stopped acting,” then the completion test has already failed.
Side effects belong inside success
The requested artifact is only half the story when the system can change the world around it.
Suppose an agent produces the right result but also modifies unrelated records, sends something it was not allowed to send, leaves temporary resources running, incurs unacceptable cost, or makes an irreversible change outside the task boundary.
I would not count that as successful delegation just because the main artifact looked right.
Task success and acceptable execution are separate dimensions. The more authority a system receives, the less defensible it becomes to treat side effects as a safety footnote somewhere outside the completion criteria.
A completion test should therefore ask what changed, whether every change was in scope, whether irreversible actions were gated, whether temporary state was cleaned up, whether rollback exists where it matters, and whether the system can show what it actually did.
That evidence is part of the work, not decoration after the work.
Benchmarks and demos belong at the right layer
There is an easy overcorrection here: if benchmarks do not prove operational autonomy, maybe they are mostly theatre.
I do not think that is true either.
Benchmarks can isolate capabilities, make systems comparable under stated conditions, expose weaknesses, and track improvement. Demos can show possibility and reveal interaction patterns that were not practical before.
They simply should not be asked to establish more than they measured.
The same principle shows up in A Scorecard Is Not a Release Gate. An evaluation result can be excellent evidence while still not owning the operational decision that follows. Here the seam is slightly different: capability evidence can be excellent while still not proving that a specific delegated job completed under acceptable conditions.
The completion contract does not replace capability evidence; it puts a boundary around what that evidence can support.
One score would be easier. That is the problem.
A universal autonomy score is attractive because it compresses a messy decision into one number, but it also hides the reason I might trust one delegation and reject another.
A system that rarely needs intervention but sometimes creates unacceptable side effects has a different risk profile from one that asks frequent clarifying questions but stays inside scope. A system that reliably completes deterministic coding tasks may still be weak at open-ended research where missing evidence is hard to detect.
Those differences matter more to me than whether both systems land on the same scalar.
So instead of asking “How autonomous is this model?”, I would ask: Which completion contract can this system satisfy reliably enough that I am willing to delegate the work?
That is a much less exciting question. It is also one I can use.
The model is only part of the delegation system
The final shift is where I think the autonomy claim should attach.
A delegated job is not completed by a model in isolation but by a larger system: model, instructions, tools, context, permissions, state, retries, evaluators, approval gates, recovery behavior, and whatever evidence surface tells the next person what happened.
A stronger model can improve that system dramatically, but it does not remove the need to define what the system may do, what it must prove, when it should stop, and when somebody else must take over.
This is why long trajectories no longer impress me in quite the same way they used to. Persistence is useful. Tool fluency is useful. Strong benchmark performance is useful. None of them answers the question I eventually have to live with:
Can I give this system a real piece of work and know what happened when it says it is done?
If the system can only be trusted because a human is still expected to notice missing work, repair broken state, reinterpret the objective, or clean up unintended side effects, that human is still part of the completion mechanism.
The system may be extremely useful. It may be highly capable. But the autonomy claim is still ahead of the evidence.
For me, autonomy only starts where completion becomes legible.
// End of transmission. Make “done” inspectable — ZYANE