What an AI agent can and cannot do in your business today

The word "agent" now covers everything from a scripted workflow with a language model bolted on to a system that reads your inbox and acts on it. The distinction that matters is simple: can it only tell you things, or can it also do things?

Everything that follows is about the second kind, because the first kind is a search box with better manners.

What works reliably now

Bounded, reversible tasks with a clear definition of done.

Drafting a reply for you to send. Categorising and routing incoming work. Pulling data out of documents into a spreadsheet. Preparing an order, a quote or a schedule that a person confirms. Reconciling two lists and reporting the differences.

The pattern is that a human stays on the last step, and the cost of a mistake is a correction rather than a loss.

What does not

Anything irreversible without review. Sending money. Deleting records. Publishing publicly. Replying to a complaint. Not because the technology always fails, but because when it fails it does so confidently and at speed, and you find out afterwards.

Long chains of steps also degrade in a way that surprises people. Each individual step is usually fine. Twelve steps compound into something nobody predicted, and the failure is often not in any single step but in an assumption carried forward from step three. Short chains with checkpoints are far more dependable than one long autonomous run, and much easier to debug when they do go wrong.

The question to ask before automating anything

What happens if this is wrong and nobody notices for a week?

If the answer is "we fix it", automate it. If the answer involves money, a legal obligation or a customer relationship, keep a person on the last step.

That single question sorts most decisions correctly, and it sorts them faster than any amount of discussion about how capable the technology is this month.

Keep a record of what it did

Anything taking actions should leave a log a human can read: what it did, when, on what input, and what it changed.

Without that you cannot audit it, you cannot debug it, and you cannot answer a customer asking why something happened. This is unglamorous and it is the difference between a system you can trust and one you merely hope about. Ask for it before you switch anything on.

Who is responsible when it acts

This question gets skipped because it feels like a legal formality. It is not — it decides how you build.

If an agent sends a quote with the wrong price, the customer is not interested in which system produced it. It came from your business, in your name, and you are bound by it in exactly the way you would be if a member of staff had sent it.

That has two practical consequences. Anything customer-facing needs a named person who owns its output, the same way a member of staff has a manager. And anything committing you to a price, a date or a scope needs a human on the last step — not because the machine is unreliable, but because the liability is yours regardless and you should see what you are agreeing to.

Firms that treat an agent as a member of staff with a supervisor tend to do well with them. Firms that treat it as a tool that cannot be blamed tend to find out the hard way.

How to pilot one without betting the business

Run it alongside the existing process rather than instead of it, for a fixed period, on real work.

The agent does the task and a person does it as they always would. Compare. This feels wasteful and it is the cheapest information you will get — you learn the error rate on your own work rather than on a vendor's demonstration, and you learn it before anything depends on it.

Two weeks is usually enough to see the shape. If the disagreements are rare and obvious, hand it over with a review step. If they are frequent, or subtle enough that the person had to think hard about who was right, stop — subtle disagreements are the dangerous kind, because those are the ones nobody catches later.

What it needs access to, and what it should not have

An agent is only as dangerous as the permissions you hand it, and permissions are usually granted in bulk because that is the quickest way to make the setup work.

Give it the narrowest access that lets it do the job. Read-only where reading is enough. A single mailbox or folder rather than the whole account. Its own login rather than a shared one, so the audit trail says what it did rather than what somebody did. And no standing access to anything that moves money — a system that can issue a refund unattended will eventually issue one you did not intend.

Two things are worth setting up at the same time, because neither is interesting until it matters. A way to revoke that access in one step, without unpicking a configuration you no longer remember. And a limit on volume, so a mistake sends five wrong emails rather than five hundred before anyone notices.

The mechanism to keep in mind: agents fail at machine speed. The damage is not usually a wrong action — it is the same wrong action repeated faster than a person can intervene.

Start where the work is boring

The best first candidates are the tasks your staff describe as tedious and describe the same way every time. Predictable inputs, predictable outputs, low cost of error.

That is where this technology is genuinely good, and where the time it gives back is real rather than theoretical. It is also where a failure teaches you something cheaply.

The businesses that get burned are almost always the ones that started with the impressive thing rather than the boring thing.