AI ENGINEERING / AI AGENTS
AI Agents vs Traditional Automation
Where an agent adds value—and where a deterministic workflow wins.
Key Insight: The question isn't "should we use an AI agent." It's "how well-defined is this task." That single question predicts, more reliably than anything else, whether an agent or a deterministic workflow is the right architecture.
AI agents are being reached for as a default answer to automation problems, the way microservices and, before that, "just add more servers" were reached for as defaults in earlier cycles. Some of those problems genuinely benefit from an agent's flexibility. Most of them are better served, more cheaply and more reliably, by a deterministic workflow that happens to call an LLM for one well-scoped step.
What a deterministic workflow does well
If the steps of a process are known in advance, and the branching logic can be enumerated, a workflow — a fixed sequence of steps, possibly with conditional branches, possibly calling an LLM for a specific sub-task like classification or summarization — is faster to build, cheaper to run, and dramatically easier to test and debug. You can write unit tests for it. You can reason about every path it can take. When it produces the wrong output, you can trace exactly which step did it.
Most "automate this business process" requests are, on inspection, this kind of problem: extract data from a document, validate it against known rules, route it based on known criteria, notify someone. None of that needs an agent deciding what to do next — it needs a workflow, with an LLM doing the one step (extraction, maybe classification) that genuinely benefits from language understanding.
What an agent actually adds
An agent earns its complexity when the path to the goal genuinely can't be enumerated in advance — when the right sequence of actions depends on what's discovered along the way, and hard-coding every possible branch would be impractical. Research tasks, exploratory debugging, open-ended customer support where the resolution path depends entirely on what the customer describes — these are legitimate agent territory, because the alternative is trying to anticipate every possible situation in a rigid workflow, which doesn't scale.
The trade you're making is real: you gain flexibility and lose predictability. An agent might take a different, sometimes worse, path than you'd have hardcoded, and debugging "why did it do that" is a fundamentally harder problem than debugging a workflow, because the reasoning happened inside the model, not in code you can step through.
The honest evaluation question
Before building an agent, it's worth writing down the actual set of situations the system needs to handle. If that list is short and stable, you don't have an agent problem — you have a workflow with one or two LLM-powered steps, and you should build the simpler thing. If the list is genuinely open-ended and growing, or if "situations we didn't anticipate" is a real and recurring category, that's a legitimate signal for an agent.
I've seen teams build agent architectures for problems with eight known cases. I've also seen teams try to force genuinely open-ended support workflows into a rigid decision tree that grew a new branch every week and never stopped growing. Both are the same mistake in opposite directions — solving a task with a tool shaped for a different kind of problem.
Cost and reliability aren't symmetric
An agent making multiple LLM calls per task, sometimes with tool use and retries, costs more and is slower than a workflow that calls an LLM once for a narrow task. That's a fine trade when the flexibility is genuinely needed. It's an expensive way to solve a problem that a deterministic system could have handled for a fraction of the cost, with better latency and more predictable behavior.
Key takeaways
Start from how well-defined the task actually is, not from which architecture is more interesting to build. Deterministic workflows with a narrow, well-scoped LLM step handle most "automate this" requests better than a full agent. Reserve agents for genuinely open-ended problems where the path can't be enumerated in advance. Be honest about the cost and reliability trade you're making either way — the flexible tool and the predictable tool are both correct, for different problems.