AI agents for small businesses:where they help, and where they do not.

01 /Start with the task, not the agent

An ordinary automation follows a path you define: when a paid invoice arrives, attach it to the matching order and mark the task complete. An agent is given a goal and a limited set of tools, then chooses some of the steps: read an unfamiliar request, decide which record matters, ask for missing information or draft a response.

That difference matters more than the model name. If you can write the correct steps and exceptions down, a fixed workflow will usually be cheaper, faster and easier to test. Use an agent for the ambiguous part, not as decoration around a process that already has rules.

02 /Tasks that make a promising first agent

Good candidates arrive as messy text or documents but end in a narrow, verifiable result. Examples include sorting incoming requests into an existing queue, finding the relevant policy before a colleague answers, comparing a supplier document with an order, or preparing a draft that a person already reviews.

The task should happen often enough to measure, tolerate a short delay and have examples of acceptable output. It also needs a clear escape route: when the evidence conflicts, a field is missing or confidence is low, the agent should stop and hand the case over rather than improvise.

• A person can check the result quickly without repeating all the work.
• The available documents contain enough evidence to make the decision.
• A mistake can be contained before it affects money, access or a customer promise.
• The tools expose narrow actions instead of one all-powerful account.
• There are enough real examples—including awkward ones—to test before launch.

03 /A worked example: triaging a shared inbox

Consider a fictional maintenance company with one inbox for breakdowns, quote requests and supplier messages. Today, a coordinator reads each email, finds the customer in the job system, creates a task and forwards anything urgent. The useful agent does not 'run customer service'. It extracts a small set of fields, looks up one customer, proposes a category and urgency, and prepares a task for review.

The fixed workflow still checks required fields, writes the approved task and sends the standard acknowledgement. A person approves urgent cases and anything the agent cannot match. This division gives the flexible reading to the model and keeps customer promises and database changes deterministic.

The pilot can be evaluated against a month of past messages: correct category, correct customer match, missed urgent cases, unnecessary escalations and review time. 'The answers look good' is not a release criterion.

04 /What should stay predictable

Do not ask a model to calculate a price that already has a formula, decide a permission that already has a policy, or move money because a message sounds convincing. Exact calculations, access control, legal retention, inventory updates and final payment actions belong in code and explicit rules. An agent may collect the evidence or explain an exception, but the system should enforce the boundary.

The same applies when there is no reliable way to judge the answer. A fluent paragraph can hide a weak decision. If the reviewer has to research the case from scratch every time, the agent has saved little and may add misplaced confidence.

05 /Design the human handoff before the happy path

Human review is not a button added at the end. Decide what the reviewer sees: the source material, the proposed action, the evidence used and what changed. Make approval and correction simple enough that people will use them rather than work around the system.

Define triggers that always require review—large amounts, new customers, sensitive data, conflicting documents—and let ordinary low-impact cases pass only after the measured error rate supports it. Keep the original input and an audit trail so a decision can be reconstructed later.

NIST's AI risk guidance treats governance, testing, monitoring and clearly assigned human roles as ongoing work, not a one-off launch checklist. For a small business the implementation can be modest, but the responsibilities still need names.

06 /Build the smallest pilot that can be disproved

Choose one input channel, one type of case and one output. Run the agent on historical examples first, then in shadow mode beside the existing process. Record where it is correct, where it abstains, what it costs and how long review takes. Include deliberately difficult cases instead of polishing a demo around the easiest ten.

Set a stopping rule before the trial: for example, no missed urgent cases in the test set, a meaningful reduction in review time and a clear ceiling on per-case cost. If it fails, narrow the task or use rules. A pilot that proves an agent is the wrong tool has still prevented a larger mistake.

07 /Limit what the agent can see and do

Give the agent purpose-built tools: read one order, draft one task, propose one update. Do not hand it a general database credential or an unrestricted browser session. Validate every tool argument in ordinary code, cap retries and spending, and require approval for irreversible actions.

Treat incoming documents, web pages and emails as untrusted data. They may contain instructions aimed at the model rather than your business process. Keep those contents separate from system instructions, restrict tool permissions and log calls and results. OWASP describes excessive agency—too much functionality, permission or autonomy—as a central risk in agentic systems.

Finally, plan for change. Models, prompts and source documents evolve. Keep a small regression set of real cases, re-run it before changes and watch production outcomes rather than assuming yesterday's accuracy will continue.