Why We Don't Build General-Purpose Chatbots (and What We Build Instead)

"Can you add an AI chatbot to our site" is the single most common AI request we get, and it's the one we push back on most often. Not because chatbots don't work, but because "general-purpose chatbot for our business" is almost never the right scope for the first AI feature a company should ship, and shipping it anyway usually produces something that looks impressive in a demo and erodes trust in production.

The core problem is scope. A general-purpose chatbot inherits every question a customer might ask, every edge case in your policies, every way your product can be misunderstood, with none of the guardrails a narrower feature can have. You can't build a meaningful evaluation set for "everything a user might ask," which means you can't meaningfully know how often it's wrong before your customers find out for you.

A narrow feature is the opposite in every dimension that matters. "Identify which three clips from this hour of webinar footage are worth publishing" or "flag which product listings need attention based on sales and stock patterns" are tasks with a bounded input, a checkable output, and a clear definition of getting it right. You can build a real evaluation set, a real accuracy number, and a real answer to "how often is this wrong and what happens when it is."

Cost and latency are more predictable too. A general chatbot has to be ready for arbitrarily long, arbitrarily complex conversations, which means provisioning for the worst case on every request. A narrow feature processes a defined input and produces a defined output, which makes token usage, latency, and therefore cost something you can actually forecast and control, instead of a number that surprises you at the end of the month.

Failure modes are the real difference, though. When a narrow feature gets something wrong, it fails in a way you predicted and built a fallback for: a clip gets flagged for human review instead of auto-published, a product recommendation gets scored low-confidence instead of shown as certain. When a general chatbot gets something wrong, it's usually a wrong answer stated with total confidence, in a conversation your evaluation set never anticipated, in front of a customer.

None of this is a blanket "chatbots are bad" position, and we'll say so directly when a chatbot actually is the right tool: a well-scoped internal FAQ bot over a fixed, curated knowledge base with clear escalation to a human is a legitimate narrow feature, not a general-purpose one, even though it looks like a chatbot from the outside. The distinction we care about is scope and evaluability, not the interface.

What we build instead, in practice: AI wired into a specific point in a workflow that already exists, doing one well-defined job reliably, with a human or a simple rule handling the cases it's not confident about. In our webinar distribution pipeline, that's clip and quote identification from raw footage. In ERP work, that's flagging which listings and stock levels actually need a person's attention across a catalog too large to review manually.

The underlying discipline is the same every time: find the smallest, most specific job inside a process a team already does, one you can build a real evaluation set for, and automate that first. It's a less exciting pitch than "we'll add AI to your whole product," and it's also the version that actually ships something your team trusts and keeps using six months later.