AI agent vs workflow: when should a model choose steps?
Use a workflow when you can write the steps and branches in advance. Use an agent when predefined rules cannot reliably cover the next useful action and a model must interpret results to choose it. Workflows can branch on tool results and call models to classify requests or write summaries. Those features alone do not require an agent loop.
I would start with a fixed workflow and add model-chosen steps only where it fails on real tasks. This follows Anthropic’s distinction between predefined workflows and model-directed agents. The useful question is what the model needs to decide, before choosing a framework.
Last reviewed: 2026-09-08.
Compare two support requests
“Where is order 123?” has a known path: check access, fetch the order, read its shipping status, and return the result. A model can phrase the reply, but it does not need to decide which system to query next. Missing orders and service errors can have explicit branches.
“Why does this job fail only after a restart?” is less predictable. The first log may point to a missing file, a stale credential, or a service that starts too late. An agent can inspect that result and choose the next check. The application must still restrict which files and tools it can use.
That second pattern is the core of ReAct: alternate actions with observations that can change the next action. It adds flexibility, but also more chances to choose an unhelpful step.
Choose the smallest amount of model control
| What the task needs | Starting point | What you still own |
|---|---|---|
| Known steps and error branches | Ordinary workflow | Validation, retries, and failure handling |
| One choice among known routes | Classifier followed by fixed workflows | Routing tests and a path for uncertain cases |
| A tool plan that can be written before execution | A planned tool graph, such as ReWOO | Plan validation and recovery when assumptions fail |
| Next actions need model judgment | A bounded agent loop, such as ReAct | Tool permissions, stop rules, and completion checks |
| Large subtasks with local exploration | Plan-and-execute | Shared state and explicit rules for changing the plan |
A plan produced by a model also needs validation before execution. ReWOO separates planning, tool execution, and answer synthesis; it does not supply your application’s permission or recovery rules. If the tool sequence is already known in code, a model-written plan may add no value.
Test the decision before adding more agents
Compare the fixed workflow and agent on the same tasks, tools, data, and total budget. Include a missing result, a timeout, and a result that changes the likely next step. Count failed and unfinished attempts. Measure correct completion, unnecessary actions, elapsed time, and cost.
For any path that changes external state, verify what happened before retrying a timed-out call. A lost response can hide a completed action; the application needs a stable operation ID or a reliable status lookup. AWS’s guidance on safe retries explains the request-identity contract.
Keep the agent only if the added choices solve enough of the workflow’s failures to justify their cost. Splitting the same work among several agents is a separate experiment.
Deeper reading
- AI agent reasoning loops compares ReAct, ReWOO, and plan-and-execute through one worked system.
- Harness engineering explains who checks actions and decides that the result is complete.
- Long-running agent runtimes covers recovery when the work outlives its worker.
- Agent framework comparison helps choose an implementation once the control flow is clear.