Workflow or agent? Choose the least autonomy that works

The framework question usually arrives too early. Before choosing a library or drawing a group of agents on a diagram, decide whether a model should choose the next step at all.

That decision changes the way a system fails and the work required to run it. A fixed workflow puts the sequence in code and gives the model bounded jobs inside it. An agent lets the model decide how to proceed, often by selecting tools and repeating steps until it reaches an outcome or a stop condition.

A five-step workflow is not a less mature agent. For stable work, it may be the finished product.

The rule I use is simple: choose the least autonomy that can improve the current process. Add another degree of freedom only when failed cases show why it is needed, and only when the team can evaluate and control the result.

Who controls the route?

Anthropic’s definition is useful because it is architectural rather than promotional. Workflows send models and tools through paths defined in code. Agents direct their own process and tool use.

The distinction is about control flow, not whether a system uses an LLM. Code can route a support request, call a model to classify it, retrieve an approved policy, ask a second model call to draft a reply, validate the output, and send it to a review queue. That is an AI workflow. The model did important work, but it did not decide the route.

An agent might receive the same support request, decide which account records and policies to inspect, ask the customer for a missing fact, then choose whether to draft a resolution or escalate. The route emerges while the run is underway.

Agent runs tend to have more variable latency and spend, with more paths to test. Anthropic recommends starting with the simplest approach that works and accepting complexity only for a worthwhile gain.

Autonomy is not one switch

Teams sometimes debate whether a system is “an agent” as if the answer also settles its permissions. It does not. Path selection, tool choice, authority, and run length can be configured separately.

Decision	A narrow setting	A broader setting
Route	Code fixes every step	The model plans the next step
Tools	Code calls one named tool	The model selects from approved tools
Authority	Read or draft only	Write, send, spend, or execute
Duration	One pass with a fixed timeout	A loop with several attempts
Handoff	Every result goes to review	Only exceptions go to review

A model can investigate flexibly with read-only tools, then give its findings to a person. It can also follow a fixed path while holding a dangerous write credential. The second design is less agentic but may carry more operational risk.

Keep these decisions separate. Granting control over the route does not require granting control over the final action.

Start with the path you can predict

Map the current workflow before adding a model. Record what starts the work, what a correct result looks like, which systems provide facts, where policy applies, and who handles exceptions. Then mark the steps that follow stable rules.

Put those stable rules in code. Use model calls for bounded work that benefits from language or judgment, such as extracting fields from a document, classifying a request, comparing two passages, or preparing a draft. Validate structured outputs before another system consumes them. Keep normal software checks for amounts, dates, identifiers, and permissions.

This first version also reveals the actual exception queue: where the route breaks, how often, and whether the same causes keep returning.

If a few patterns explain most exceptions, add branches or improve the source data. An agent is useful when the needed path varies with context and the rules required to encode it have become fragile or unmanageable. OpenAI’s guide to building agents points to nuanced decisions, difficult-to-maintain rules, and heavy use of unstructured data as signals that an agent may fit. It also recommends checking that a deterministic solution will not suffice before committing to one.

Move only the uncertain part

Do not hand the whole workflow to an agent because one step contains exceptions. Keep the predictable path and place a bounded agent around the part where route selection has value.

Give it a small set of distinct, well-documented tools. A tool should do one understandable thing, return a result the model can interpret, and enforce authorization outside the prompt. If two tools look nearly identical, tool selection becomes harder to diagnose. If one tool accepts a vague command and can modify anything, the permission boundary is too broad.

Start with one agent. Turning every specialty into a separate agent creates handoffs, more prompts, and more places for context to be lost. OpenAI’s guide recommends expanding a single agent first and splitting the system only when complex instructions or overlapping tools produce persistent failures.

Set stopping conditions in code. A run can end after a final structured result, a failed tool call, a maximum number of turns, a cost limit, or an explicit escalation. “Continue until you are confident” is not an operating limit.

Let consequence set the permission boundary

