When to Use AI Agents (and When a Plain Script Beats Them)

In 2025, I watched a $40,000 automation project fail because we built an autonomous agent for work a 30-line Python script could have done. The question of when to use AI agents isn't a whiteboard exercise. It is the difference between a system that ships and one that quietly dies in staging, exactly like the pilots I wrote about in my guide to getting AI agents to production. Here is the decision framework I use now, after building agents on CrewAI, LangGraph, and my own Hermes runtime for two years.

The Workflow-vs-Agent Line (When to Use AI Agents Starts Here)

Most teams skip this step. They hear "agents" and start wiring up a planner, a memory store, and a tool-calling loop before they have written down what the task actually is. Anthropic's engineering team calls this out directly in their "Building effective agents" guide: find the simplest solution possible, and only add complexity when you need it. Their exact words are blunt. "This might mean not building agentic systems at all."

That line changed how I scope projects. Anthropic draws a clean line that most vendors blur on purpose. A workflow is when LLMs and tools are orchestrated through code paths you wrote: a fixed sequence, a known branch, a retry you control. An agent is when the model decides the path at runtime. It picks the tools, the order, and when to stop.

The trap is that agents feel more impressive. They are also the option that trades latency and cost for a chance at better performance, and you only find out later whether the trade was worth it. If the path is knowable in advance, you do not have an agent problem. You have a scripting problem wearing an agent costume.

When to Use AI Agents: Three Questions I Ask Before Writing a Line of Code

Before I reach for an agent runtime, three questions decide it. If I cannot answer yes to at least one, I build a workflow or a script instead.

One: does the path change based on the input? If every request follows the same steps, an agent is decoration. A support ticket router that always does "classify, then tag, then assign" is a workflow. A researcher that has to decide whether to read three sources or thirty based on what it finds is an agent.

Two: is the failure recoverable without a human in the loop? Agents take actions. If a wrong action costs real money or writes to a production database, you need guardrails that are easier to express as explicit code than as prompt instructions. That is a workflow with a human checkpoint, not an autonomous loop.

Three: does the task need judgment that a fixed rule cannot capture? Summarizing a contract, triaging an ambiguous bug report, planning a multi-step migration where the next step depends on what broke. These are agent-shaped. "Sort these by date" is not.

I learned question two the expensive way. A client wanted an agent to reconcile invoices. I built the autonomous version first. On day three it "reconciled" a vendor by marking twelve legitimate charges as duplicates because the prompt said "minimize open items." The script that replaced it did the same job in 40 lines and never once decided to delete something on its own.

I now make cost-per-run a gate in the proposal itself. Before an agent gets approved, I write down what the same task costs as a script and what it costs as a model loop, and if the loop is more than 5x the price and a user would never notice the difference, the script wins. That single rule killed three "agent" projects last quarter before anyone wrote a line of framework code.

The Honest Part

Agents are not free. The marketing says "set it and forget it." The reality I have lived is three costs nobody puts on the demo slide.

Latency. An autonomous loop that calls a model four or five times to do what a function does in milliseconds will make a user-facing feature feel broken. I killed an agent that added 11 seconds to a checkout step. Customers do not wait 11 seconds.

Cost. Every agent step is a model call you pay for, often with retrieval and tool calls stacked on top. The invoice reconciler cost about $0.04 per run. At 9,000 runs a month that is $360, which sounds fine until you realize the script version costs $0 a month and runs faster.

Reliability. The more the model decides, the less you can predict. A workflow fails the same way every time, so you fix it once. An agent fails in a new way each Tuesday. My context engineering guide covers how much of that variance comes from context, not the model, but the point stands: autonomy is a reliability tax you pay forever.

A Real Build: The $40K Agent That Should Have Been a Cron Job

The project I opened with was a "smart document processor." The brief asked it to read incoming PDFs, decide which template applied, extract fields, and route to the right team. The shop we hired built a multi-agent system: a classifier agent, an extractor agent, a router agent, and a supervisor to mediate them.

It worked in the demo. In production it misrouted 1 in 9 documents and burned $1,200 a week on model calls. We tore it down. The final version is a 200-line Python service: a regex and a lookup table for the 14 document types we actually receive, a validator, and a single API call to the model only for the fields that are genuinely free-text. Routing accuracy went to 99.4 percent. Cost dropped to about $30 a week. The "agent" part survived only as one small, bounded call.

That is the pattern. Agents earn their place at the edges, where judgment lives. The plumbing should be code.

When Not to Use AI Agents

Say it out loud so the roadmap committee hears it. Do not use an agent when:

• the steps are fixed and known
• a wrong action is expensive and unrecoverable
• you need the result to be the same every time
• latency or cost is a hard constraint
• a simple API call with a good prompt already does it

I cover the testing side of this in how to test AI agents before production, because the moment you do decide an agent is right, verification becomes the whole job. An agent you cannot test is an agent you cannot trust, and tool-call verification is where most of those trust failures actually start.

The Decision Rule I Ship With

Here is the version I put in every proposal now. Start with a workflow. Write the code path. If, after it runs, you keep hitting cases where the fixed path is wrong and a human has to intervene, that is your signal an agent belongs in that specific gap. Not the whole system. The gap.

The teams shipping real agents are not the ones who reached for the framework first. They are the ones who earned the complexity by proving a simpler thing was not enough. Build the boring version. Measure where it breaks. Then, and only then, let the model drive.

That is when to use AI agents. Everything else is a script with a longer resume.