AI agents for SMEs: what they can do in 2026, and what they can't yet

An agent is not a chatbot with a better personality. It is a loop: a model reads a goal, picks a tool, sees what the tool returned, and decides whether it is finished or needs another step. The tools are ordinary — a search across your documents, a database query, a call to a system you already run. What the model adds is the choosing, one step at a time, with the result of the last step in front of it.

That definition matters commercially, because it tells you where the value and the risk sit. The value is in the tools and the data they reach; a loop with nothing to call is a conversation. The risk is that the loop can take an action, and an action can be wrong in ways a paragraph of text cannot. Everything below follows from those two facts.

For a small or mid-sized business the practical question is narrower than the industry conversation. What can you hand to a loop like this today, with a person still in the room, and what should you leave alone for another year?

What works today

Four patterns are dependable enough to put in front of staff now, in roughly the order most teams should attempt them.

• Retrieval-backed answering: the agent finds the passages in your own material that answer a question, and drafts a reply that cites them.

• Structured extraction: turning a document into fields you can validate, with a confidence signal on each one.

• Scheduled multi-step work: a job that reads several systems on a timer, applies your rules, and writes a result back.

• Triage and routing: classifying whatever arrives, attaching the context, and sending it to the right queue or person.

Retrieval works because the hard part is your content, and you already own it. The agent is not being asked to know your refund policy; it is being asked to find the paragraph that states it and quote it accurately. The failure mode is a missing or mismatched citation, which a person spots in a second, rather than a confident invention nobody can trace.

Extraction is the most under-rated of the four. A model that reads a scanned delivery note and returns supplier, date, line items and total, each with a confidence, replaces a task that is genuinely tedious and easy to check. Validate the fields against rules you already have — does the total match the lines, is the supplier on the approved list — and most errors are caught before a person looks at them.

Scheduled multi-step work is where agents start to look like software rather than a chat window. Nothing waits for somebody to type. The job runs, produces a result and a log of how it got there, and anything it could not resolve lands in a queue with the reasoning attached. Because it runs on a timer you can evaluate it against a week of real cases before anyone depends on it.

Triage is the cheapest place to start if you are unsure. The agent answers nothing. It reads the incoming message, labels it, attaches the customer record and the last few interactions, and routes it. If it labels badly, somebody re-routes and you have gained a training example. Nothing irreversible happens, and the time saved is real.

What still needs a person

The four below are not permanently out of reach, but today they are where an unsupervised agent costs more than it saves.

• Judgement under ambiguity, where the right answer depends on context nobody wrote down.

• Anything irreversible — payments, deletions, public statements, contractual commitments — without a review step.

• Long-horizon planning, where a decision made at step two only proves wrong at step thirty.

• Negotiation, where the other side is adapting to you.

Ambiguity is the honest limit. A model produces a plausible answer whether or not the information needed to answer well was present, and plausibility is exactly what you cannot use as a signal. The mitigation is not a better prompt. It is designing the task so missing information is detectable: required fields, an explicit "not stated" answer, and a route to a person when the source does not contain what was asked.

Irreversibility is a design rule rather than a maturity question. Put the review step where the harm would be, not where it is convenient. A draft that a person sends is a different product from a message that goes out on its own, even when the text is identical — and the first one can ship a year earlier.

Long-horizon planning fails quietly. Each step looks reasonable, small errors compound, and the loop only discovers the problem when it runs out of budget or produces something absurd. Keep the loops short, checkpoint them, and prefer a chain of small tasks a person can inspect between stages over one long autonomous run.

Negotiation is the one where being predictable is a liability. An agent that reliably concedes under pressure is a discovered exploit, not a feature. Use the model to prepare — summarise the position, list the trade-offs, draft the opening — and keep the exchange itself with a person.

The three limits nobody warns you about

These three surprise people after the pilot works, which is the worst moment to meet them.

Evaluation is harder than the build

Getting a demo to work takes days. Knowing whether it is right takes a labelled set, a way to score answers that are not simply right or wrong, and somebody whose job it is to look. Budget for the evaluation set before the build. A hundred real cases with agreed correct answers is worth more than another month of prompt tuning, and it is the only thing that later lets you change a model without guessing.

Cost tracks usage, not seats

Most software you buy is priced per person per month, so the finance model assumes cost scales with headcount. Model access is billed by tokens — roughly, the volume of text going in and coming back — so cost scales with how much work the system does and how much context you send it each time. A long document pushed through a loop that retries is not a rounding error. Meter it from day one, set a ceiling per run, and read the bill weekly during the pilot.

Models change under you

Providers version their models, publish deprecations and retire old ones, and a prompt tuned to one version can behave differently on the next. Treat the model as a dependency with a version: pin it where the platform lets you, keep the evaluation set runnable, and re-run it whenever you move. Teams that skip this find out about the change from a customer.

How to start without betting the business

1. Pick one process that repeats often and is cheap to correct.

2. Run the agent beside the team for two weeks without switching anything off, and compare its output to theirs.

3. Log every input, every tool call and every output, so a disputed answer can be reconstructed instead of argued about.

4. Define the rollback before launch — the switch that returns the process to people, and who is allowed to throw it.

None of that is exotic. It is the discipline you would apply to any system that touches customers. The difference with an agent is that it fails in fluent sentences, so the logs and the evaluation set have to do the work your intuition normally does.

The honest summary for 2026: agents are good at finding, reading, structuring and routing, and unreliable at judging, committing and planning far ahead. Build for the first list, design the second one out of the loop, and revisit the boundary every few months. It has been moving in one direction, and the teams with an evaluation set already running are the ones who will notice when it moves again.