A system can investigate a software failure for an hour and still need permission to deploy a one-line fix. That is a sensible allocation of authority. The useful question is how much work an agent can complete inside a defined operating boundary, with evidence that another person can inspect.
We assess autonomy task by task. A document summarizer, a maintenance planner, and an infrastructure operator face different consequences, data constraints, and recovery options. Calling all three fully agentic hides the decisions a buyer actually needs to make.
Separate capability from authority
Capability describes what the system can accomplish under stated conditions. Authority describes what it is allowed to do for this requester, on these resources, at this time. A benchmark may inform the first question. It does not answer the second.
Anthropic distinguishes workflows from agents by whether predefined code paths or the model direct the process. That is a useful architectural distinction. The permission ladder below adds a separate operational view: which consequences have been delegated? It is an Agent9 design framework, not an industry certification scale.
Use a ladder of delegated consequences
- Observe: read approved sources and explain what changed. The output includes provenance and known gaps; the system cannot modify the underlying estate.
- Prepare: create a draft, patch, or proposed work order in an isolated workspace. The person responsible can inspect the complete artifact before external effects occur.
- Execute an approved action: perform a specific reviewed operation against named resources. Approval covers the exact payload, not a broad interpretation of the objective.
- Operate within standing limits: repeat a bounded task under explicit policy, with spending limits, allowed destinations, stop conditions, and a named escalation owner.
- Coordinate bounded work: choose and sequence several permitted tasks while preserving each task's limits. Coordination does not grant the union of every connected tool's privileges.
Expand the action scope only after the system demonstrates useful performance, correct denials, and recovery under the conditions that matter. A longer uninterrupted run is not sufficient evidence.
Work through one concrete example
Consider a public-source infrastructure-monitoring assistant. At the observation stage it compares current and previous measurements, links its sources, and labels missing coverage. At the preparation stage it creates an incident brief. Both stages can be useful even if a human owns every operational response.
A narrow next step might allow the assistant to open an internal ticket when a defined combination of observations occurs. That grant should name the queue, required evidence fields, duplicate suppression rule, and escalation conditions. It should not also permit configuration changes on the monitored network.
To evaluate the next level, replay cases with stale observations, conflicting sources, duplicate events, and an unavailable ticket service. Inspect whether the assistant distinguishes observed loss of visibility from an actual outage. Check whether it preserves uncertainty after another agent summarizes the case.
Measure errors by their consequence
A single success percentage can conceal the behavior that makes a system unacceptable. Track false escalations, missed required escalations, prohibited actions attempted, prohibited actions executed, and unreconciled external writes separately. Also measure useful completion and the reviewer time needed to accept it.
Set acceptance thresholds with the workflow owner before evaluation. A tolerable drafting error may be an intolerable operational command. Preserve the test-set version and deployment configuration so a later model or tool change does not inherit an old result without rechecking the affected behavior.
Design for an orderly handback
The system should return control with the objective, completed steps, supporting evidence, unresolved uncertainty, and next allowed action. A vague failure message forces the operator to reconstruct the entire run. A clear handback preserves useful work while authority remains with the person or policy that owns it.
In a defense-program demonstration, ask to see a deliberate stop: missing evidence, changed authorization, or an unavailable dependency. Use public or synthetic data until the intended data handling is explicitly established. A team that can explain the stop condition gives reviewers a more useful basis for evaluation than an unqualified claim of end-to-end autonomy.
Buy and build bounded outcomes. Define authority independently of capability, evaluate failure behavior, and make the handback as deliberate as the happy path.
Continue the conversation
Bring Agent9 one workflow, its operating constraints, and the evidence you need before deployment. Discuss the engineering problem.