Agents vs. No Agents: Why Boring AI Still Wins
Every AI vendor conversation right now eventually uses the word "agentic." It's become shorthand for sophisticated, for cutting-edge, for the thing you should be building instead of whatever you're building now. Most of the time it's the wrong recommendation, and it's worth being precise about why, because the imprecision costs real money in production.
What "agentic" actually means
Strip the marketing off the word and it describes one specific property: autonomy over the steps. A fixed pipeline knows its steps in advance. Extract the fields, classify the result, format the output, done. The sequence is decided at build time, by you, and the system just executes it.
An agent decides its steps at run time. Given a goal, it chooses what to do next, whether to call a tool, whether the result was good enough, whether to try again or try something else. The steps aren't fixed in the code; they're generated by the model as it goes, in response to what it just observed.
That's the whole distinction. Not "uses AI" versus "doesn't use AI." Not "smart" versus "simple." Fixed sequence versus self-determined sequence. Everything else people mean when they say agentic (tool use, memory, multi-step reasoning) is downstream of that one property, not separate from it.
The tradeoff nobody puts in the pitch deck
Autonomy over steps buys flexibility. It also spends predictability, and the spending is structural, not incidental.
A fixed pipeline's cost is knowable before you run it. Three LLM calls cost three LLM calls, every time, for every input. An agent's cost is a function of how many steps it decides to take, and that number isn't known until it's done deciding. It might solve a problem in two steps. It might loop, retry, second-guess itself, and take twelve, with context growing at every step, which means each subsequent call is also more expensive than the last. You're not paying for an answer. You're paying for however much wandering it took to find one, and the wandering is exactly the part you can't estimate in advance.
This is not a criticism of agents. It's the actual price of the actual thing they're for. The question worth asking isn't whether an agent is more capable, it usually is, for the right problem. It's whether you're buying capability you need or capability you're paying for by default. Microsoft's own ecosystem draws this same line: the stay, extend, or build decision is the same single-call-versus-orchestration tradeoff, just wearing a Copilot Studio license instead of a line of code.
When the price is worth it
Agents earn their cost when the path to the answer genuinely isn't knowable in advance, and the only way to find it is to try something, look at what happened, and adjust.
Debugging a failing test is the clean example. You can't write the fixed sequence of steps that fixes an arbitrary bug, because the sequence depends entirely on what the bug turns out to be. Read the error, form a hypothesis, check a file, revise the hypothesis, try a fix, see if it worked. Each step depends on the result of the last one. That's not a pipeline with extra steps. It's a genuinely different shape of problem, and an agent's ability to decide its next move based on what it just learned is the actual feature you're buying.
Open-ended research behaves the same way. Multi-step investigation where the second question depends on the answer to the first, tool selection that depends on what the first tool returned, anything where you'd genuinely struggle to write the steps down beforehand because you don't know them yet. If you find yourself trying to enumerate the fixed sequence and failing, that failure is the signal. It's telling you the problem is agent-shaped.
When it's just an expensive way to do something simple
Most production AI is not this. It's a short list of jobs with a knowable, fixed shape, and if you want five of them worked out in detail, I've written up real examples separately:
- Classify this ticket
- Extract these fields from this document
- Summarize this thread
- Translate this paragraph
- Answer this question from these documents
Every one of these: input arrives, one model call (occasionally two or three in a fixed sequence) transforms it, output leaves. You could write the steps on an index card before you've seen a single example, because the steps don't depend on the content, only the task does.
Wrapping that in an agent doesn't make it more capable. It makes it slower, harder to debug (a failure could be anywhere in a self-determined chain of unknown length instead of one of three known calls), and expensive in a way that scales with nothing you actually value. I build AI features behind a specific seam for exactly this reason: client calls a function, the function makes one call to the model, shapes the response, returns it. That's the whole feature, for the overwhelming majority of features worth shipping. The single call is cheaper, it's reliable in the boring way that lets you sleep, and when it breaks you know exactly where to look.
Why you keep hearing the opposite
Agentic AI gets the coverage because it's the better story. It's the bigger vision, the more fundable pitch, the demo that makes people lean forward. "It figured out the fix on its own" is a sentence people repeat at dinner. "We replaced a manual extraction step with one API call" is not, even though the second sentence is where most of the actual, deployed, load-bearing AI in production lives right now.
That gap between coverage and deployment isn't a conspiracy, it's just what gets attention. Novelty is a better story than reliability, always, in every domain, and AI isn't an exception. The practical cost is that founders and product leads calibrate their expectations against the coverage instead of against the deployment reality, and end up reaching for agents on problems that never needed one.
The actual decision
Two questions, and they resolve almost every case.
Can you write down the steps in advance, before you've seen the specific input? If yes, you don't want an agent. Build the fixed pipeline, or the single call. It'll be cheaper, faster, and easier to debug, and it will do the job just as well, because the job was never the hard part.
Do you need to hand over a goal and let something investigate, try, observe, and self-correct until it's actually done? If yes, and only if the problem genuinely has that shape, the agent's cost is worth paying, because the flexibility is the thing you came for.
Everything else is a demo, not a deployment.
This is the architecture I build for clients: the single call where a single call does the job, and the agent only where the problem actually earns one. If you're not sure which side of that line your problem sits on, get in touch.
Rosemarie Withee has spent thirteen years helping operations teams get real work out of their software, first Microsoft 365, now AI. She’s written six books for Wiley and builds AI products at Portal Integrators.