AI Agents Are the 2026 Hype, But Most Companies Need a Script, Not an Agent

A client came to us last spring with a sentence that sounded copied straight off a conference slide: "We need an autonomous AI agent that runs our onboarding by itself." We asked what that onboarding actually does. The answer: it sends three emails on a schedule, checks whether the user completed their profile, and if not, sends a reminder. That is not a job for an agent. That is a cron job and three conditions. We wrote it in an afternoon, it has run for a year without a single incident, and it costs nothing per call.

The agent story is everywhere in 2026. The agent that books, researches, and decides on its own. The technology is real and sometimes genuinely impressive. But in nine out of ten conversations we have, what the company calls an "agent" is actually a linear process with a couple of branches. For that, an agent is the most expensive, slowest, and least predictable way to solve something a script handles deterministically.

What an agent actually is, and what it isn't

Let's agree on terms. An agent in the serious sense is a system where the LLM itself decides which step comes next, picks tools from a given set, evaluates the result, and loops until the task is done. The key word is decides. If you already know the sequence of steps up front, you don't have an agent, you have a workflow with an LLM call inside it. That is perfectly fine, just don't pretend it is something else.

In June 2025, Gartner published a prediction that got cited constantly through 2026: more than 40 percent of agentic AI projects will be canceled by the end of 2027. The reasons they list are not exotic. Escalating costs, unclear business value, and inadequate risk controls. The same report introduced the term "agent washing," the repackaging of ordinary chatbots and RPA tools into something sold as an agent. In other words, half the market is selling a script under the name of an agent, and the other half is wondering why their agent costs as much as a small team.

When a script is objectively better

Determinism is a feature, not a shortcoming. If a process has a clear input, known steps, and a clear output, deterministic code wins on every metric a client cares about. It is cheaper because there is no per-token cost. It is faster because there is no model latency. It is testable because the same input always produces the same output. And when it breaks, it breaks at a line you can read in the log, not somewhere inside the model's "reasoning" that you cannot reproduce.

An example from practice. On one e-commerce project, incoming inquiries had to be categorized and routed to the right team. The first proposal on the table was an agent that "understands context and routes by itself." What actually shipped: a few keywords, a check on the order amount, and a single LLM call only for the edge cases the rules do not cover. Ninety percent of traffic is handled by rules in milliseconds and at no cost. The model only fires for the ten percent where it genuinely adds value. That is not an agent, it is good engineering, and that is exactly why it works.

Where agents actually break

The problem with a real agent is not any single step, it is the compounding effect. If one step is correct with 95 percent reliability, a chain of five such steps drops to around 77 percent. Ten steps and you are below 60. An agent that plans long chains of actions on its own falls apart mathematically, and every error along the way feeds in as the input to the next step and gets amplified.

The second problem is observability. When an agent gets it wrong, "why" often has no clean answer. Context accumulated across several calls, the model misread one tool result, and kept building on it. In a script you open the log and see the exact line that failed. In an agent you reconstruct a reasoning chain that may never replay the same way. The third problem is actions with consequences. An agent that can send emails, change data, or spend money without hard limits will, sooner or later, do something you did not ask for. That is why serious setups keep a human on the critical steps, which in turn undermines the full-autonomy pitch.

When an agent does make sense

We are not against agents, we are against agents in the wrong place. An agent pays off when the problem genuinely has an open solution space, when the possible paths grow so large you cannot enumerate them in advance, and when it is acceptable for the system to be wrong sometimes because a human reviews the result anyway. Exploring an unknown document base, exploratory data analysis, tasks where every case is different. That is where an agent's adaptivity is worth what it costs.

The rule we use is simple. First we ask whether we can draw the process as a diagram with known steps. If we can, it is a workflow, we write code and drop in an LLM only where language or judgment is needed. We give an agent a shot only when we honestly cannot draw that diagram because the paths are too many. Nine times out of ten the diagram exists, nobody just wanted to draw it because "agent" sounds better in a meeting.

Related:

• AI in Web Development 2025: Where It Actually Helps and Where It's Just Hype
• RAG Isn't Magic, It's Search Engineering Most Teams Get Wrong

Thinking about automating a process and not sure whether you need an agent or a plain script? That conversation is the cheapest part of the project and it saves the most money. Contact us and we'll walk through your case without the hype.