Teams planning their first AI automation often ask whether they need "an agent" or "a workflow". The question matters because the two behave very differently when something goes wrong, and because the more autonomous option costs more to run and to supervise.
The short answer: use a workflow wherever you can write down the steps, and let an agent handle only the part where you cannot. Most good designs are a workflow with an agent inside one or two steps.
The two terms, defined#
Anthropic's engineering team drew a useful line in its guide "Building effective agents". It describes workflows as systems where models and tools are orchestrated through predefined code paths, and agents as systems where the model dynamically directs its own process and tool use, keeping control over how it completes the task.
Put simply: in a workflow, you decide the order of steps. In an agent, the model decides. A workflow can contain model calls at several steps and still be a workflow, because the path is fixed. An agent loops: it picks a tool, looks at the result, and picks again until it believes it is done.
Why the difference matters#
Predictability. A workflow runs the same path every time. You can test each step, and a failure points at one step. An agent may take a different route on each run, so the same input can succeed twice and fail on the third.
Cost and speed. An agent makes several model calls with growing context to reach an answer. Anthropic's own guide warns that the autonomous nature of agents means higher costs and the potential for compounding errors, and advises finding "the simplest solution possible", increasing complexity only when needed.
Oversight. It is easy to put an approval in front of a known step. It is harder when you do not know in advance which tools the agent will use. You then need to restrict the tools it has and gate the risky ones.
A decision table#
| Question | Points to a workflow | Points to an agent |
|---|---|---|
| Can you list the steps in advance? | Yes | No, they depend on what is found |
| Is the input format stable? | Yes (forms, invoices, tickets) | No (open-ended questions, research) |
| What does a mistake cost? | High, or hard to undo | Low, or easy to review |
| Do you need the same answer every time? | Yes | Variation is acceptable |
| Is volume high and margin thin? | Yes, keep calls few | Volume is low |
| Does the task need many tools chosen on the fly? | No | Yes |
If most answers sit in the left column, build a workflow. If they are mixed, you probably want the hybrid below.
Workflows are not "less AI"#
A common worry is that a fixed workflow is old-fashioned automation with a model bolted on. That undersells it. The patterns Anthropic lists are all workflows: chaining model calls with checks between them, routing an input to a specialist step, running subtasks in parallel, and having one model draft while another reviews. These cover a great deal of real work, such as classification, extraction, summarising and drafting, with far less variance than a free-roaming agent.
For a lot of tasks, a single model call with good retrieval and a few examples is enough. Do not add a loop until you have seen the single call fail.
The hybrid pattern#
The pattern that works best for most teams is a deterministic outline with an agent in the gap:
- A fixed first step receives and cleans the input.
- A cheap classification step decides what kind of request it is.
- Common, well-understood kinds go down a fixed path with no agent at all.
- The unusual kinds go to an agent that has a small, deliberate set of tools.
- The agent's proposal passes through a check, and risky actions wait for a person.
- If the agent cannot finish within a step limit, the case goes to a human queue.
This gets you the cost and predictability of a workflow for the bulk of traffic, and flexibility where you actually need it.
Building it in Cadrix#
On the canvas, this is a small graph:
- Start with a message, webhook or schedule.
- Classification step: a model call that returns one label from a short list you define (for example "order status", "refund", "other").
- Condition routes by label. "Order status" and "refund" go to fixed branches that call your systems through web requests or connected tools.
- Agent handles the "other" branch. Give it only the tools it needs, a clear instruction, and a knowledge base if it must answer from your documents.
- Condition after the agent: if it returned a confident answer, send it; if not, continue to the next step.
- Human Input pauses for a person to approve, edit or reject, and the final action runs only after that.
Each run is recorded step by step, so when the agent branch takes an odd route, you open the trace and see which tool it chose and what came back. That visibility is the main reason to keep agents small and bounded.
Signs you picked wrong#
If your "agent" always calls the same three tools in the same order, it is a workflow. Turn it into one, save the cost, and gain testability. If your "workflow" has grown a thicket of conditions to handle every special case, it may be time to give one branch to an agent.
Revisit the choice after a month of real runs. The traces show which cases are routine and which are not.
