We get a version of this question on almost every discovery call. Should this be an AI agent, or a workflow? The honest answer is that most teams confuse the two, and the wrong choice quietly burns the budget. Here is how we tell them apart, and the test we run before committing to either.
The line we draw
- A workflow is a sequence of steps where the path is known in advance. Even if a step uses an LLM, the orchestration is deterministic. Same inputs in, same outputs out, same way every time.
- An agent decides the path itself. It picks tools, plans sub-steps, and adapts to what it finds. You give it a goal and a sandbox, not a flowchart.
If you can sketch the happy path on a napkin, it is a workflow. If the napkin needs a decision tree with three branches, it is still probably a workflow. Reach for an agent when the branches are unbounded.
Why it matters
Agents are powerful but expensive. Expensive in tokens, expensive in latency, and expensive in debugging time. Every autonomous decision is a potential failure mode you have to monitor. Workflows are boring, fast, and cheap to operate. Boring is a feature.
- Workflows win when you need predictability, auditability, and cost ceilings. Most B2B back-office work lives here.
- Agents win when the input space is genuinely open-ended. Research, triage with novel categories, multi-system reasoning where you cannot enumerate the cases.
The 10-test test
Before we commit to an agent, we make the team write the first 10 test cases by hand. If those test cases all funnel through the same 3 to 4 steps with minor variations, we ship a workflow with an LLM inside it. Not an agent around it.
The result is usually 10x cheaper to run, ships in half the time, and is debuggable by humans without printing a 4,000-line trace.
A real example
On a recent build for a legal services client, the original brief asked for a “research agent.” After mapping the actual decisions, we shipped a workflow with three LLM calls and one fallback path.
- Workflow version: 4 seconds per task, $0.02 per task, 100% reproducible.
- Agent version (prototyped first): 90 seconds per task, $1.40 per task, occasionally surprising in ways the client did not want.
- Quality difference: none that mattered. The workflow gave the same answers, faster and cheaper.
5 questions to ask before you build
- Can you list 10 example inputs? If yes, look at them. If they cluster, build a workflow.
- Can a junior teammate describe the steps in plain English? If yes, those steps are your workflow.
- What happens when something goes wrong? Workflows fail predictably. Agents fail creatively. Pick the failure mode you can support.
- Who pays the token bill? Agents at scale can be 50 to 100 times more expensive per task. Make sure that math works before you commit.
- Does the user need to understand the answer? Workflow outputs are easy to explain. Agent traces are not. If explainability matters, default to workflow.
The lesson that keeps repeating
Start with the workflow. Reach for an agent only when the workflow visibly buckles. The teams that follow this rule ship faster, cheaper, and with fewer 2 a.m. incidents. The teams that start with the agent because it sounds more impressive end up rebuilding it as a workflow six months later, just with a year of tech debt to clean up first.
Boring works. Boring ships. Use the agent only when boring stops working.
