A chatbot reads. It looks up an answer — in a script, a knowledge base, a set of canned responses — and hands it back. An AI agent reads and writes: it can update a record, move a ticket to the next status, book a slot on a calendar, send a confirmation email, and then live with the consequences of that change. That’s the line that actually separates the two. Not vocabulary. Not how advanced the underlying model is. Write access, and who answers for it.
Vendors describe it the same way once you strip the marketing. Anthropic calls the distinction workflows vs. agents: in a workflow, “LLMs and tools are orchestrated through predefined code paths,” while agents are “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” Microsoft draws the same border in consumer terms: chatbots use “rule-based or scripted responses,” while an AI agent is “autonomous, goal-driven, and capable of reasoning.” Both descriptions point at the same fact: an agent decides what to do next and acts on that decision. A chatbot doesn’t get to decide anything — it just answers. If you’re still working out which one your business needs, start with what a chatbot actually does — most small businesses asking “do I need an AI agent” actually need a chatbot.
Why the Industry Sells You “Agent” Anyway
Every definition you’ll find in search results was written by a company selling an agent. Zendesk, Salesforce, Microsoft — the word “agent” sits in their product names, so naturally every one of their glossary pages nudges you toward “you need an agent.” None of them mention the part that should worry you more than the word choice: an agent that writes to your systems can also write the wrong thing to your systems, at machine speed, without asking first.
What Has to Be True Before You Let Software Write
Before “agent” makes sense for your business, three things have to already be true — not built by the agent, but true before it shows up.
- There’s a system where the truth lives. Not a person’s memory, not a sticky note, not a spreadsheet three people edit differently. An agent can only act on what it can read reliably, and it can only write to a place that has fields, not tribal knowledge. Plenty of small businesses run entirely on the owner’s memory and a shared inbox — that’s not a system yet, it’s a habit, and there’s nothing for an agent to plug into.
- That system has to grant write access. Read access is easy to hand out; almost every tool has an API for pulling data. Write access is a different decision — it means the agent can change a customer record, close a job, or send a message on your behalf without a human clicking “send.” Most businesses that think they want an agent haven’t actually decided they’re comfortable with that.
- Someone has to own what happens when the write is wrong. Not the vendor. You. If the agent books the wrong slot, updates the wrong status, or quotes a customer the wrong price, somebody on your team resolves it — and that person needs to know it happened. A chatbot’s worst failure is a bad answer someone can correct in the same conversation. An agent’s worst failure already changed a record before anyone noticed.
If any one of the three is missing, “agent” is the wrong tool — not because the technology can’t do it, but because there’s nothing safe for it to act on yet. That’s usually where a well-built chatbot, or a simpler rules-based automation, does the job better and costs less to get wrong.
The Vendors Building Agents Say the Same Thing
This isn’t us being cautious about a technology we don’t sell — it’s the companies building agent frameworks. Anthropic’s own engineering guidance names the failure mode directly: agents bring “higher costs, and the potential for compounding errors,” and need “extensive testing in sandboxed environments, along with the appropriate guardrails” before they’re trusted with anything that matters. Its core recommendation is to “find the simplest solution possible, and only increasing complexity when needed” — in other words, don’t reach for an agent when a scripted workflow will do the job.
OpenAI’s own guidance for teams building agents makes a similar point without saying it outright: an agent should be able to halt what it’s doing and hand control back to a person the moment something goes wrong, operating inside guardrails defined ahead of time rather than improvising past them. Read plainly, that’s a requirement, not a nice-to-have — software that can act on its own has to be built with an exit built in, because “keep going and hope it’s right” stops being an option once it can write.
What This Looks Like in Practice
One place we’ve watched this line hold is project tracking for a contractor. Every lead that arrives by email carries a job-site address. That address doesn’t get typed into a spreadsheet by hand — it’s read out of the inbox automatically, and a card for that job appears in the pipeline. From there, a person still moves the card between statuses; the map view just follows whatever status the card is already in, so the crew can see where today’s jobs actually are without anyone updating two systems by hand. Reading an address out of an email and pinning it to a map is agent-shaped work — narrow, and cheap to check when it’s wrong. Deciding which job gets the crew today stayed a person’s call. That’s not a limitation we’re apologizing for — it’s the boundary from the three questions above, applied to one workflow instead of argued about in the abstract.
More on how that map-based tracking works.
Where to Start
If you don’t have a system where your business truth lives yet, that’s the actual project — not “get an agent.” A chatbot that answers from what you already have will tell you faster whether write access is even worth building toward, and it costs a fraction of what an agent-shaped mistake costs to unwind. We’ve broken down what a chatbot actually costs once you get past the “starts at” numbers vendors publish.
Not sure which side of that line your business is actually on?
