What makes something an agent

Most AI in a business system does one thing when asked. Read this document. Draft this email. Score this lead.

An agent is different. It is given a goal rather than a task, and it works out the steps itself.

“Chase the overdue invoices” instead of “send this reminder to this customer”.

To do that, it has to decide what to look at, decide what to do, do it, see what happened, and decide what next. Multiple steps, with judgement between them.

That is a genuine advance. It is also why it needs more care in a system where money moves.

What this could look like

Concrete examples make the idea clearer.

Collections. Review overdue invoices, check each customer’s history and any open disputes, draft appropriately different messages, send them, log responses, and escalate the ones that need a person.

Purchasing. Notice low stock, check lead times and supplier reliability, prepare purchase orders, and flag the ones needing approval.

Support triage. Read incoming tickets, gather relevant context, resolve the routine ones, and route the rest with a summary attached.

Month-end preparation. Run the standard checks, chase missing documents, assemble the exceptions, and present a list for the accountant.

Each of these is several steps a person currently does in sequence.

The honest state of it

Some of this works now. Much of it works in demonstrations and needs supervision in production.

Working reasonably today: multi-step tasks within a narrow, well-defined boundary, with review before anything commits.

Emerging: longer chains where the agent decides between several genuinely different courses of action.

Not there: anything you would leave unsupervised where the cost of being wrong is significant.

The gap is not intelligence. It is reliability under exceptions. An agent that handles ninety-five percent of cases well and does something odd on the other five percent is a problem in a system that touches money — because the five percent is where the money usually is.

Why business systems are harder than they look

Four reasons an agent in an ERP is a different proposition from an agent doing research.

Actions are hard to reverse. A posted journal entry needs a reversal. A sent email cannot be recalled. A confirmed order has been communicated to a supplier.

Errors compound quietly. A wrong step produces a wrong record, which the next step treats as fact. By the time anyone notices, several things are wrong.

Explanation is genuinely difficult. When an agent takes fifteen steps and the outcome is wrong, tracing why is hard. In a system an auditor may examine, that matters.

Permissions are inherited wholesale. An agent with the ability to post entries can post wrong ones. There is no partial capability.

Where to use them now

Two rules make agents useful today.

Narrow the boundary

An agent with a defined scope and a limited set of permitted actions is far more reliable than one with broad latitude.

“Prepare collection emails for overdue invoices under a set value, do not send” is a task an agent handles well.

“Manage our receivables” is not, yet.

Keep the commit step

Let the agent do the work and stop before anything irreversible.

Draft the emails and present them. Prepare the purchase orders as drafts. Assemble the exception list.

A person confirms.

This captures most of the time saving. The steps that take the effort are the gathering, checking and preparing — not the final click.

Questions to ask any vendor

Six, and vague answers tell you something.

• What exactly can it do, and what can it not?
• What can it do without a person confirming?
• What permissions does it run with?
• How do we see what it did and why?
• What happens when it encounters something unexpected?
• How do we stop it mid-task?

That last one matters more than it sounds. An agent working through two hundred records needs a stop button that works immediately.

What to be sceptical about

“Autonomous” as a selling point. In a business system, autonomy is a risk to be managed, not a feature to be maximised. Ask what it does without confirmation.

Demonstrations on clean data. Everything works on clean data. The question is what happens with a duplicate customer, a missing cost, or a half-completed record.

Claims without a stop mechanism. If nobody can explain how to interrupt it, it is not ready.

Anything that would post to your ledger unsupervised. Whatever the accuracy figures.

A realistic position

For most businesses, the sensible stance is:

Watch this properly. It is progressing quickly and the direction is real.

Use narrow, supervised versions now where they exist. Preparation and gathering, not commitment.

Do not restructure your processes around it yet. Build on what works today.

Keep your data clean. Everything that comes will work better on clean data, and worse on bad data. That work is worth doing regardless of what arrives.

The short version

An agent works out its own steps toward a goal, rather than doing one task. That is a genuine advance and it is arriving.

In a business system the difficulty is not capability. It is reliability on the exceptions, and the fact that actions cost money and are hard to reverse.

Narrow the scope. Stop before the commit. Limit the permissions. Log everything.

Used that way agents are useful now. Used as marketing describes them, they are a risk you will not notice until the exception arrives.