AI agent or workflow automation? Choose the smallest system that works

An invoice arrives. The system reads it, checks the supplier, extracts the total and sends it for approval. Does that need an agent? Often the useful starting point is a defined workflow, with a model handling the part that requires interpreting a document.

Now consider researching an unfamiliar company. The system may need to choose a source, discover a contradiction, search again and decide when it has enough evidence. The route is harder to specify in advance. That is where an agent can become a candidate. The distinction matters because the freedom you add also creates work in evaluation, operation and control.

What is the difference?#

Anthropic distinguishes workflows, where code defines the path, from agents, where a model directs its process and tool use.^[1] We use that distinction here because it makes a buying or design decision concrete. It does not depend on which product calls itself an “agent”.

Map the task before choosing the architecture#

Write down the input, useful output and systems involved. Then list where a person currently makes a judgement. Some apparent judgement is simply an undocumented rule: invoices above a threshold need a second approval, or records missing a customer ID need manual review. Make those rules explicit first.

Other judgement may require interpretation without requiring freedom over the whole process. A model can classify a support message, after which ordinary code routes it to a queue. That hybrid can be enough. Ask exactly which step benefits from letting the system choose what to do next, and what evidence would show an improvement.

Use three examples to locate the boundary#

Invoice intake. A defined sequence can receive a file, extract fields, validate totals and request approval. Unreadable or inconsistent files go to a person. The model helps interpret the document; it does not need authority to create a supplier or release a payment.

Support triage. Start with classification, retrieval and a draft response. If a request requires navigating several systems to discover its cause, an agent may be useful inside a constrained investigation. Keep permissions separate: reading an order and issuing a refund are different capabilities.

Research assistance. An agent can explore sources and revise a plan. Require it to return evidence links and mark unresolved questions. A plausible paragraph without supporting material should not count as a successful research task. These examples are hypothetical design cases, not reports of systems we tested.

Give the system less authority than the user has#

Define narrow tools with clear inputs and outputs. A tool that can read a specific customer’s order is easier to reason about than unrestricted database access. Keep the customer identity and permission decision outside model-generated arguments wherever possible. Retrieved text must not be allowed to rewrite the application’s access policy.

Separate preparing an action from executing it. A system might draft a refund request, show the amount and reason, then require an authorised person to approve it. The right boundary depends on the consequence and reversibility of the action. OWASP ASVS is a useful reference for verifying the surrounding application’s security controls.^[2]

Measure the whole job, including the rescue work#

Build a set of representative tasks with expected outcomes. Include ambiguous inputs, unavailable tools, incomplete records and requests outside the system’s authority. Run the simplest viable workflow and the agent on comparable cases. Record whether the result was useful, whether a person intervened and how much time that intervention took.

Track cost per accepted result, rather than cost per model call. A cheap call repeated many times with a lengthy human correction can be expensive. Track elapsed time too: a user may prefer a predictable answer in seconds to an exploratory process whose duration varies. Avoid presenting a handful of selected demos as a reliability rate.

Decide how it stops and how a person takes over#

Set limits on tool calls, elapsed time and spending. Define what happens when the system repeats itself or cannot establish a fact. Preserve enough execution history to diagnose the problem, while avoiding unnecessary storage of sensitive material. A human handoff should carry the facts already discovered and the unresolved decision.

Version the instructions, tool definitions and evaluation cases. When you change a model or add a tool, rerun the relevant cases before expanding access. Our production-readiness checklist covers the surrounding release responsibilities.

Choose the smallest useful amount of autonomy#

Use rules when rules solve the task. Use a model inside a workflow when interpretation is the missing capability. Consider an agent when choosing the route is itself valuable and you can evaluate the result. This progression gives you a baseline against which additional complexity must earn its place.

The tooling decision comes afterwards. Whether you choose a no-code platform or custom software, ask the same questions about permissions, evidence and recovery. An architecture is useful because it completes the work reliably, not because its label sounds more advanced.

Build a small evaluation set before choosing autonomy#

Run the same cases against a simple workflow and the proposed agent. Use representative examples, including difficult cases, and keep an untouched set for later checks. Define acceptance before inspecting the result. If human correction is allowed, record it explicitly rather than counting the corrected output as autonomous success.

Anthropic’s evaluation guidance discusses examining transcripts and outcomes with different kinds of graders. For your product, the key is a result that can be checked against the task: the right record changed, the answer is supported, and permission boundaries were respected.

Compare cost per accepted outcome#

Use this definition: cost per accepted outcome = (tool charges + review effort cost + correction effort cost) ÷ accepted outcomes. State how you value human effort and whether the accepted result permits correction. If there are zero accepted outcomes, the ratio is undefined; report the failure instead of a misleading cost figure.

For an illustrative run, £10 of tool charges plus £40 of review and correction cost across 20 accepted tasks produces £2.50 per accepted outcome. If only ten tasks were accepted at the same total cost, it becomes £5. These numbers are arithmetic examples, not observed agent performance.

Report elapsed time and unauthorised actions separately. A cheaper system is not acceptable if it achieves savings by taking actions outside its authority. A low-risk test set also cannot establish behaviour on a different high-consequence task. Expand permissions only after defining the relevant evidence and controls.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. Anthropic: Building effective agents ↗

   Published 19 December 2024. Cited for the workflow/agent distinction; the page notes that its tooling landscape has since changed.

   Accessed 16 October 2026
2. OWASP Application Security Verification Standard ↗

   A framework for verifying application security controls, not a certification conferred by this checklist.

   Accessed 16 October 2026
3. Anthropic: demystifying evaluations for AI agents ↗

   First-party engineering guidance on evaluating agent behaviour and outcomes. Product examples in our article are illustrative.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.