I turn messy workflows into AI products people actually use.

• Classify. An LLM labels each question factual, philosophical or ambiguous, with a confidence score. Low confidence is downgraded to ambiguous, and ambiguous questions get two short readings side by side, each cited.
• Retrieve. Hybrid search over 5,578 passages from all 18 parvas: BM25 keyword search plus vector similarity (pgvector), merged with Reciprocal Rank Fusion because the two scores aren't on the same scale. A failed search retries with period vocabulary ("siblings" becomes "brothers and sisters").
• Answer. The model writes only from the retrieved passages. Guardrails handle off-topic questions and prompt-injection attempts.

• Cut scope to Q&A. A story-telling mode was specced, then removed to keep v1 focused on one thing done well.
• Changed the architecture after measuring. Self-hosted embedding and re-ranking models needed about 703MB of memory against a 512MB free-tier limit. I moved to an external embeddings API plus pgvector instead of cutting hybrid search or paying for a bigger host. Re-ranking is deferred to v2.
• Chose embeddings on cost and limits. Gemini's free tier would have taken about 6 days to embed the corpus. OpenAI's embeddings cost about $0.07 for all of it.
• Asked for the API key late. The key prompt appears at the first question, not up front, so visitors see value before being asked for a paid key.
• Tested the classifier against real questions. A hand-labeled eval set, and I relabeled rows after live-testing when the model's reading was the more defensible one.

Add a re-ranker once there's a hosting decision for it, run the labeled eval set across all three providers, and tackle modern-dilemma questions (for example, "should I buy more plants?") that need their own validated classifier.

• A hand-written loop, no framework. Each turn the model picks one of four actions: call a tool, ask a question, propose a plan, or stop searching.
• The model decides, code enforces. Code owns the three-question limit, run limits, a plan validator that checks every item and price against real tool results, and a write gate that needs approval for each action.
• Privacy by design. The model never sees addresses or phone numbers.

24 scenarios covering happy paths, missing information, contradictions, infeasible requests, tool failures, mid-run changes and safety. Scoring uses deterministic checks, not another model. Runs passing every check (gpt-5-mini):

• The validator caught three plans that broke a rule. No strategy invented an item or wrote without approval.
• Read it with care. It's one model with three runs per scenario. The first full run scored 65 of 71. I then fixed the prompt and code for three scenarios, so 71 of 71 is tuned, not a held-out score. The whole eval programme cost about ₹161.

• Dropped the "go out" (Dineout) path after finding open tool defects and empty results from every search, and documented why in the requirements.
• Moved a rule from prompt to code. The agent once gave up after two restaurant searches without checking Instamart. Code now refuses to stop searching until both Food and Instamart have been tried.
• Published failures. A scoring bug, a validator rule that never fired and rate-limit noise are all written up in the case study.

• Speak. Press to talk. Sarvam's speech model turns the audio into Roman-letter text, which is what the stores' search understands.
• Understand. A language model decides whether to search, ask a question, offer choices or politely refuse anything that isn't fashion or beauty shopping.
• Search. A small backend queries the stores, groups the same product across them, drops poorly rated items and ranks by lowest listed price.
• Reply. A short generated answer in the chosen language is spoken, while three product cards appear. Code checks every reply: the language, no rude forms of address, and every price spoken must exist in the search results.

Speech recognition on 56 clips I recorded in English and Hinglish, scored against the brands, products and prices in each clip. Agreed spelling variants count as correct:

• The last two score low partly because they return Devanagari for Hinglish, while search needs Roman letters.
• The language model and page logic, on what was meant (21 scripted conversations, three runs): 78 of 78 turns correct. On what the recogniser actually heard: 21 of 26. All five misses were misheard brands (Asics, Van Heusen, Schwarzkopf, Fabindia).
• Read it with care. One speaker (me): 41 clips with a fan running and 15 in a quiet room. With 31 brand mentions, a few points either way is noise. My own floor for brand accuracy was 70% and I have not met it. Dropped words showed up three times, too rarely to estimate a rate. The 78 of 78 comes after two prompt fixes the test exposed, so it is tuned, not held-out, and the pipeline test uses simulated search and voice.

• Dropped a feature to protect the learning goal. Coupons and offers from a deals site needed per-user sign-in and had an unresolved terms question. I cut them so the time went into evaluating the voice pipeline.
• Kept replies generated, not scripted. Scripted sentences would have hidden the Hinglish quality problem. I would rather measure it and fix it.
• Defined what counts as correct for a brand. An agreed spelling variant is fine, a name that could mean two things must trigger a question, and anything else is a miss.
• Made recovery cheap. A type-instead box and a pencil on each spoken message, because brand names were the main failure.
• Bring-your-own-key for the voice service, and a daily cap on the search I pay for.
• Tested it hard myself and wrote up real bugs: a platform tab that spoke and lost the brand, an endless brand question and a wrong-language reply.

Record other speakers, test with real Hinglish shoppers (voice against typing, timed), compare against the stores' own voice search, and add a demo video.