Ask what the system can change, who will notice a mistake, and how hard the action is to reverse. A weak internal draft can be corrected. A message sent to a customer may require an apology and a case review. A changed bank record or approved payment creates a different class of exposure.

For work with meaningful consequences, the first agent version should usually gather evidence and prepare a recommendation. Keep the final action with a person until the system has a measured track record. Human review needs a designed interface: show source facts, the proposed action, unresolved questions, and a clear way to reject or correct the result. A bare approval button invites rubber stamping.

The NIST AI RMF Core treats scope, expected costs, human oversight, testing, and monitoring as documented parts of the system lifecycle. That framing helps here. The permission boundary should come from the use context and impact of failure, not from how capable the model looked in a demo.

Evaluate the whole run

A fixed workflow can be tested at clear seams. Did extraction match the verified fields? Did routing choose the correct queue? Did validation reject a malformed amount? Also test the final outcome, because individually plausible steps can still combine into a bad result.

Agent evaluation needs the entire run. Anthropic’s guide to agent evaluations separates the transcript from the outcome. The transcript records outputs, tool calls, and intermediate results. The outcome is the final state of the environment. An agent may claim that it updated a record even though the database did not change. Checking only the final message misses that failure.

Build tasks from representative historical work and define success before running them. Use hard checks where the environment allows them: a record exists, a total matches, a forbidden tool was not called, or the case landed in the right queue. Use a written rubric and calibrated human review for judgments that cannot be reduced to a field comparison.

Run important cases more than once. Model behavior varies, and one successful attempt can conceal an unreliable route. Record task success, unsafe actions, unnecessary tool calls, escalations, latency, and cost. Group failures by cause rather than staring at a single pass rate. A missing source fact calls for a different fix than a bad tool description.

Production monitoring shows what happened on live traffic. The case set compares a prompt, model, tool, or permission change before it reaches users. You need both.

A hypothetical invoice workflow

Consider a hypothetical accounts-payable team that matches invoices against purchase orders and receiving records. The initial design can stay fixed. A model extracts invoice fields into a schema. Code validates the fields, retrieves the matching records, applies documented tolerance rules, and routes clean matches into the existing approval process. Mismatches go to a person with the source records attached.

After running that workflow, the team reviews its exception queue. Many mismatches may share a stable cause, such as a known freight line or a supplier identifier change. Those deserve code or better master data. A smaller group may require a flexible search across partial receipts, vendor history, and receiving notes. That is a credible boundary for a bounded agent.

The agent receives read access to those sources. It chooses what to inspect, cites the records it used, and prepares a resolution summary for the AP lead. It may draft a question for the vendor, but a person approves the send. It cannot modify vendor bank details, alter a purchase order, or approve a payment.

Test it first on resolved historical exceptions. Then run it in shadow mode on live cases, where its recommendation is recorded but does not affect the process. Compare its outcome with the AP lead’s resolution, inspect disagreements, and rerun the test set after each material change.

If the evidence supports a wider boundary, add one reversible action, not a bundle of permissions. For example, the agent might attach a verified receiving note to the case while payment approval remains with a person. The next evaluation then measures the effect of that single change.

Know when the fixed workflow has won

A fixed workflow has won when it meets the target on representative cases, operators can understand its failures, and added autonomy does not produce enough improvement to justify its cost and risk. Stop there. There is no prize for replacing legible code with a model loop.

Do not add an agent when the team cannot agree on a correct result, source data is unreliable, or no one owns exceptions. Flexible planning may hide those problems and make failures harder to explain.

When real exceptions do require changing routes, add a bounded agent around those cases. Keep its tools narrow, its consequential actions behind approval, and its full runs under evaluation. The A.G.E.N.T. delivery framework follows the same sequence: begin with one owned workflow and a case set, build the smallest system that passes, then leave the operating team with monitoring and a clear escalation path.

The architecture can change later. It should change because the evidence changed.

Further reading

• Building effective agents, Anthropic
• A practical guide to building agents, OpenAI
• Demystifying evals for AI agents, Anthropic
• AI Risk Management Framework Core, NIST