ShareDeal has two audiences who keep asking the same questions: employees ("how do refunds work for partial-fulfilment groups?") and customers ("why was my order split into two deliveries?"). Both questions have the same property — there's a clear answer somewhere in our docs, our SOPs, or our database, and a human is paid to look it up. That's the entire pitch for a knowledge bot.
So I built one. Python, Claude Opus 4.7, Voyage embeddings, ChromaDB. Here's what actually mattered.
1. Two audiences, one bot, two policies
Employees can see SOPs, internal pricing logic and partner contracts. Customers cannot. The bot is the same model and the same retrieval pipeline — but the document filter and the system prompt change based on the caller. One codebase, two trust boundaries. That separation is non-negotiable.
2. Voyage for retrieval, Claude for reasoning
Embeddings get a lot of attention they don't deserve. Most of the heavy lifting is done by the LLM after retrieval, not the retriever itself. Voyage gives me strong, cheap embeddings and that's all I need from it. The interesting work is in chunking, query rewriting, and how I phrase the system prompt for the answering step.
3. Tool use is what makes it useful
Pure RAG can answer "what is our refund policy". Tool use lets it answer "did my refund go through". The bot has access to a small set of typed tools — get_order(order_id), list_recent_refunds(user_id), get_partner(slug) — each of which is a tightly scoped function that hits the real backend with the user's permissions. Claude is great at picking which tool to call and stitching the result into the answer.
4. Prompt caching is the cost story
The system prompt is long — policy, examples, tool definitions, tone. Without prompt caching, every turn pays for that. With caching, the cost drops by an order of magnitude on multi-turn conversations. If you skip prompt caching, you're not really using the platform.
5. The unglamorous parts that decide quality
- Chunking. Legal docs and chat transcripts need different chunk sizes and overlaps. There is no universal answer.
- Query rewriting. The user's first message is rarely the right query. Rewriting it before retrieval is the single highest-leverage thing in the pipeline.
- Citations. Every answer should be traceable to a source chunk. Without citations, you can't tell hallucinations from miss-matches.
- Eval set. A frozen list of 50 real questions with expected answer shapes. Run it on every prompt change. Without this, you're flying blind.
The model is not the moat. The data, the tooling around the data, and the discipline of evaluating on real questions — that's the moat.
What's next
Adding the customer-facing channel into the WhatsApp business surface so support can deflect the easy questions. Most users don't want a chatbot in a tab — they want their question answered where they're already typing. That's WhatsApp, in Bangladesh.