Botme: AI agents that do more than chat

The problem

Most “AI chatbot” widgets are a thin wrapper around an LLM with a system prompt that says “answer questions about our product.” They sound confident, they’re often wrong, and they can’t actually do anything - a customer asking “where’s my order?” or “can I book a call for Thursday?” just gets a polite non-answer.

Botme is built to close that gap: an agent that knows your content, and can take real actions on your site.

What I built

Every Botme chatbot starts with a knowledge base - PDFs, DOCX files, or scraped pages get chunked and embedded into Pinecone, with each chatbot living in its own isolated namespace so one customer’s data can never leak into another’s answers.

From there, each bot can be given “superpowers”:

• Lead capture forms with Cloudflare Turnstile protection, so the bot can collect contact details mid-conversation
• Calendar booking - a two-phase confirmation flow against Google Calendar, so a visitor can actually reserve a slot, not just be told to “visit our booking page”
• Order tracking for WooCommerce stores, verified server-side so the bot can answer “where’s my order” without ever exposing other customers’ data
• Custom action buttons for things like policy links or escalation to a human

To keep it affordable to run, Botme has a smart answer cache - both exact-match and semantic - so repeated questions don’t re-hit the LLM, with the savings passed back to the business owner rather than billed per query.

Why these choices

Built on Next.js with the Vercel AI SDK, which made it straightforward to support both OpenAI and Google’s models behind the same streaming interface - useful for cost and latency tuning per customer. LangChain handles the retrieval-and-tool-call orchestration, MongoDB stores chatbots and conversations (the schema needed to flex a lot during early development) while Pinecone is used to store vector embeddings, and Redis + BullMQ handle rate limiting and background work. Billing runs on Stripe with atomic credit reservation so usage and payments can’t drift out of sync under concurrent requests.

The security work

Giving an AI agent the ability to act - book meetings, look up orders - means thinking hard about how that ability could be abused. A few things that ended up mattering most:

• Ten layers of request validation on every chat message: trusted IP resolution, per-IP rate limiting, conversation-token binding, origin checks, cost controls, and SSRF protection
• Conversations are identified by non-guessable 48-character hex tokens, compared in constant time to avoid timing attacks
• The order-tracking tool returns the exact same failure message whether an order doesn’t exist or the email is wrong - otherwise it becomes an enumeration oracle
• Booking confirmation tokens are single-use, server-validated, and expire after an hour

None of this is visible to end users, but it’s most of why the project took as long as it did.

What’s next

More integrations (other calendar and e-commerce platforms).