When to use a workflow and when to use an agent.
"Agent" is the word everyone wants to put on their project right now. But plenty of tasks that get built as agents would be faster, cheaper, and more reliable as simple workflows. Here's a decision framework that helps you pick the right tool — before you build the wrong one.
The first question we ask in every client engagement is: does this task actually need an agent, or would a workflow do the job? It's a disqualifying question — not because agents are bad, but because workflows are often better, and building the more complex thing when the simpler thing works is a pattern that costs teams money and creates maintenance burden.
Here's how to think through the choice clearly.
The core distinction: rules vs. judgment
A workflow is a deterministic system. Given the same input, it always produces the same output, following a predefined sequence of steps. You can read the code and predict exactly what will happen. That predictability is valuable — it makes workflows fast, cheap, auditable, and easy to debug.
An agent is a non-deterministic system. It uses a language model to make decisions at runtime — which tool to call, how to interpret ambiguous input, what to do when the situation doesn't match the expected pattern. That flexibility is valuable when you need it. It also adds cost, latency, and unpredictability.
The question is: does your task require judgment, or does it require execution?
The five questions to ask about your task
1. Can you write the complete decision logic as an if-then-else tree?
If yes — if you can enumerate the conditions, the branches, and the outputs — that's a workflow. If you find yourself adding "but there's also the case where..." without end, the task has genuine ambiguity that a workflow can't handle cleanly.
2. Does the task involve reading and interpreting natural language?
Any task that requires understanding what someone means — not just pattern-matching on keywords — typically needs a language model. Routing an email based on its subject line can be a workflow. Routing an email based on what the sender is actually trying to accomplish usually needs an agent.
3. Is there a significant tail of edge cases?
Workflows are excellent at the 80–90% of cases that follow the rules. But if you have a long tail of exceptions that each require slightly different handling, the workflow grows unwieldy — a spaghetti of conditional branches that nobody wants to maintain. If the exceptions require judgment to handle correctly, that's where an agent adds value.
4. How much does an error cost?
Workflows fail in known, bounded ways. An agent can fail in novel, unexpected ways. If the cost of an unexpected error is high, the predictability of a workflow is often worth more than the flexibility of an agent. This is why we're skeptical of agents controlling truly irreversible, high-stakes actions without very careful design.
5. How often do the rules change?
If the business logic changes frequently, a workflow requires code changes for each update. An agent can sometimes adapt to policy changes through prompt updates — faster and more accessible to non-engineers. This is one case where the agent's flexibility is a concrete operational advantage.
When workflows are clearly the right choice
Workflows excel at:
- Event-triggered notifications: "When deal stage changes to Proposal Sent, notify the account manager and create a follow-up task in 3 days."
- Data sync: "When a new row appears in this spreadsheet, create a contact record in the CRM."
- Scheduled reports: "Every Monday at 8am, pull last week's pipeline data and email the summary to the sales team."
- Form processing: "When intake form is submitted, create a case record, assign it to the right team based on service type, and send a confirmation email."
- Approval routing: "If invoice amount is over $10,000, route to CFO for approval. Otherwise, auto-approve."
All of these have deterministic rules. They don't require judgment. Build them as workflows.
When agents are clearly the right choice
Agents excel at:
- Document classification with nuanced criteria: understanding what a document is about, not just what format it's in.
- Open-ended customer inquiry handling: understanding what a customer is actually asking and routing or responding accordingly.
- Research and synthesis: gathering information from multiple sources and producing a coherent summary or recommendation.
- Exception handling: reviewing edge cases that a workflow flagged as not-matching-rules and deciding what to do about them.
- Personalized outreach: generating responses or follow-ups that are tailored to the specific context of a relationship, not just a template.
The hybrid pattern that's usually right
In practice, most real-world systems benefit from a hybrid: use workflows for the deterministic parts, embed an agent for the judgment steps.
Example: a lead routing system. The workflow handles the deterministic parts — receiving the lead, looking up the account in the CRM, fetching the routing rules table. The agent handles the judgment step: reading the lead's notes and form responses and classifying the lead type when it doesn't clearly match a single category. The workflow picks back up to execute the routing decision.
This architecture gives you the best of both worlds: predictable execution with intelligent judgment at the decision points that actually require it. It's also more maintainable — the workflow logic is separate from the prompt logic, and each can be updated independently.
The cost argument for getting this right
An agent call costs roughly 10–100x more than a workflow step, depending on the model and context length. If you're running a system that processes 10,000 events per day and half of those don't need an agent, you've added significant unnecessary cost. Multiply by 12 months and it's a meaningful number.
More importantly: agents have more failure surface than workflows. Every agent call is an opportunity for a confidence miscalibration, a hallucination, a format drift. For tasks that don't need judgment, you're taking on that risk for no benefit.
Build the simplest thing that works for the task. If the task genuinely needs an agent, build an agent. If a workflow covers it, build a workflow. And if you're not sure, that uncertainty is worth resolving before you start building — not after you've shipped.
If you have a task and aren't sure which shape is right for it, get in touch. It's often a 15-minute conversation.
Book a call