You have an idea. Before anyone builds anything, four questions decide whether it is an agent, something simpler, or not a software problem at all. Getting this wrong is the most expensive mistake in the whole subject, and it is made before a line of code exists.
First: can you draw the steps in advance?
If you can sketch the flow on a whiteboard before it runs, you do not need an agent. You need an automation, or an automation with AI doing the messy parts.
That middle option is the one almost nobody offers you, and it fits most real business processes better than either extreme. The path is fixed, exactly like a normal automation, but at two or three named steps a model reads something messy, drafts something, or makes a judgement call.
A new enquiry arrives. AI reads and classifies it. Fixed rules route it. AI drafts the reply. A person approves. The CRM updates. Two steps needed a model. The rest is plumbing.
It is cheaper, faster and far easier to fix, because a failure traces to a step rather than to a decision nobody can reconstruct.
You need a genuine agent when the sequence cannot be known in advance, because what happens next depends on what the last step turned up. That is a real category. It is just rarer than the market implies.
Second: would three people describe it the same way?
Ask three people who touch the process how many steps it has. If you get three different numbers, stop. You do not have a software problem. You have a process that exists in fragments across several heads.
This is the most common true answer we give, and almost nobody else gives it, because there is nothing to sell attached to it. It is also why so many cross-department requests arrive as “we need an agent”: people are trying to buy a system that knows the thing nobody has written down.
Finance sees steps one to four. Operations sees five to nine. The account director sees the complaint at the end. Each is individually confident. None can describe the whole thing.
The fix is a couple of hours of mapping, not a build. And the output of that mapping is the most reusable thing you will produce, because a written procedure survives changing your mind about tools later.
Third: what starts it, and who notices when it stops?
Four things can start an agent, and they produce completely different products out of identical builds.
- A person asks. Someone is present to check the output.
- A schedule. It runs at 7am whether or not anyone is watching.
- An event. A form is submitted, an email arrives, a record changes. The most common real shape.
- Another agent hands it work.
The moment the trigger is anything other than a person, you have taken on an obligation: somebody has to find out when it stops working.
And the check has to be the right kind. Not “did it run” but “did it produce what it should have”. We learned this expensively. One of our reminder pipelines ran perfectly on schedule for weeks while sending nothing at all, because it was hosted somewhere it could not read the credentials it needed. Every health check was green. The job was running. It just was not working.
Fourth: does the arithmetic work?
The unglamorous gate. How often does this happen, and how long does it take a person now?
Twice a month at twenty minutes is not a build. It is forty minutes a month, and you will spend more than that maintaining the agent.
Daily at twenty minutes is a different conversation entirely, and so is weekly at three hours.
Run the numbers before anything else, because a good agent doing a job that barely needed doing is still a waste, and it is a waste that looks impressive for about a month.
What people say, and what they usually mean
Most agent conversations are two vocabularies talking past each other. This is the table we use on client calls. The third column matters most: never open by correcting the word, ask the question and let them get there.
| They say | It usually means | Ask this instead |
|---|---|---|
| We want an AI agent | A fixed path with a model at two or three steps | Are there specific steps where a judgement call happens, or does it need to work out the whole path itself? |
| Can we automate this? | Automation, once somebody writes the process down | Could a new starter run it on Monday from what is written down today? |
| It needs to be intelligent | One step has to read messy input | Show me what arrives. Emails, PDFs, free text, or something already structured? |
| It should just handle it | Nobody has decided who reviews the output | When it gets one wrong, who finds out, and how? |
| Like ChatGPT but for our data | A retrieval assistant, not an agent | Where does that data live now, and how often does it change? |
| We want it to learn | Knowledge, or a written procedure that gets updated | Learn from what? Every case, or the ones where you corrected it? |
| What stops it going wrong? | A permission gate and a named reviewer | What should it never be allowed to do, even if it decides it should? |
| Our automation is agentic | There is an AI step in it, or AI helped build it | At runtime, can it do something that is not on the canvas? |
Every question in that last column is about observable behaviour. Nobody has to concede a definition to answer one, which is why they work in a room.
How to tell whether a vendor is really selling you an agent
The industry has a name for the gap between the claim and the thing: agent washing. Assistants, chatbots and ordinary automation rebranded as agentic.
But agentic automation is not automatically false, which is what makes it awkward. Most of those platforms genuinely do let you build agents now. So the question is never whether the vendor is lying. It is whether the thing you have is an agent, or an automation on a platform that also sells agents. That is a question about your own build, and it is answerable.
One test, then evidence. The test is: who decides the next step? Everything below is how you check the answer you were given.
- Where is the AI, in the builder or in the running thing? A lot of agentic claims mean an AI assistant helps you construct the automation. Useful, and it says nothing about the runtime. Cheapest question to ask, and it settles a surprising number of them.
- Can you draw it? If there is a canvas and the boxes are the steps, the path was decided in advance. That is a workflow, however clever the steps.
- Does the number of model calls vary between runs? Visible in the logs and on the bill. Strong evidence, not proof: a workflow can loop or fan out over a variable number of items too. What it cannot do is vary which steps run, so pair this with question two.
- Does the model choose which tool to use, or does the code? A fixed slot that always calls the same tool is a workflow step, even when a model fills it in.
- Show me a failure. Give it a broken link or a missing field. A workflow does exactly what its error branch says. An agent may re-plan: pick a different tool, take another route, try something else unprompted.
One trap in that last one. Stopping and asking a human is not disqualifying. A well-built agent hands back deliberately, and a good one does it often. The question is not whether it ever stops. It is whether re-planning is available to it at all.
Where you land
After those four you are in one of five places, and only one of them is an agent.
- Map it first. Nobody can describe the process. Do that, then reassess. Very common.
- Not worth building. The arithmetic does not work.
- An automation. Fixed path, no model needed anywhere.
- An automation with AI at named points. Fixed path, model reads or drafts at two or three steps. In our experience this is where most business processes actually land.
- An agent. The path genuinely cannot be known in advance.
Whichever it is, the next question is what to build it with, which is the tools page. And if it did turn out to be an agent, read the skills page first, because what makes agents work is not the tooling.