That 'AI Agent' You're Being Sold Might Just Be a Flowchart

I've had three calls this year where someone described an "AI agent" they wanted built, and by the end of the conversation it turned out to be a form that sends an email when a field is filled in. Nothing wrong with that. It's useful. But it's not an agent, and calling it one sets the wrong expectations before a line of code gets written.

The term has spread fast because it sells. Every automation tool now has an "agent" in its marketing somewhere. Some of what's sold really does involve a language model making decisions with some autonomy. A lot of it is a decision tree that someone has dressed up because "workflow" doesn't sound as exciting on a landing page.

What actually makes something an agent

A genuine AI agent, in the sense people mean when they use the term properly, does three things a plain script doesn't:

• It decides what to do next based on the situation, not a fixed sequence of steps.
• It can call on more than one tool or source of information to complete a task.
• It can adjust its own approach if the first attempt doesn't work, within limits you've set.

A rule-based automation, by contrast, follows a path someone designed in advance. If X happens, do Y. If a field is blank, send a reminder. If an invoice is over 30 days old, flag it. This is not a lesser thing. It's often exactly what a business needs, and it's cheaper, faster and easier to trust than anything involving a model making judgement calls. The problem is only when it's marketed as one and priced as the other.

Why the distinction actually matters to you

It matters for three practical reasons, not because the terminology itself is interesting.

Cost and complexity. A rule-based system is quick to build and cheap to run. A genuinely agentic one needs proper guardrails: logging, fallback behaviour, limits on what it's allowed to touch, and a way for a human to step in when it gets something wrong. If you're quoted the same price for both, someone's numbers don't add up.

Predictability. Rules do the same thing every time given the same input. That's a feature, not a limitation, for anything touching invoicing, compliance, or customer communication. An agent making judgement calls will occasionally make a different call than you'd expect. If your process can't tolerate that, you don't want a real agent there, however good the demo looked.

What happens when it's wrong. With rules, you can trace exactly why a decision was made and fix the rule. With something making its own calls, "why did it do that" is a harder question to answer, and you need a plan for catching mistakes before they reach a customer. I've written before about how AI agents tend to fill gaps with assumptions rather than asking, and that habit gets more consequential the more autonomy you've handed over.

Questions worth asking before you buy

If someone, a vendor, an agency, or your own team, pitches you an "AI agent" for a process, ask these directly:

• What decisions does it actually make, versus what's a fixed rule underneath?
• What happens when it encounters something it hasn't seen before? Does it guess, stop, or ask?
• Can I see a log of what it decided and why, after the fact?
• What's the blast radius if it gets something wrong? A misfiled document is different from a wrong refund issued automatically.
• What tools or systems can it reach, and who decided that list?

If the answers are vague, or the demo only shows the happy path, that's worth noting. Good agentic systems are the ones where someone has clearly thought about the unhappy paths too.

When plain automation is the right answer anyway

Most of what businesses actually need doesn't require an agent at all. Chasing overdue invoices, syncing a booking system with a calendar, generating a report every Monday morning, checking stock levels and reordering when they drop below a threshold. These are well-defined processes with clear rules. Building them as rules is faster, cheaper, and far easier to maintain than wrapping them in a language model that adds cost and unpredictability for no real benefit.

The cases where genuine agent behaviour earns its keep tend to involve unstructured input: reading a messy inbox and deciding how to route it, summarising varied documents, handling customer queries that don't fit a script. Even then, the useful version usually has a human checking or approving the output somewhere in the loop, at least until you've built enough confidence in it to loosen that.

The honest version

I'll tell you straight, when we talk through what you actually need, whether the "agent" you had in mind is really just a well-built set of rules, or whether the process genuinely benefits from something more flexible. Most of the time it's the former, and that's good news: it's quicker to build and there's less that can go wrong. If you do need the real thing, it's worth building it with someone who's thought about what happens when it gets it wrong, not just what happens in the demo. If you want to talk through a specific process, get in touch and I'll give you a straight answer either way.