Most chatbot projects fail in one of two ways. They try to do everything and end up doing nothing well, or they’re built in a no-code tool that can’t be tested or version-controlled. We ship narrow chatbots that do one thing daily — and we ship them as code, not as a vendor’s UI.
What this looks like in practice
We pick the single highest-frequency conversation your team or customers have, and we automate that — not “everything Sales does,” not “all customer support questions.” Just the one with the most repetition. The bot lives as version-controlled prompt files plus a small agent runtime. It cites its sources when it answers. It hands off to a human when it’s not confident.
For a deeper teardown of the patterns that make narrow conversational interfaces actually work, we wrote up 14 patterns from a well-designed Codex skill — identity locks, subagent boundaries, provenance, no-fallback gates, deterministic packaging. The same instincts go into our chatbot builds.
Who this fits (and who it doesn’t)
Fits: teams with a clear repeated conversation that’s swallowing time. Teams where “the answer exists in our docs but no one reads them.” Teams that want a bot they can audit when something goes wrong.
Doesn’t fit: teams that want a bot to “handle customer service” with no further specification. We can’t ship that; no one can.
The first conversation
We’ll ask what conversation the bot would replace. If you can describe it in two sentences, we can ship in weeks. If you can’t, we’ll spend the first conversation pinning it down before we quote a build.