Most things you'd call an AI agent shouldn't be one.

A while back I sat down to map out what I'd actually build for advice practices, and I had it wrong.

I'd already built a few AI agents for my own business. One runs my marketing. One watches my sales pipeline and tells me who I've gone quiet on. One handles client communications. They work, and I'm fond of them. So when I started sketching what a practice might need, I sketched agents. An agent for fee consents. An agent for review prep. An agent for reading fact-finds.

Then I sat down to design and cost one properly, and realised almost none of them needed to be agents at all. Nearly every job I'd pictured was a plain automation with one small AI step in the middle. Cheaper, more predictable, and far easier to show someone if they asked how it worked.

Since then I've had the same conversation with enough people to think it's worth writing down, because "agent" has become the word everyone reaches for, and it's usually the wrong one.

---

The Question

Here's the whole framework, and it's one question.

Who decides what happens next?

In an automation, you do. You lay the track in advance. When this happens, do that, then that, then stop. If there's AI involved, it's one narrow station on the line doing a specific job: pull these six fields out of this scanned document, or draft this paragraph. The AI never chooses the route. It does its bit and hands the work on.

In an agent, the AI does. You give it a goal, some tools and some context, and it works out its own steps in the moment. It decides which tool to reach for, when to try something else, and when it's finished.

An analogy that's held up well for me: an automation is a production line you designed. An agent is a capable new starter you brief on Monday morning and let get on with it. Both are useful. They are not the same purchase, and they don't carry the same risk.

---

Why This Matters More In Advice Than It Does Elsewhere

In most industries this is an engineering preference. In a licensed practice it's a governance decision, for three reasons.

You can show an automation to someone. A fixed workflow does the same thing on every single run, and you can walk a person through it step by step: here's the trigger, here's what happens, here's where a human signs off. "The AI decided to" is a much harder sentence to finish in front of a licensee or a regulator. If a process touches client outcomes, being able to explain it precisely is worth more than being clever.

It costs a fraction. One narrow AI call per run is pennies. An agent reasoning its way across a dozen steps, calling tools, rethinking, is a different order of cost. The horror stories you hear about surprise AI bills almost always involve an agent looping without a sensible limit on it.

There's less room to go wrong. If a job has one correct answer, giving the AI freedom to decide how to reach it adds risk without adding value. Freedom is only worth paying for when the job genuinely needs judgement.

So in advice, the simpler tool is usually the better tool. That's not a compromise or a starter version. On a job with one right answer, an automation is the correct build.

---

Working It Through

Three examples, all of them things practices actually ask for.

Reading a scanned fact-find into your CRM. Someone hands you paper, or a PDF. You want the data in your system without anyone typing it twice. This looks like a job for clever AI, and there is AI in it, doing the extraction. But the route never changes: read the document, pull the fields, put them in the CRM, flag anything it wasn't confident about for a human to check. That's an automation. Nothing decides anything.

Pulling the numbers out of a statement of advice. Same shape. Read, extract, file. An automation with one AI step.

Chasing fee consents. This one is more interesting, because it changes depending on how far you take it. Version one is a schedule: find the consents that are due, draft a reminder for each, and send once a human has approved them. Fixed track, no decisions, so it's an automation. Version two reads the client's reply. Now something has to work out whether "leave it with me" is agreement, hesitation or a complaint, and decide whether to reassure, re-send or hand it to a person. That's judgement, in a conversation, and that genuinely is an agent.

Notice what changed between those two versions. Not the technology and not the ambition. What changed is that a decision appeared in the middle of the job. That's the moment you've earned an agent, and not before.

---

Two Things That Trip People Up

"AI agent" is used to mean almost anything. Plenty of products marketed as agents are automations with a language model bolted on, which is fine, and often exactly what you want. The word tells you nothing about what you're buying. Ask the vendor the question instead: at any point in this process, does your system decide what to do next? Their answer, and how comfortable they are giving it, is more informative than the brochure.

An AI model is not an agent. This one causes real confusion. The model is a brain in a jar. It has no memory of you, no tools and no ability to do anything on its own. An agent is that brain plus somewhere for it to run, plus tools it can use, plus memory, plus a defined role. When someone says they've "got AI", it's worth knowing which of those they actually have, because the gap between a model and a working agent is where all the effort lives.

Worth separating too: the AI I use to build things for a client is my tool, not part of what they buy. What runs inside a finished solution is a different thing entirely, sitting in their own environment, invisible to them, doing one narrow job. A client never ends up owning my subscription, and shouldn't.

---

I Went Looking For Someone To Tell Me I Was Wrong

I'd been running this framework for a while before I read a book on building AI agents written by specialists at AWS, mostly expecting to be told I was being too conservative.

It said the opposite. For anything with compliance obligations attached, the pattern it recommends is the explicit, fixed-path one, where you can prove certain checks always happen in a certain order. That's an automation. On multi-agent systems, its advice was blunter than mine: start with one agent and good tools, and only add more when you hit a genuine limit, because a few agents that work reliably beat a pile that don't.

It also sets out a maturity ladder, from a plain language model up through adding data, adding tools, then workflows, then autonomous agents. Most real business problems, it reckons, are solved a fair way down that ladder. Which matches what I keep finding in practices: the valuable work is boring, repetitive and has a right answer.

---

What To Do With This

Next time someone pitches you an AI agent, or you find yourself asking for one, run the question over it. Write down the job step by step, the way it happens now. Then look for the point where a decision gets made.

If you can't find one, you don't need an agent, and buying one means paying more for something harder to explain. If you find one, be precise about where it is, because that's the only part that needs judgement. The rest of the job can still be a plain, predictable automation running around it.

Most of the time you'll find no decision at all, just a sequence somebody has been doing by hand for years. That's not a disappointing answer. That's the cheapest, safest, fastest win in your practice, and it's sitting right there.