Consider two requests: extract a date from an invoice, and investigate why a customer’s shipment failed. The first has a narrow output. The second may require checking an order, reading a carrier update and deciding which missing fact to seek next. Putting both behind an agent does not make them the same engineering problem.
Why it matters: Useful autonomy depends on the shape of the task and the cost of a wrong action.
Start with the path the task takes
Anthropic draws a practical distinction between workflows, whose steps are arranged in code, and agents, which direct their own tool use. Its guidance also notes that autonomy can increase latency, cost and the chance of errors accumulating. Building effective agents.
For a fixed extraction task, a known sequence is easy to inspect. The team can validate the date format and send an unclear invoice to review. An agent becomes more interesting when the correct next step depends on what it finds, especially when enumerating every branch would be cumbersome.
The decision should be tested with the team’s own work. A compelling demo does not reveal how often the system loops, asks an unnecessary question or overlooks an unusual case.
Define what finishing means
In a hypothetical support workflow, writing “I have resolved the issue” is a poor completion test. The useful outcome might be a corrected delivery address in the right record, with the customer given an accurate explanation.
Anthropic’s evaluation guide makes this separation explicit: the transcript records what an agent did and said, while the outcome is the resulting state of the environment. It also describes code-based, model-based and human grading, each with different limits. Demystifying evals for AI agents.
For a product team, that suggests checking both the work and its consequences. Did the right record change? Was unrelated information left alone? Could a person understand the result well enough to challenge it?
Put a price on the extra freedom
Compare a simple workflow and an agent on the same set of representative tasks. Measure accepted outcomes, elapsed time and the amount of human correction. A system that completes more difficult cases may justify extra computation. A system that mainly produces longer explanations may not.
A stopping rule is part of the product. The agent should have a clear route to ask for missing information or return control when progress stalls. Endless retries can turn an ambiguous task into an expensive one without improving the answer.
The strongest case for an agent is a task with meaningful branching, accessible evidence and an observable result. Start there, then expand the permissions and workload only when the evaluation supports it.
For a connected perspective, see The Cost of Intelligence Is Moving to Operations.
Reporting & Sources
Architecture analysis based on primary engineering guidance, reviewed September 26, 2026. The examples are hypothetical, not reported customer tests.
