What AI agents can actually do for small businesses

A demonstration shows what a system can do on a good day. It does not tell you what it will do on yours. The short answer is that an AI agent can sort, summarise and draft a lot of a small business's routine work, but anything involving money, commitments or silent failure still needs a person. Here is how I decide which is which, with examples from running agents in my own business.

What an agent actually is

Ordinary automation follows a script, and it stops working the moment reality is messier than the script. An agent is given a goal and a set of tools, and it decides what to do next. That makes it useful in the messy middle of a job. It also makes it risky, because a system that decides what to do next can decide wrong.

Four kinds of useful work

In a service business, the tasks worth considering fall into four groups, and the order matters. They run from annoying to get wrong to expensive to get wrong.

Classify and route. Something arrives, whether a call, an email or a form, and it needs to go to the right place with the right context. The failure mode is mild: a wrongly routed enquiry is annoying and recoverable.

Summarise and record. A phone call happens, and someone needs to know what was discussed without listening to it. In a business where nobody has time to write anything down, a reliable summary is worth a great deal.

This is the job our own AI voice agent does at Manchester PC (opens in a new tab). It answers the call, collects the details and leaves a record. We review what it collected and decide which enquiries need a call back. It records; a person decides. Even this mild job needed work. Postcodes were misheard often enough that the agent now checks what it heard against a list of real UK postcodes rather than trusting the transcription.

Draft and prepare. A quote, a follow-up (opens in a new tab) (that link is to Step Into AI, the platform I run) or a reply. The agent produces the first version and a person approves it. Drafting is where the time goes, and approval is quick.

Act and send. The agent sends the message, books the slot or updates the record. This is where the risk lives, and where the design work has to be done carefully.

Where they do not belong

Anything involving a number that matters. Prices, quotes, stock levels and delivery dates all qualify. A language model predicts text; it does not calculate. Any figure that goes to a customer should be computed by something that computes, not generated by something that predicts text.

Anything that commits the business. Sending a quote, agreeing a discount, promising a date or accepting terms. The agent can prepare all of it, and the commitment should come from a person.

Anything where being wrong is invisible. This is the dangerous category and the hardest to spot. If an agent quietly fails to follow up a lead, there is no error and no complaint. Silent failure needs its own defences: reporting, reconciliation, and a way of counting what should have happened against what did.

I met this first-hand testing OpenClaw, an open-source autonomous agent. It would say it had started sub-agents to share the work, and when I checked, about half the time nothing had actually happened. An agent that fails loudly is annoying. One that reports success when it failed is dangerous.

Framing the approval question

“Should a human approve this?” does not help much, because the honest answer is nearly always yes. A more useful pair of questions is what a wrong action costs, and how long it would take for someone to find out.

If the cost is low and it is discovered quickly, let it run. Sorting an enquiry into the wrong queue is a good example, because the worst case is that someone moves it. If the cost is high, and especially if money is attached, a person approves.

If the cost is low but it would go unnoticed for weeks, that needs engineering rather than policy. It needs a report, a sample check, or a counter showing how many times the agent acted and what happened next.

What I would not do

I would not give an agent access to a system just because it might need it. Access should be the minimum that lets it do its job, because every extra permission is another way for a bad decision to have consequences.

And I would not automate a process the business has not yet defined. If people are inconsistent about how something is done, the process is not understood yet. An agent will not fix that, and it may make the inconsistency faster.

Start with one thing

The temptation is to design the whole operation at once. Pick one task instead, and run it in shadow mode alongside the person who does it now. The agent produces its output, the person still does the real work, and the two are compared.

Shadow mode is not free. Someone has to read both outputs, and that time comes out of the same day as everything else. What it buys is evidence about your own work rather than about a demonstration. If it worked, pick the next task.

For two real-world examples, see what three months of an AI voice agent taught us and my honest review of OpenClaw and autonomous AI agents.