The chatbot on your website is not an AI strategy
A widget that answers FAQs satisfies the mandate and changes nothing. What an actual AI strategy looks like — from a company that sells chatbots.
Somewhere in your company, probably this quarter, someone will present a slide that says the AI initiative is on track. The evidence: there's now a chatbot on the website.
Here's an uncomfortable exercise. Ask three questions about that chatbot:
- What work does it actually complete, end to end?
- Can anyone show you a trace of what it said to customers last Tuesday, and why?
- If the vendor doubled the price tomorrow, could you take the logic and leave?
For most companies the honest answers are: not much, no, and absolutely not. That's not a strategy. That's a checkbox with a monthly invoice.
And here's the part that should make you trust this argument a little more: we sell a website chatbot. It's called letchat.ai, it's built on our platform, and we will happily deploy it for you. We're still telling you it is not a strategy. A chatbot can be the first move of a strategy — but only if it's built on the right foundation. Let me draw the difference.
Why the chatbot-first play feels so good
The chatbot is the most popular answer to the "adopt AI" mandate for understandable reasons. It's visible — the board can click on it. It's contained — it can't break production. It's fast — a vendor can have it live in a week. It produces a metric — "deflected conversations" — that goes up and to the right.
Every one of those virtues is also why it changes nothing. It's visible because it's on the surface of the company, not in the work. It's contained because it's disconnected from your systems. It's fast because it's shallow. And "deflection" is a metric about avoiding conversations, not doing work.
Meanwhile the actual operations of your company — engineering, ops, finance, the back office, the real support queue — run exactly as they did in 2022.
The three failures of chatbot-as-strategy
It's one surface. Your company doesn't work in a chat widget. It works in terminals, repos, browsers, inboxes, Slack channels, internal APIs. An AI strategy that only touches the website has opted out of every place where labor actually happens. The question isn't "can AI answer questions on our site" — it's "can agents do recurring work across the surfaces where work lives?"
It's invisible and ungoverned. Most deployed chatbots are black boxes. You see the transcript, maybe. You don't see the reasoning, the retrieval, the tool calls, or the failure modes. There's no approval gate between the model and your customer. When it says something wrong — and it will — you find out from the customer. A system with direct customer contact and no oversight isn't an asset; it's an incident that hasn't happened yet.
It's rented. The prompts, the knowledge wiring, the conversation logic, the data — they live inside the vendor's product. You can't read the logic, version it, or move it. Two years in, the chatbot is load-bearing for your support flow and the switching cost is enormous. You didn't buy a capability; you leased a dependency.
What an actual AI strategy looks like
Strip away the buzzwords and an AI strategy is three commitments:
1. Agents do real work, not just conversation. The bar isn't "answers questions." The bar is: closes the tier-1 ticket, triages the incident, drafts the reply and files the follow-up, runs the weekly report, does the boring backlog. Work you would otherwise pay a human hour for.
2. Every agent is observable and governed. You can watch each action an agent takes — the trace, not a summary. Risky operations require explicit human approval. Customer-facing replies can run in draft-and-confirm mode until the agent has earned autonomy. Secrets are redacted before anything leaves your infrastructure. This is what lets you expand what agents do instead of freezing at the pilot.
3. You own the logic and the data. The agent's behavior lives in files you can read, version, and take with you. Your API keys are your own. You can self-host. The leverage compounds inside your company, not inside a vendor's valuation.
Notice that a chatbot fits comfortably inside this strategy — as one deployment of one agent on one surface. That's the correct size for it.
The chatbot, done as a first move
Here's the version of the chatbot play we'd actually defend — it's how we built letchat.ai on top of rysh:
- The chatbot is an agent on an engine, not a standalone product. The same engine that answers your website runs agents in your terminal, your browser automations, and your email and Slack channels. Deploying the chatbot means you've deployed the platform — the second and third use cases don't start from zero.
- The logic is a markdown skill file — readable, versioned in git, portable. Change the agent's behavior with a pull request, not a support ticket.
- It's governed: human takeover is built in, and the same approval machinery that gates a destructive shell command gates whatever you decide is risky.
- It's yours: self-hostable, running on Claude with your own API key. Your data doesn't become someone else's training asset or retention liability.
Same widget on the website. Completely different position underneath it. One is a decoration; the other is the first workflow of an AI-native company — with the second workflow already cheap to add.
The question to bring to your next AI review
Don't ask "do we have AI?" You do; everyone does. Ask: "what work did agents complete for us last week, can we see exactly how, and do we own the way they did it?"
If the answer is a deflection percentage from a widget, you have a coat of paint. The mandate deserves better — and the gap between you and the company that took it seriously is compounding weekly.
We're taking on a handful of design partners — companies that want to start with one real workflow (yes, the chatbot counts) and build toward AI-native on a foundation they own. If that's you: rysh.ai/design-partner.
Related: What it actually means to be an AI-native company · letchat.ai vs Intercom Fin