Insights
What an AI agent actually is — and isn't — for an SMB
A plain-English definition of AI agents for small business, the three-signal test for when to build one, and when an automation is the smarter buy.
“AI agent” is the most over-used term in the small-business software market right now, and the gap between what vendors mean by it and what you’ll actually get is where budgets go to die. So before you buy one, build one, or get sold one, here is the operator’s definition — the one we use when we scope work for SMBs and public-sector teams.
The one-sentence definition
An AI agent is a system that uses a language model to decide what to do next — which tool to call, in what order — based on what came back from the last step, until a task is done.
The load-bearing word is decide. A program that always calls the same three APIs in the same order isn’t an agent. It’s an automation, and that distinction is worth real money, because automations are cheaper to build, cheaper to run, and far easier to keep alive.
You reach for an agent when the next step genuinely depends on the result of the last one. A support request that might be a billing question, an outage, or a feature request — and needs a different path for each — is agent-shaped. A nightly export that always moves the same fields from one system to another is not.
What an agent is not
- It is not a chatbot. A chatbot answers. An agent acts — it files the ticket, books the slot, updates the record. The chat box is just one possible surface.
- It is not “AI for the whole company.” The agents that fail are the ones scoped as a universal assistant on day one. The ones that work start as one workflow, one team, one clear input and output.
- It is not magic that removes the need for rules. A good agent has more guardrails than the manual process it replaces, not fewer.
- It is not always the right answer. About 60% of what gets pitched to us as “an AI agent” is automation wearing a costume. We say so before any money changes hands.
The AIX three-signal test
When an SMB asks us whether a task is worth turning into an agent, we look for three signals. If a candidate workflow doesn’t hit all three, we don’t build the agent — we either automate it or leave it alone.
Walk a real example through it. Ticket triage for a 200-person company: the decision is data-shaped (the ticket text tells you the category), a human does it dozens of times a day, and the cost of a wrong route is a quick reassignment. Three for three — that’s a strong first agent. Now try “an agent that writes our marketing emails”: the quality bar is vibe-shaped, the volume is low, and a bad send goes to your whole list. Zero for three. Don’t build it.
Agent or automation? A quick comparison
| Automation | AI agent | |
|---|---|---|
| Decides the next step? | No — fixed path | Yes — depends on the data |
| Build cost | Lower | Higher |
| Run cost | Predictable | Varies by model + context |
| Best for | Repetitive, identical steps | Branching, judgment-shaped work |
| Failure mode | Breaks loudly when an API changes | Can be confidently wrong |
Most SMBs need more automation than they think and fewer agents than they’re being sold. The skill is telling which problem you actually have — which is the first thing we figure out together on a discovery call.
What “shipped” means
A demo is easy. A shipped agent has four things, or we don’t call it shipped:
- An eval harness — a test set of real inputs so you can change a prompt without praying.
- A cost dashboard — per-task cost, visible, so spend never surprises you.
- A fallback path — what happens when the model is wrong (log, escalate, refuse).
- A named human owner inside your org who’s accountable for it.
The eval harness is the one most teams skip, and it’s the one that separates an agent that survives contact with production from one that quietly degrades until someone turns it off. This mirrors Anthropic’s guidance on evaluating Claude applications — eval first, ship second.
We build these for our own shop first
We’re not describing this from theory. AVA, the assistant our own MSP runs every day, is an agent over years of support history — it retrieves the relevant tickets, drafts the note, and takes the bounded actions an engineer approves. We shipped it to ourselves before we recommended the pattern to anyone, which is the whole reason this definition is opinionated instead of generic.
Common questions
Is an AI agent the same as ChatGPT? No. ChatGPT is a general assistant you talk to. An AI agent is a scoped system that takes actions inside your tools — it might use the same underlying model, but it’s wired to a specific job with specific permissions and guardrails.
Do I need an agent or just automation? If the steps are always the same, you need automation. If the next step depends on what the last step returned, you’re in agent territory. Run the three-signal test above; if you’re unsure, the AI Readiness Assessment walks through it for your specific workflow.
How much does an AI agent cost a small business to run? Per-task cost depends on the model and how much context each call needs, but a well-scoped agent should cost an order of magnitude less than the labor of doing the same task by hand. We ship a cost dashboard with every agent so the number is never a mystery.
How long does it take to build a first agent? Four to six weeks for a pilot: scope on the discovery call, build the eval harness and integration first, then the agent itself, then a week of bake-in. We deliberately start narrow.
Where should an SMB start? With the highest-volume, most clearly bounded decision a person on your team makes by hand every day. Pick that one. If you want help finding it, that’s exactly what the discovery call is for.
Keep reading
Related
Want this shipped in your org?
Take the AI Readiness Assessment for a personalized scorecard, or book a 30-minute discovery call. No slides — bring the workflow you've been arguing about and we'll tell you whether it's the right first one.