What is an agent, actually?

Everyone selling software in 2026 calls it an agent. Here’s the definition I actually use at work, and it has nothing to do with architecture.

A chatbot answers you. A workflow follows steps someone wrote in advance. An agent is different in one specific way: somewhere in the middle of the work, it makes a judgement call you didn’t script — and then acts on it.

That’s it. Not the model, not the framework. The judgement plus the acting.

An invoice arrives. Software that extracts the total is a tool. Software that follows “if total is more than £10,000, route to Priya” is a workflow. Software that reads the invoice, notices the supplier is new, the purchase order doesn’t quite match and the bank details changed last week, and decides this one needs a human — that’s an agent. It exercised judgement about the situation, not a rule someone pre-wrote.

Which is why the interesting question about any agent is never “how smart is it?” It’s the question you’d ask about a new hire: what is it authorised to do with its judgement?

There’s a ladder. Suggest — it recommends, a person acts. Prepare — it drafts the email, queues the payment, a person approves. Act — it does the thing, and a person finds out afterwards. Every rung up the ladder trades review time for risk. The ladder, not the model, is the real design decision — and it’s a business decision, which means it belongs to operators, not just engineers.

So when someone shows you “an agent”, ask where the judgement happens and which rung it’s standing on. If nobody can answer, you’re looking at either a workflow in a costume or an incident being scheduled.

Try this

Try it: Make the call turns the ladder into three situations where you decide whether the agent should suggest, prepare or act.