AI Agents for Small Business: The Four Jobs They Do Well, and Four They Do Badly

“AI agent” has been stretched to mean almost anything, which makes it hard to evaluate whether you need one. Here is a working definition, the four jobs they genuinely do well in a small business, and the honest failure modes.

What an agent actually is

An automation follows a fixed path. Step one, step two, step three, done. If something unexpected appears, it fails or ignores it.

An agent decides what to do next. It has a goal, a set of tools it can use, and the ability to choose which tool to use based on what it finds. That is the difference: automation executes a route, an agent navigates one.

This distinction matters commercially, because agents cost more to build and run, and they are only worth that when the path genuinely varies. If your process is the same every time, you want an automation and someone selling you an agent is overcharging you.

Four jobs agents do well

1. Handling unstructured inbound

Email, form submissions, enquiries, support tickets. Anything where a human wrote free text and something has to be understood before it can be routed.

An agent reads it, works out what it is, extracts what matters and routes accordingly. This is the highest-value use for most small businesses, because unstructured inbound is exactly what rules-based automation cannot touch.

2. Research that follows its own leads

Working a prospect list, gathering competitive intelligence, enriching records. The path varies per item, sometimes the answer is on the homepage, sometimes it takes three more steps, which is precisely where an agent beats a script.

3. Document work at volume

Reading contracts, invoices, applications or reports and extracting structured fields. Layouts vary, so pattern matching breaks. Agents handle the variation.

Keep a human review step wherever being wrong is expensive. Extraction is good, not infallible.

4. First-contact conversation

Qualifying an enquiry and booking something. Works well when the conversation has a shape and a defined end state. Works badly when it could go anywhere. There is a detailed version of this for property here.

Four jobs they do badly

• Anything needing accountability. If a decision must have a named person behind it, legal, financial, HR, anything regulated, an agent cannot hold that responsibility. It can prepare the decision. Someone still has to make it.
• Work where being wrong is silent and expensive. If errors will not surface for weeks, the compounding damage outweighs the saving. Add human review or do not automate it.
• Genuinely novel situations. Agents generalise from patterns. Something with no precedent is exactly where they are least reliable and most confident-sounding.
• Relationship work. Your best client noticing they are being handled by software is a real cost that nobody puts in the business case.

The engineering that actually matters

Not the prompt. Three other things:

Tool design

An agent is only as good as what it can do. Tools should be narrow, well-described and hard to misuse. A tool called update_record that can change any field is an invitation to trouble; three specific tools with tight scopes are safer and, in practice, more accurate.

State and recovery

Multi-step work fails partway. The question is whether it resumes or starts over. I build agents as stateful graphs so a failure at step four does not discard steps one to three, which matters both for cost and for not double-sending things.

The confidence boundary

The most important part. Every agent needs an explicit threshold at which it stops and asks a human. Set it conservatively and loosen it as evidence accumulates.

Log every escalation and review them weekly. The pattern tells you where to improve and where the agent should permanently stay out. An agent that escalates too often is annoying. One that never escalates is dangerous.

Cost, realistically

Two components. Build is one-time, typically $1,000 upward depending on how many systems it touches. Running costs are per-use: model calls, plus infrastructure.

The running cost is where projects surprise people. An agent making twelve model calls to complete one task costs roughly twelve times what a single call costs, and that multiplies by volume. Worth modelling before you build, not after.

Cheaper models handle most steps fine. Reserve the expensive ones for the steps that genuinely need reasoning. Routing by task rather than defaulting everything to the strongest model routinely cuts running costs substantially.

How to start

Pick one process. Narrow, high-volume, currently manual, with a clear definition of done.

Run it with a human reviewing every output for two weeks. You will find the edge cases you did not anticipate, there are always some, and you will build an accuracy baseline.

Then loosen review to a sample. Keep the escalation path. Expand scope only once the first thing is boring.

What not to do: commission an “AI transformation” across five processes at once. You will not know which part is failing, and you will have no baseline to judge against.

The honest summary

Agents are genuinely useful for unstructured input, variable-path research and document work at volume. They are not useful for accountability, novelty or relationships, and they are frequently sold for all three.

The test I apply before building anything: if this agent is wrong, how quickly does someone find out, and what does it cost in the meantime? If the answer is “slowly” and “a lot,” it needs a human in the loop, or it needs not to be built.