Behind the voice on this site is a text problem: given a stranger's question — "what did Mayank actually do at theAsianparent?" — produce an answer that is specific, accurate, and sounds like a person. That means deciding what the model knows, how it looks things up, and what it's forbidden from inventing.
The knowledge base
The raw material is a brain dump: a ~2,600-line markdown document containing three full case studies (Mama's Choice, theAsianparent verification, RansahAI), second- and third-order analysis, and six narrative threads about how my career fits together. Plus structured JSON: facts, projects, and a career timeline.
At startup, a chunker splits every markdown source on H1/H2/H3 headings. Each chunk carries its heading and, importantly, its parent H1 — so a detail buried on "Page 7 — User Research" still knows which case study it belongs to. Fragments shorter than about 40 characters get merged upward rather than becoming noise.
Retrieval: keyword search today, vectors next
Search today is unglamorous: in-memory keyword scoring. Exact whole-word matches score points, substrings score half, chunks from curated MDX case studies get a quality boost, and a query term appearing in a chunk's parent heading gets a bonus — that last bit anchors answers to the right case study.
This is deliberately boring. The function's return shape is frozen so that when I swap in pgvector on Postgres, only the implementation changes — the brain layer and the API route won't notice. Embeddings will fix the real weakness of keyword search: synonyms. Ask about "hiring funnel" today and you only find chunks that literally say it.
Most answers never touch retrieval
Retrieval is a fallback, not the default. The system prompt inlines a compact profile block — identity, contact, location, every project with its headline metric, tools, career narrative — budgeted at roughly 700–850 tokens. That covers the large majority of recruiter questions in a single round trip, no tool call, lower latency.
The model gets two tools for everything else: lookupFacts for structured data (full timeline, project detail) and searchKnowledge for the chunked notes. It's capped at three tool steps, because deeper chaining added a second or two of latency without improving answers.
Prompting a concierge that represents a real person
The prompt does more work than the retrieval. The rules that matter:
- Third person, always. The concierge speaks about Mayank — "Mayank built...", never "I built...". It's an assistant representing me, not a deepfake of me.
- No fabrication, with an exit. Every metric, date, and company name must come from the profile block or a tool result. If the answer isn't there, the model says so and points to my email. A confident hallucination about my career is worse than no answer.
- Spoken constraints. Two to four complete sentences, no markdown, numbers spelled out, and never trail off mid-thought — because this text gets synthesized into audio, and a sentence fragment sounds broken out loud.
- Fail over, not down. Requests go through OpenRouter with a small chain of fallback models; on a rate limit before any text streams, the next model takes over.
Where it fails
Honestly: keyword search misses paraphrases, as noted. The 450-token output cap occasionally clips a genuinely good longer answer. And the third-person voice, while correct, sometimes reads stilted when someone asks something personal.
But the failure mode I'm proudest of is the boring one: when the concierge doesn't know, it says it doesn't know. For an AI representing a real person's career, that's the whole game.