The industry is building agents even for deterministic workflows and that’s a mistake. It feels a lot like the dot-com era, when everyone rushed to establish an online presence without questioning why, and we all know how that turned out.
There is a meeting happening right now, in some conference room or some Zoom grid, where a perfectly reasonable process (the one with simple decision point, a lookup table, and a decade of stable behavior) is about to be rebuilt as an “agentic” system. Someone said the word agentic out loud, and the room nodded, because nodding at agentic is what rooms do in 2026. Nobody asked the question that truly mattered, which is whether the process needed an agent, or AI, or anything more sophisticated than the if statement that has been quietly doing the job since before the term “agentic” existed.
Don’t get me wrong. I’m a fan of AI agents when the use case actually fits. But before racing up the autonomy ladder, the real question is whether AI should be involved in the process at all. And if the answer is yes, then how much? And, how independently? More often than current hype suggests, the honest answer is “less than you think.” And sometimes, the answer people are even less willing to admit is: “none.”
AI agents have become the new default tool; like a hammer in search of nails (see Abraham Maslow’s the Law of Instrument). The problem is, not everything is a nail, and this isn’t a tool suited for every job.
The Reflex
Let’s name the pattern, because the pattern is the useful part. A genuinely capable technology arrives. It does something that, in a demo, looks like magic. The demo is real. The capability is real. And then a specific cognitive shortcut kicks in: because the technology is impressive in the cases where it fits, it gets treated as the default answer in the cases where it doesn’t.
Take a look at my tutorial where I wrote an AI investigate a bug. This capability could easily be extended to writes a patch and opens a PR; all on its own.
I quoted Maslow in my post on why it’s a good time to be a generalist, and he keeps earning his keep. The specialist with a hammer doesn’t ignore the screw – he misidentifies it as a nail. The team that has just mastered agent orchestration doesn’t ignore the deterministic process. They misidentify it as a reasoning problem.
There’s also a less flattering driver, and I’d be dishonest to leave it out. “We built an agent” is a fantastic line on a slide. It’s a fantastic line in a performance review. It sounds like innovation, it photographs well at the all-hands, and it is trivially countable in a way that “we chose not to over-engineer this” never will be. That is Goodhart’s Law wearing a trench coat. The thing being optimized is looks innovative, not solves the problem, and the two are not the same thing – they have never been the same thing.
The Train on Rails
Here is the analogy I want you to keep in your head for the rest of this post. A deterministic process is a train on rails. The entire value of rails is that the vehicle cannot make choices. It goes where the track goes, every single time, predictably, cheaply, and in a way you can audit by simply looking at the map. There is no question, after the fact, about why the train went to Newark instead of Trenton. The track went to Newark. An agent is a driver with opinions. Autonomy is the whole pitch. The driver looks at the situation, reasons about it, and decides what to do. That is a superpower when the route is genuinely unknown, when the roads change, when there is no track. It is an act of self-sabotage when there is a track.
Put a driver-with-opinions on a train, and you have taken on every downside of autonomy. The train can now, in principle, leave the rails – while buying exactly none of the upside, because the rails were the point. You are paying for the possibility of improvisation in a context where improvisation can only hurt you. Sometimes the driver does the right thing. Sometimes the driver, reasoning beautifully and confidently, salts the dish that called for sugar. And when you ask why, you don’t get an answer. You get a probability distribution.
An agent applied to a deterministic process converts a property you wanted (i.e., predictability) into a liability you now have to manage.
The Risk Inventory
Let me be specific about what you’re actually buying when you wrap an agent around a process that didn’t need one. I’ll frame each as the deterministic version versus the agentic version, because the contrast is where the cost lives.
- Non-determinism, by choice. A deterministic function returns the same output for the same input, forever. An agent does not guarantee that – it reasons, and reasoning is path-dependent and probabilistic. For an open-ended task, this variability is a feature. For a process that is supposed to do the same thing every time, you have paid real money to introduce a regression and then called it innovation.
- Auditability collapse. When a deterministic process makes a decision, the decision is in the code. You can point a regulator or an auditor at the exact line. When an agent makes a decision, the explanation is a reasoning trace that may differ on the next run. If the phrase “SOX compliance” appears anywhere near your process, an agent will give you the kind of heartburn I warned about in the agents tutorial – except now it’s not a hypothetical, it’s an audit finding.
- Cost that scales with traffic instead of value. A deterministic function costs essentially the same whether you call it ten times or ten million times. An agent reasons – and meters – at every step. I already told the story in Goodhart’s Law: Uber burned through its annual budget for certain AI coding tools by April; Microsoft cancelled Claude Code licenses across an entire division citing cost. Those weren’t philosophical objections. They were invoices. When you put an autonomous reasoner on a high-volume deterministic path, you are paying grandmaster rates to sort the mail, and the bill arrives monthly.
- Latency. A deterministic step that resolved in fifty milliseconds becomes a multi-second loop of round trips to a model, with the occasional timeout for variety. Your users notice. Your SLA notices. Your pager notices.
- Error compounding, quietly. A workflow fails loudly, at a known step, with a stack trace. An agent fails by doing something plausible but wrong, then “recovering” creatively in a direction nobody anticipated, and the failure surfaces three steps downstream looking like something else entirely. Non-stationary failure modes are a special gift to whoever is on call at 3 a.m.
- A wider attack surface. This is the one teams underweight the most, so I’ll dwell on it. A deterministic parser cannot be socially engineered. It has no opinions to manipulate. The moment you replace it with an agent that ingests untrusted input through a language model and has tools it can call, you have created a system that can be talked into things. Prompt injection is not a theoretical curiosity; it is the natural consequence of giving a probabilistic, persuadable system autonomy over a process that used to be a closed, deterministic function. You didn’t just add intelligence. You added a manipulable surface where there wasn’t one.
- You no longer own your own behavior. A deterministic process is stable until you change it. An agentic process can change behavior because a vendor shipped a new model on a Tuesday. The system that passed all its tests last quarter can quietly start making different decisions this quarter, and you will find out from production, not from your commit history. Outsourcing your cognition is also outsourcing your stability.
None of these are arguments that agents are bad. They are arguments that autonomy is a cost, and you should only pay it when you’re buying something with it.
The Framework: an Autonomy Ladder
Before you ask “which AI architecture,” ask “how far up the autonomy ladder does this problem actually require me to climb?” Then, climb the fewest rungs that solve it, not the most that impress people.
| Rung | What It Is | When It’s Right |
|---|---|---|
| 0 – No AI | Plain code. A regex, a state machine, a lookup table, four if statements. | The rules are knowable and stable. You can draw the flowchart. |
| 1 – Code + One AI Call | Mostly deterministic flow with a single narrow model call: classify this, extract that. | One step needs judgment a rule can’t capture; everything around it is fixed. |
| 2 – Workflow | A predefined sequence of steps, some AI-powered, where you decide what happens next. | You know the steps before you start. The AI colors within the lines you drew. |
| 3 – Agent | An autonomous reasoner that decides its own path. | The path is genuinely unknown at runtime. Figuring out what to do is part of the work. |
The default is the lowest rung. The burden of proof is on every step up, not on staying put. Each rung you climb trades away determinism, auditability, speed, and cost-stability in exchange for adaptability. If you don’t need the adaptability, you are simply selling those four things for nothing.
A short litmus test, lifted and elevated from the four questions in the agents post:
- Can you draw the flowchart? If you can cover 95% of cases on a whiteboard, you don’t need an agent. You may not need AI at all.
- Must the same input produce the same output? If yes, an autonomous reasoner is the wrong tool by definition.
- Will anyone ever ask “why did it do that”? If an auditor or a regulator might, you need reproducibility, and reproducibility is the first thing autonomy spends.
- Is cost-per-run × volume a number you’d put on a slide proudly? Do the token math before, not after.
- Is there genuine novelty at runtime – or just the appearance of it? Agents earn their cost on real open-endedness, not on processes that merely feel sophisticated because we dressed them up.
If the answers point down the ladder, go down the ladder. The cleverness is in building the smallest thing that works, not the most autonomous thing you can justify in a roadmap review.
Agents Are Not the Problem
I want to be as fair to agents as I tried to be to each hype cycle in Déjà vu, because the easy misreading of this post is “agents bad,” and that is not the lesson.
The F-150 has been the best-selling vehicle in America for decades, and it is a genuinely excellent truck – for hauling, for towing, for terrain that would destroy a sedan. It is also an absurd choice for a twenty-minute urban commute. The truck isn’t wrong. The match is wrong. Agents are the same. When the path is genuinely unknown, when the task demands multi-step reasoning with tool use, when you can tolerate some non-determinism in exchange for handling cases you couldn’t enumerate upfront – an agent is not just acceptable, it’s the right call, and I’ll happily help you build one.
The problem is never that agents exist. The problem is the reflex that reaches for the most autonomous, most impressive-sounding option before anyone has checked whether the problem has a track running through it. The most innovative-sounding option is not the same as the most appropriate one. It is exactly the same mistake as treating “most downloaded” as “best for your use case” – same disease, new decade, bigger invoice.
The best technical decisions still start with questions, not answers. The question here is the cheapest one in the building, and almost nobody asks it: does this process have rails? Because if it does, the last thing you want is a driver with opinions.
Build the agent when, like in Doc Brown from Back to the Future, where there are no roads…
When you’re standing on a track, build the train.
Somewhere along the way, we’ve drifted from the KISS principle: “Keep it simple, stupid.” It’s a mindset coined by Kelly Johnson, a lead engineer, at the Lockheed Skunk Works. Following this principal, the simplest solution is restraint – not everything needs an agent.
