Not everything needs an agent. Here’s how to decide.
“Should we use an AI agent for this?”
I hear this question weekly. Teams are excited about agentic AI. They’ve seen the demos. They want to build agents for everything.
Sometimes that’s the right call. Often, it’s not.
Agents introduce complexity, cost, and unpredictability. For some problems, that tradeoff is worth it. For others, a deterministic workflow is simpler, cheaper, and more reliable.
Here’s the framework we use at Rotascale to make this decision systematically.
The Core Tradeoff
Agents excel when the problem space is ambiguous and the path to solution is unclear. They can reason, adapt, and handle novel situations.
Deterministic workflows excel when the problem is well-defined and the solution path is known. They’re predictable, auditable, and cheap.
quadrantChart
title Agent vs Workflow Decision Space
x-axis Well-Defined Problem --> Ambiguous Problem
y-axis Known Solution Path --> Unknown Solution Path
quadrant-1 "Strong Agent Case"
quadrant-2 "Consider Agent"
quadrant-3 "Deterministic Workflow"
quadrant-4 "Consider Agent"
"Document Q&A": [0.7, 0.6]
"Invoice Processing": [0.2, 0.2]
"Code Review": [0.6, 0.5]
"ETL Pipeline": [0.1, 0.1]
"Customer Support": [0.8, 0.7]
"Report Generation": [0.3, 0.3]
"Research Tasks": [0.9, 0.9]
"Form Filling": [0.15, 0.15]
The key insight: most enterprise tasks are more well-defined than they appear. The instinct to reach for agents often comes from excitement about the technology, not from genuine ambiguity in the problem.
The Decision Tree
Here’s the framework as a decision tree. Start at the top and follow the branches.
flowchart TD
START[Start] --> Q1{Is the task well-defined<br/>with clear inputs/outputs?}
Q1 -->|Yes| Q2{Is the solution path<br/>known and stable?}
Q1 -->|No| Q5{Does the task require<br/>multi-step reasoning?}
Q2 -->|Yes| Q3{Are there frequent<br/>edge cases/exceptions?}
Q2 -->|No| Q5
Q3 -->|No| DET[Use Deterministic Workflow]
Q3 -->|Yes| Q4{Can edge cases be<br/>enumerated and handled?}
Q4 -->|Yes| DET
Q4 -->|No| HYB[Use Hybrid Approach]
Q5 -->|Yes| Q6{Is latency critical<br/>sub-second required?}
Q5 -->|No| Q7{Is the task<br/>safety-critical?}
Q6 -->|Yes| HYB
Q6 -->|No| Q7
Q7 -->|Yes| Q8{Can you accept<br/>occasional failures?}
Q7 -->|No| AGT[Use Agent]
Q8 -->|Yes| AGT
Q8 -->|No| HYB
style DET fill:#dcfce7
style AGT fill:#dbeafe
style HYB fill:#fef3c7
Let’s walk through each decision point.
Decision 1: Is the task well-defined?
A well-defined task has:
- Clear inputs (you know what information you’re starting with)
- Clear outputs (you know what you need to produce)
- Clear success criteria (you know what “done” looks like)
Well-defined examples:
- Extract invoice data into structured fields
- Route support ticket to correct department
- Generate weekly report from database
Ambiguous examples:
- “Help the customer solve their problem”
- “Research competitors and summarize findings”
- “Write code to implement this feature”
If the task is well-defined, you probably don’t need an agent.
Decision 2: Is the solution path known?
A known solution path means:
- You can write down the steps to accomplish the task
- The steps are the same (or nearly the same) every time
- An engineer could implement it as traditional code
If you can flowchart the solution, you don’t need an agent to figure it out.
Decision 3: Are there frequent edge cases?
This is where it gets nuanced.
Many well-defined tasks have occasional edge cases. An invoice might be in an unusual format. A support ticket might be in a language you don’t normally see. A report might need special handling for a specific client.
The question is: how frequent are these edge cases, and can they be enumerated?
Enumerable edge cases: You can list them, write handlers for them, and maintain the handlers over time. Use deterministic workflow with explicit exception handling.
Non-enumerable edge cases: The exceptions are too varied or too novel to pre-specify. Consider a hybrid approach where an agent handles the exceptions while a workflow handles the common path.
Decision 4: Does it require multi-step reasoning?
Multi-step reasoning means the task requires:
- Breaking down a complex problem
- Making decisions that depend on intermediate results
- Adapting the approach based on what’s discovered
This is where agents shine. They can plan, execute, observe, and adjust.
But be careful: many tasks that feel like they require reasoning can actually be decomposed into a fixed workflow once you understand them well enough.
Decision 5: Is latency critical?
Agents are slow. Each reasoning step is an LLM call. Complex tasks might require dozens of calls, each with latency.
If you need sub-second response times, agents are probably not the answer - at least not for the hot path. You might use agents for background processing while serving users with faster deterministic logic.
Decision 6: Is it safety-critical?
Safety-critical tasks have consequences for failure that are unacceptable. Medical decisions. Financial transactions. Legal advice.
Agents can fail in unpredictable ways. They can hallucinate. They can misunderstand instructions. They can take actions you didn’t anticipate.
For safety-critical tasks, you need either:
- A deterministic workflow with verified correctness
- A hybrid approach with human oversight at critical points
- An agent with extensive guardrails and verification layers
The Hybrid Pattern
Notice that many paths lead to “hybrid approach.” This is often the right answer.
The hybrid pattern uses deterministic workflows for the predictable parts and agents for the parts that require flexibility.
flowchart LR
subgraph "Deterministic Layer"
I[Input Validation] --> R[Routing Logic]
R --> P[Pre-processing]
end
subgraph "Agent Layer"
A[Agent Reasoning]
end
subgraph "Deterministic Layer 2"
V[Verification] --> O[Output Formatting]
O --> D[Delivery]
end
P --> A
A --> V
style I fill:#dcfce7
style R fill:#dcfce7
style P fill:#dcfce7
style A fill:#dbeafe
style V fill:#dcfce7
style O fill:#dcfce7
style D fill:#dcfce7
Example: Customer support automation
- Deterministic: Receive ticket, classify category, extract key information
- Agent: Understand the specific issue, reason about the solution, draft response
- Deterministic: Check response against policies, format for channel, send
The agent does the part that requires understanding and reasoning. The workflow handles the parts that are routine and need to be reliable.
Cost Comparison
Let’s make this concrete with cost numbers.
For well-defined tasks like invoice processing, a deterministic workflow costs ~$0.001 per task. An agent doing the same work costs ~$0.05 - fifty times more.
At scale, this matters. A million invoice processes per month: $1,000 with workflow, $50,000 with agents.
Reliability Comparison
Cost isn’t the only factor. Reliability differs too.
| Dimension | Deterministic | Hybrid | Full Agent |
|---|---|---|---|
| Predictability | 100% - same input, same output | High for workflow parts | Variable |
| Failure modes | Known, enumerable | Mixed | Novel, surprising |
| Debugging | Straightforward | Moderate | Difficult |
| Auditability | Complete - every decision logged | Good with effort | Requires infrastructure |
| Latency | Milliseconds | Seconds | Seconds to minutes |
For regulated industries - financial services, healthcare, insurance - the auditability and predictability of deterministic workflows often outweighs the flexibility of agents.
Common Mistakes
Mistake 1: Agent for everything
“Agents are more powerful, so we should use them by default.”
Agents are more flexible, not more powerful. For well-defined tasks, a deterministic workflow is more powerful - it’s faster, cheaper, and more reliable.
Mistake 2: Workflow for everything
“We can’t trust AI, so we’ll only use traditional automation.”
This leaves value on the table. Tasks that genuinely require reasoning and adaptation are better served by agents, even with their limitations.
Mistake 3: Binary thinking
“It’s either an agent or a workflow.”
Most real systems are hybrid. Use workflows where you can, agents where you must, and combine them thoughtfully.
Mistake 4: Ignoring compliance
“We’ll figure out auditability later.”
For regulated industries, the architecture decision has compliance implications. Agents require more infrastructure for explainability and audit trails. If you don’t build that infrastructure, you may not be able to use agents at all.
The Practical Checklist
Before building anything, answer these questions:
Task Definition
☐ Can I fully specify the inputs?
☐ Can I fully specify the outputs?
☐ Can I define success criteria?
Solution Path
☐ Can I write down the steps?
☐ Are the steps the same each time?
☐ Could an engineer implement this without AI?
Edge Cases
☐ What are the known edge cases?
☐ Can I enumerate them?
☐ What's the frequency of novel situations?
Constraints
☐ What's the latency requirement?
☐ What's the cost budget?
☐ What are the compliance requirements?
☐ What's the acceptable failure rate?
Decision
☐ Mostly "yes" on task/solution/edge cases + tight constraints → Deterministic
☐ Mostly "no" on task/solution/edge cases + flexible constraints → Agent
☐ Mixed → Hybrid
The Bottom Line
Agents are powerful tools for ambiguous, reasoning-heavy tasks. They’re expensive, slow, and unpredictable tools for well-defined tasks.
The right architecture matches the approach to the problem:
- Deterministic workflows for well-defined, high-volume, latency-sensitive, compliance-heavy tasks
- Agents for ambiguous, reasoning-heavy, low-volume tasks where flexibility matters more than predictability
- Hybrid approaches for most real-world systems that have both types of work
Don’t let excitement about agents drive you to over-engineer problems that have simpler solutions.
Not everything needs an agent. Use the right tool for the job.
Need help architecting your AI systems? We help enterprises choose the right approach - agents, workflows, or hybrid - based on their actual requirements. Let’s talk.