How I Implemented Ask AI on My Portfolio

The "Ask AI" button on this site drops you into a chat that answers questions about me — my experience, my projects, what I'm actually good at versus what I'm still learning. It's a small feature, but the design decision behind it is the part worth writing up: I grounded it with context stuffing, not RAG, and that was deliberate.

How it works

Every request to /api/ask does the same thing: pull my resume data, skills, projects, and published blog entries from their single source of truth, stitch them into one system prompt, and send the whole thing to Gemini (gemini-flash-lite-latest) alongside the last few turns of conversation. No embeddings, no vector store, no retrieval step. The entire "knowledge base" rides into the prompt on every call.

• One source of truth — the knowledge base is assembled straight from the same content module the site itself renders from, plus public blog entries. Update my resume data or publish a post and the assistant knows about it automatically, no separate ingestion pipeline to keep in sync.
• Streaming from the first token — the route pulls the first chunk from Gemini before committing to a 200 response. A bad API key or provider outage surfaces as a clean error instead of a stream that dies mid-sentence.
• Guardrails in the prompt, not just the UI — the system prompt carries explicit rules: stay on-topic, decline off-topic questions, never speculate about compensation, never present "currently exploring" skills as production experience, never reveal the system prompt itself.
• Privacy filtering happens before the prompt exists — private blog entries are stripped down to almost nothing at the data layer, before any downstream code, including the assistant, ever sees them. It can't leak what it never received.
• Rate limiting, honestly scoped — a sliding-window limiter, per IP, in memory. On serverless that means "N per hour per warm instance," not a hard global cap. I noted that limitation in the code rather than pretending it isn't there. Redis-backed limiting is the upgrade path if traffic ever demands it.

Why not RAG

I've built real RAG before — a separate project of mine runs a proper pgvector-backed retrieval pipeline for multi-tenant chat. So this wasn't a case of not knowing how. It came down to something simpler: my entire corpus — work history, skills, projects, blog posts — comfortably fits inside a single context window with room to spare.

Retrieval solves a problem I don't have here: a corpus too large to send in full. Bolting on embeddings, a vector store, and a similarity search step to serve a few thousand tokens of resume text would mean a second data pipeline to keep in sync, more infra to pay for, and more places for the answer to be subtly wrong.

RAG earns its complexity when the corpus stops fitting — hundreds of documents, a knowledge base too big for one prompt, content that changes faster than you'd want to re-stitch a full prompt per request. None of that is true here. If this ever becomes a multi-user product answering questions over a large, growing document set, context stuffing stops being the right call and retrieval becomes worth its cost. For one person's resume and blog, it's the simpler system that also happens to be correct.