Key takeaways
- The difference is path ownership. A workflow follows a path its designer defined; an agent decides which step or tool comes next from the state it observes.
- Use a workflow when the branches are knowable in advance. Use an agent when the task is open-ended enough that the next useful step cannot be listed beforehand.
- Most operating processes should be hybrid: a deterministic shell owns triggers, permissions, approvals and records while an agent handles one bounded investigation or drafting step.
- Agent flexibility costs more in latency, evaluation and failure surface. Do not pay that cost merely because one step uses a language model.
- Compare both approaches on the same awkward case and the same stop conditions. A happy-path demo hides the decision you are actually making.
The category boundary is path ownership
The label AI workflow does not settle this choice. A fixed path can call a language model to classify a message and still be a workflow. An agent can use the same model and the same tools, but the model selects the next action from the goal and the current state.
Anthropic draws this line explicitly in its engineering guide to agents: workflows orchestrate models and tools through predefined code paths, while agents dynamically direct their own process and tool use. The same guide recommends starting with the simplest approach because agents trade latency and cost for flexibility. That recommendation is vendor-authored, but the architectural distinction is concrete enough to test in your own design.
Ask one question at each point in a sample run: could the designer list the valid next steps before seeing this case? If yes, the path belongs in a workflow. If no, ask whether discovering the next step is genuinely part of the job. If it is, that bounded part may belong to an agent. “There are many branches” is not enough. A large map is still a map.
| Dimension | Predefined workflow | AI agent |
|---|---|---|
| Who chooses the path | The designer, before the run. | The model, during the run, within its tools and constraints. |
| Best fit | Recurring work with known branches and a stable finish condition. | Open-ended work where useful steps depend on evidence discovered along the way. |
| Test shape | Branch coverage: each input reaches the expected output. | Outcome evaluation: different valid paths may still pass the same goal and safety checks. |
| Failure surface | A broken condition, connector, mapping or unavailable service. | Those failures plus poor planning, wrong tool choice, looping or compounding interpretation errors. |
| Cost and latency | Usually bounded by the steps the designer fixed. | Variable with the number of observations, decisions and retries. |
| Audit question | Did the configured path execute correctly? | Why did it choose this path, and was the result acceptable? |
The six-question path-ownership test
- Can you list the allowed next step after every state in five real cases?
- Does the number or order of useful steps change because of information discovered during the run?
- Can two different paths both be correct, with the result judged by an outcome rather than an exact sequence?
- Is there a reliable source of ground truth after each action, so the system can observe whether it worked?
- Can you bound the tools, permissions, turns, time and cost without removing the flexibility you wanted?
- Is a person named to receive the case when the system cannot finish inside those bounds?
A “no” on the first question and “yes” on the next five is an agent-shaped problem. A yes on the first means a workflow can own the path even if one box uses model judgment. A no on questions four, five or six means the problem is not ready for either architecture. It has no feedback, boundary or fallback.
This is where the deterministic versus agentic decision becomes more useful than a category label. The whole process does not have to inherit the answer given to its hardest step.
One request, run both ways
The goal. Operations needs a short renewal brief covering current terms, internal usage, unresolved support issues and material changes in the supplier's public documentation. A person makes the renewal decision.
As a predefined workflow. On a date from the contract record, fetch the contract fields, query the usage report, collect open tickets, open three named public pages, draft the brief in a fixed template and send it for review. The design is excellent if those sources and questions are stable. Every run follows the same six steps, so coverage and failure are easy to inspect.
Where the workflow strains. One supplier announces a product migration on a page nobody listed. Another changed its documentation structure. A third has no usage because a subsidiary uses a separate account. Adding branches after each surprise creates a growing research tree.
As an agent. Give the system the same goal, approved internal sources and a restricted web-search tool. It begins with the contract, decides which evidence is missing, searches within the allowed domains, follows relevant product notices, and stops when the brief's four evidence sections are supported or a turn limit is reached.
Where the agent strains. It may search too broadly, mistake a similarly named product, spend more turns on an unimportant gap or produce a plausible brief with weak evidence. Each observation must be retained, sources must be attached to claims, and the renewal action itself remains outside its tools.
The hybrid. A deterministic workflow triggers, collects known internal records, creates the run, enforces allowed tools and deadlines, and routes the final brief. A bounded agent owns only the public-evidence investigation. A person reviews the brief and makes the renewal decision. This is usually the useful answer because only one part of the task has an unknowable path.
What belongs outside the agent
An agent does not remove the workflow around it. Anthropic's current description of a trustworthy agent is a loop that plans, acts, observes and adjusts. The same source says autonomy creates room to misread intent, take unintended actions and encounter prompt-injection attacks. Its practical advice is to control the tools, permissions and environments the agent receives.
| Keep deterministic | Allow agent choice | Keep human |
|---|---|---|
| Trigger, run ID and duplicate prevention | Which approved evidence source to inspect next | Clarifying a goal the system cannot infer safely |
| Credential scope and the list of available tools | How to divide an open-ended research task | Approving access the current run does not have |
| Maximum turns, time, spend and retry policy | Whether the observed result closes an evidence gap | Accepting a consequential recommendation or commitment |
| Output schema, source requirement and record retention | The order of reversible investigation steps | Handling the case after the bounded fallback fires |
NIST's AI Risk Management Framework reinforces the operating point without prescribing an architecture: roles, responsibilities, monitoring and periodic review should be defined across the system lifecycle, and viable non-AI alternatives belong in the decision. “Can an agent do this?” is one input. “Does its flexibility repay the additional control and evaluation?” is the purchase question.
The flexibility bill arrives in five places
Model usage is the visible line item, but it is rarely the whole difference. An agentic loop has a variable number of decisions and tool calls. That affects response time and run cost. It also changes the work around the system: more paths need evaluation, more intermediate state must be retained, and more failure modes need a handoff.
| Cost | Workflow question | Agent question |
|---|---|---|
| Build | How many branches must be specified and maintained? | How are tools, goals, context and stop conditions designed? |
| Run | What is the fixed step and service-call count? | What are typical and maximum turns, tool calls and model use? |
| Evaluation | Which branch tests prove the configured path? | Which cases and graders prove acceptable outcomes across valid paths? |
| Operations | Which failed step is retried or replayed? | How is partial state handed off when the loop stops or wanders? |
| Change | Which branch or mapping changed, and what regression set covers it? | Did the model, prompt, tool description or environment change behaviour? |
A fixed workflow can be expensive to build when it has hundreds of legitimate branches. An agent can be cheaper to start when the path is hard to enumerate. The direction can reverse in production: once the same choices repeat, carrying them as model decisions means paying to rediscover a rule every run. Record recurring successful choices and codify the ones the process owner can now state.
Procurement language such as “agentic platform included” says nothing about this bill. Ask for a trace from one ordinary case, one awkward case and one forced stop. Count actions, elapsed time, human review and recovery work. Then compare the fixed and agentic designs on the same cases rather than comparing two vendors' preferred demos.
A category decision you can write in one paragraph
Finish the evaluation with a short architecture decision. Name the process, the part whose path cannot be defined in advance, the evidence that proves that claim, the tools and actions allowed, the maximum run budget, the output check, the human gate and the fallback. If the paragraph cannot name the unknowable part, use a workflow. If it cannot name the bounds and pass condition, keep the agent in observation mode.
This record matters because the attractive part of an agent is also the easiest part to expand later. A research agent receives one more tool, then permission to draft, then permission to send. Reviewing the original paragraph makes expansion a deliberate policy change instead of a sequence of convenient toggles.
How this comparison was evaluated
This page compares architecture categories, not two products. No pricing, connector, model-performance or vendor-security claims were tested. The matrix was checked against the category definition and tradeoffs in Anthropic's engineering guidance, its 2026 agent-control guidance and NIST's lifecycle risk outcomes on 28 July 2026.
The worked request is simulated. It was run as a paper design in two forms: a six-step fixed path and a bounded observe-decide-act loop. The test notes record what must be known before the run, what may be chosen during it, where evidence comes from, how the run stops and which action stays with a person. It is designed to make the architectural tradeoff reproducible without pretending to benchmark unnamed software.
Limitations and when not to use this
- “AI agent” is not used consistently across the market. Some products call a fixed sequence with model steps an agent. Evaluate who chooses the next step rather than trusting the label.
- This page does not compare vendors, features or pricing, and it has not been independently reviewed by a named product reviewer. Product claims require a separate dated test.
- The worked request is simulated and intentionally reversible. Processes involving money, access, employment, health, legal rights or other significant effects need domain-specific controls beyond this category test.
- A workflow can still be the wrong design when the underlying process is unstable or unowned. Architecture cannot repair a decision the organisation has not made.
Sources
- Building effective agents — Anthropic Accessed 28 July 2026
- Trustworthy agents in practice — Anthropic Accessed 28 July 2026
- AI Risk Management Framework Core — NIST Accessed 28 July 2026
Run the path-ownership test
Take one real case and write down the next step at every point. The implementation guide turns the gaps into a bounded first build.
Run the path-ownership testUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.