There is a pattern I keep seeing in AI product development. A team has a workflow that already works. The steps are known. The inputs are defined. The possible states are understood. The failure cases can be handled.
Then someone asks: “Can we make this agentic?”
And suddenly a deterministic workflow becomes: LLM → Agent → Tools → Execution
The system is now technically more “AI-powered.” But is it actually better? I'm not convinced. I think we're increasingly using AI agents for problems that never required an agent in the first place.
Some Problems Already Have an Answer
Consider a subscription upgrade. The workflow is straightforward:
Validate subscription
↓
Charge payment
↓
Update plan
↓
Send confirmation
There isn't much ambiguity here. If the payment succeeds, update the plan. If the payment fails, don't update the plan. If the subscription is invalid, reject the request. If the plan changes successfully, send the confirmation. You can represent this using normal application architecture: if/else → workflow → queue → state machine → API
The behavior is predictable. The states are explicit. The transitions can be tested. The failure cases can be defined. The system can be monitored with conventional metrics. There is no reasoning problem that requires an LLM. Now imagine putting an agent in the middle:
User → LLM → Agent → Tools → Payment API → Database → Email
The system now has another component deciding what should happen next. For a deterministic workflow, that doesn't necessarily add intelligence. It adds uncertainty.
Deterministic Problems Should Usually Stay Deterministic
If the system already knows the correct sequence of operations, I want that sequence represented explicitly in code. A state machine might define:
PENDING
↓
VALIDATED
↓
PAYMENT_PROCESSING
↓
PAYMENT_CONFIRMED
↓
PLAN_UPDATED
↓
COMPLETED
Each transition can have explicit conditions. If something fails during payment, the system knows where it is. If the worker crashes after payment but before the plan update, the system can recover from a known state. If the confirmation email fails, the email operation can be retried independently.
This is boring software engineering. And that's a compliment. Boring systems are often easier to operate. You know what they're going to do. You know what they can do. You know what they cannot do.
And when something breaks at 2 a.m., you can follow the state transitions without wondering what the model decided to do.
What Does an Agent Actually Add?
Agents become interesting when the system doesn't know the exact path ahead of time.
Consider a customer asking: “My account keeps getting charged every month. I cancelled the subscription weeks ago. Can you figure out what's happening?”
That's not a simple workflow. The system may need to:
- inspect the customer's account
- look at subscription history
- inspect invoices
- compare transaction dates
- check cancellation events
- determine whether another subscription exists
- inspect relevant policies
- potentially ask the user for additional information
- decide what action should happen next
The path depends on what the system discovers. Maybe there is an active subscription. Maybe the cancellation happened after the latest billing cycle. Maybe there are two accounts. Maybe the payment belongs to a different product. Maybe the transaction is actually a temporary authorization.
The system can't necessarily know the correct sequence beforehand. That's where an agent can provide real value.
The agent can reason about the current state, select the next useful action, inspect the result, and decide what information is needed next. That's fundamentally different from executing a predefined workflow.
Unknown Paths Are Where Agents Become Useful
The distinction I use is fairly simple:
Known path → deterministic software.
Unknown path → consider an agent.
An agent is valuable when the system has to make decisions based on information it discovers during execution. A deterministic workflow is valuable when the system already knows the correct sequence. This distinction can prevent a lot of unnecessary complexity.
Suppose your onboarding process is always: Create account → verify email → create workspace → assign default permissions → send welcome email.
That doesn't need an agent. Build a workflow. Now imagine the product receives: “Help me configure my workspace for our engineering team.”
There may be several possible configurations depending on team size, existing tools, security requirements, integrations, and user preferences.
The system may need to ask questions, inspect available resources, compare options, and decide what to do next. That's a much more reasonable candidate for agentic behavior. The difference isn't whether AI can perform the workflow. It can. The question is whether reasoning is actually required to determine the workflow.
Agents Introduce a New Class of Failure
Once an LLM is responsible for deciding what happens next, you inherit a different set of engineering problems. The model can choose the wrong tool. It can generate incorrect arguments. It can call tools in an inefficient order. It can retry unnecessarily. It can misunderstand the current state. It can fail to recognize that an operation has already completed. It can produce an action that wasn't intended.
Now you need additional infrastructure around that behavior. You need model monitoring. You need tool-call observability. You need evaluation datasets. You need guardrails. You need permission boundaries. You need retry strategies. You need state management. You need to think about prompt injection. You need to test behavior across different model outputs. You need recovery mechanisms for partially completed operations.
None of these are inherently bad. They're simply costs. And those costs make sense when you're getting something valuable in return: the ability to navigate an uncertain problem. They make much less sense when the workflow was deterministic from the beginning.
Don't Use an Agent to Hide Bad Architecture
There's another reason I'm cautious about agent-first design. Sometimes an agent is introduced because the underlying workflow is difficult to model.
Instead of understanding the system and defining its states and transitions, we give an LLM access to several APIs and ask it to figure things out.
That can feel faster during prototyping. But you've effectively moved architecture into probabilistic behavior. A traditional workflow might explicitly say:
Validate
→ Charge
→ Update
→ Notify
An agent might be told: “Use the available tools to complete the subscription upgrade.” Now the sequence isn't fully encoded in the application. It's partly encoded in model behavior. That makes the system harder to reason about. If the process is business-critical, that's a trade-off worth taking seriously.
Use AI Where Uncertainty Exists
This doesn't mean agents are unnecessary. Quite the opposite. There are problems where deterministic logic becomes awkward because the input is unstructured and the path depends on interpretation.
Investigation is a good example. Research is another. Troubleshooting can be another. Planning tasks, information synthesis, multi-step analysis, and workflows that dynamically change based on discovered information can all benefit from agentic systems.
The important question isn't: “Can an agent do this?” Almost certainly, it can. The better question is: “Does this problem actually require autonomous reasoning?” If the answer is no, an agent may be unnecessary complexity.
Start With the Simplest Architecture
When designing an AI feature, I would start with the boring solution. Can an API handle it? If not, can a workflow handle it? If the workflow has explicit states, can a state machine handle it? If work needs to happen asynchronously, can a queue and workers handle it?
Only when the system genuinely needs dynamic decision-making would I introduce an agent. That progression might look like: API → Workflow → Queue → State Machine → Agent
Not every problem needs to reach the last step. In fact, most shouldn't. An agent should be an architectural choice based on the problem, not a default implementation pattern because the product happens to use AI.
The Goal Isn't to Make Everything Agentic
AI agents are powerful precisely because they can operate when the path isn't completely known. But that doesn't mean every product workflow should become agentic. If a process is predictable, encode it. If its states are known, model them. If its transitions are deterministic, make them explicit. If the system needs to reason about what to do next based on information it discovers, then consider an agent.
The simplest distinction is still the one I find most useful:
Known path → deterministic software.
Unknown path → consider an agent.
The goal isn't to maximize the amount of autonomy in a product. It's to use the right level of autonomy for the problem. Sometimes the smartest thing an AI engineer can do is not use an AI agent at all.
Top comments (0)