Workflow or agent? A practical way to choose
Most automation doesn't need an autonomous agent. Four questions that tell you when a plain workflow is the better answer, and when it isn't.
evanbyte5 min read
The most expensive mistake in AI projects is reaching for an agent when a workflow would do. Agents are flexible, and flexibility has a price: they are harder to test, harder to predict, and slower and costlier to run. Sometimes that price is worth paying. Often it isn't.
A spectrum, not a switch
'Agent' covers a wide range of designs. It helps to place yours on the spectrum before you build it.
| Design | Who decides the next step | Good for |
|---|---|---|
| Script or rules | Your code, always | Steps that never vary |
| Workflow with a model step | Your code, with a model handling one fuzzy step | A fixed process with messy input: classify, extract, summarize |
| Router | A model picks one of several fixed paths | Requests that fall into a few known types |
| Agent loop | The model, step by step, using tools | Open-ended tasks where the path can't be known in advance |
| Several agents | Models handing work to other models | Rarely needed. Try a single agent first |
Moving down the table buys flexibility and costs control. Start at the top, and move down only when the evidence says you must.
What you give up as you move down
The price of autonomy shows up in the places that matter most once a system is live.
| Workflow | Agent loop | |
|---|---|---|
| Testing | Each step has a clear input and output, so it can be tested on its own | The path varies from run to run, so you test outcomes across many cases |
| Predictability | The same input takes the same path | The same input can take different paths on different days |
| Cost and speed | A known number of model calls | A variable number of calls, bounded only by the limits you set |
| Debugging | Open the step that failed | Replay the whole trace to see where the reasoning went wrong |
| Worst case | The worst thing one step can do | The worst thing any tool can do, in any order |
None of this is a reason to avoid agents. It's a reason to buy autonomy deliberately, and to know what you're paying.
Four questions to ask
- Is the path known in advance? If you can write the steps on a whiteboard, write them in code. A model can still handle the fuzzy parts inside it.
- Does each step depend on what the last one found? If the next action genuinely depends on discoveries along the way, such as investigating a failed payment, a loop starts to earn its keep.
- What does a wrong action cost? A badly drafted email is cheap to fix. A wrong refund is not. The higher the cost, the more you want a fixed path and explicit approvals.
- How often will it run, and how fast must it be? Every extra model call adds latency and cost. A workflow with one model call costs a fraction of a loop that makes many.
An example: matching invoices to payments
Imagine a finance team matching bank payments to open invoices. Most matches are exact: same amount, same reference. A script handles those. Some are fuzzy: a customer paid two invoices in one transfer, or mistyped the reference. That's where a model helps.
The right design is a workflow. The script makes the exact matches, a model step proposes matches for the leftovers, and a person approves anything above a set amount. No loop is needed, and every part can be tested on its own.
A second example: triaging support tickets
Support triage looks like an obvious agent. Break it down and most of it is a workflow.
- Classify the ticket. A router: one model call that picks billing, bug, how-to, or other.
- Fetch context. Plain code: look up the customer and the order, and search the help center.
- Draft a reply. One model call, grounded in what the previous step found, with sources cited.
- Check the draft. Fixed rules: no promises outside policy, no personal data where it doesn't belong.
- Act. Send the reply, or ask a person to approve it first if money or an exception is involved.
Five steps, two model calls, and no loop. When the system does something odd, you know which step to open.
Common mistakes
- Starting with a multi-agent framework. It adds moving parts before you've shown that one agent can't do the job.
- Letting the model decide what the code already knows. If only one tool can be right at this step, call it.
- Giving broad tools to a loop. A tool that can do anything makes every run a risk. Narrow tools are what make loops safe.
- Skipping the baseline. Without a simple version to compare against, you can't tell whether the agent is better, only that it's more impressive.
Add autonomy where the evals say you must
A useful discipline: build the simplest version first, write evals that capture the cases it gets wrong, and add autonomy only where those failures justify it. Each step toward more autonomy should be a decision backed by a measured gap, not a default.
- Start with a workflow and a model step for the fuzzy part.
- Measure it on real past cases.
- If a group of cases fails because the path varies, let the model choose among a few fixed paths.
- Only if that still falls short, give the model tools and a loop, with limits on steps, time, and spend.
Where to go next
In a discovery conversation we map the workflow, mark which steps are fixed and which need judgment, and choose the lowest point on the spectrum that does the job. The agent blueprint tool runs a lightweight version of that exercise in a couple of minutes, and Write the evals first covers how to measure what you build.
