The conversation about "AI" has gotten muddy. A lot of teams now refer to anything that involves a large language model as an "agent." That blurring is convenient for vendors selling AI but expensive for the buyers paying for it. The difference between a bot and a custom agent isn't semantic. It's structural — different cost, different timeline, different success criteria, different risk profile.
If you're commissioning AI work right now, the single most useful thing you can do up front is decide which of these you actually need. Most projects we see that come in branded as "an AI agent" should have been scoped as a bot. Some bot projects should have been scoped as agents. Both kinds of mismatches waste months.
The distinction in plain words
A bot answers questions. It's grounded in your content — pages, documentation, catalog data, FAQs, knowledge base — and its job is to understand what the user is asking, retrieve the right answer, and route to a human when it can't. A bot doesn't take actions in your systems. It informs.
An agent completes tasks. It doesn't just answer questions about how to do something — it does it. It connects to your CRM, your help desk, your inventory, your payments. It executes multi-step workflows. It makes decisions within guardrails you've defined. It hands off to a human only when judgment is required. An agent acts.
That's the whole distinction. Bots inform. Agents act. Anyone telling you these are the same thing has either not implemented both or is selling something.
Bots inform. Agents act. Conflating the two produces some of the most expensive mistakes in enterprise AI right now.
How to tell which you need
Three questions, in this order.
1. What does success look like — a better answer, or a completed task?
If success is "the user got the right information faster," you want a bot. Examples: a website visitor figuring out which of your products fits their use case. A B2B buyer comparing two SKUs. A customer trying to figure out how to do something in your software. All of these are about information moving more efficiently from your content to the user's brain. No system actions required.
If success is "something got done that previously required a human," you want an agent. Examples: a refund processed end-to-end. A renewal quote generated and sent. A field service visit scheduled, technician assigned, customer notified, CRM updated. All of these are about a workflow completing without human intervention. The information piece is incidental; the doing is the point.
2. How much structured action sits behind the conversation?
If the answer to most questions can be assembled from existing content, you want a bot. The user asks. The bot retrieves and synthesizes. The user gets answer. Done.
If the answer requires querying multiple systems, executing logic against those queries, possibly writing back to one or more systems, and confirming the result — that's an agent. The structural overhead is much higher because you're building integrations, defining guardrails, and orchestrating across systems.
3. What's your tolerance for the AI making a mistake?
This one matters more than people realize. A bot's worst-case mistake is usually an inaccurate or unhelpful answer. The user can verify, ignore, or escalate. The blast radius is small.
An agent's worst-case mistake is doing something wrong in your system. Refunding the wrong customer. Scheduling the wrong job. Updating the wrong record. The blast radius is bigger, and the recovery work is real. Agents need much heavier design around guardrails, dry-runs, and human-in-the-loop checkpoints — which is part of why they take longer to build.
The math from these three questions usually points the same direction. If you're informing, you want a bot. If you're acting, you want an agent. If you're not sure whether you're informing or acting, you probably want a bot first and an agent later, in that order.
Why most companies actually want a bot first
Most of the AI-on-our-website, AI-in-our-product, AI-for-our-catalog projects we see have an information problem at their core. Users can't find what they need. Or they can find it but can't compare it. Or they can compare it but can't tell which option fits their situation. None of these are workflow automation problems. They're "translate from user intent to existing content" problems.
A bot solves them. Fast. Productized variants of bots — like the three deployments we ship under ANSWR — get to production in four to eight weeks with predictable outcomes (deflection, conversion, time-to-answer). The integrations are content sources, not transactional systems. The blast radius if something goes wrong is conversation quality, not data integrity.
An agent is the right call when you've already nailed the information layer and are now ready to compress workflow. You know the queries you want to handle end-to-end. You know which systems they touch. You know what "done" looks like for each. Now you're investing in workflow automation, not information retrieval — and the timeline, cost, and complexity step up accordingly.
This sequencing matters. Companies that try to build an agent before they've solved the information problem usually end up with neither. The agent stalls because the underlying content and product knowledge isn't structured enough to act on, and there's no bot to fall back on for the questions the agent doesn't handle.
When the answer really is "agent, not bot"
To be clear: there are projects where the agent answer is the right answer, and trying to scope them as a bot is the mistake.
If your customer support cost is dominated by tickets that involve looking something up, executing an action, and confirming — and the action sits behind systems your bot would never have permission to touch — you want an agent. If you're building automation around a specific workflow (sales motion, renewal motion, dispute motion) where the conversation is incidental and the action is everything, you want an agent. If you're explicitly trying to remove humans from a process, not just make their answer-finding faster, you want an agent.
These projects have different economics than bot projects. Longer build, more integration work, more guardrails design, higher value per deployment when they land. Agent work is closer to systems integration than to chatbot work. Sphere does this kind of work as bespoke engagements rather than as productized variants — the use cases are diverse enough that productizing them prematurely would compromise either fit or quality.
The practical recommendation
If you're scoping AI work right now, start with these two questions before anything else:
- Are we trying to move information more efficiently, or are we trying to remove a human from a workflow?
- If the AI does this wrong, what does the recovery look like?
The answers will tell you whether you're shopping for a productized bot or commissioning a custom agent. They'll also tell you what a realistic timeline and budget look like. The most expensive AI mistakes we see happen when projects start without clarity on which of these two things they actually are — and end up halfway between, in scope and in outcome.
If you want to talk through your specific situation, we're happy to do that. We sell both. We're also honest about which one fits — we'd rather sell you the right thing than the bigger thing.
Want to dig deeper? Explore ANSWR — our productized bot family with three deployment variants for websites, catalogs, and SaaS applications. For custom agent work, talk to us directly about your specific workflow.