What this prompt does
This prompt asks the model to act as an AI engineer designing a retrieval-augmented internal knowledge assistant for a given [company_type]. You supply the [stack], the knowledge [sources], and the [access_model], and it returns a concrete architecture, the system prompt, and a code sketch for the retrieve-to-rerank-to-answer path — explicitly not a vendor pitch.
The structure works because it covers the unglamorous parts that decide whether a RAG assistant is trustworthy. Ingestion is defined per source from [sources] (connectors, chunking, embeddings, re-index cadence); retrieval is hybrid with re-ranking and clickable citations; generation is grounded with an "answer only from context, otherwise say you don't know" rule. The [access_model] drives role-based filtering so people only see what they're allowed to, and operations adds a usage dashboard and an eval set. Because the prompt insists on a concrete architecture and a code sketch rather than a vendor pitch, you get an implementable shape for the retrieve-rerank-answer path instead of generic RAG theory.
When to use it
- A company wants to stop pinging the same few people for the same answers.
- You need RAG grounded in citations, not a model that confidently makes things up.
- You have multiple knowledge
[sources]needing different connectors and re-index cadences. - You need role-based access so eng, sales, support, and exec see only their content.
- You want a usage dashboard tracking top questions, deflection, and thumbs-down review.
- You want an eval set in place to catch retrieval and answer regressions.
- You want permissions designed in from the start rather than bolted on later.
Example output
Expect a text architecture diagram of the pipeline, the full system prompt with grounding and follow-up rules, and a code sketch for the retrieve -> rerank -> answer path on your [stack]. Around that, you'll get the ingestion plan per source, the hybrid retrieval and citation design, the governance and PII handling tied to [access_model], and the operations layer with a dashboard and eval set.
Pro tips
- Lock down the
[access_model]early — retrofitting permissions onto an existing RAG index is painful and risky. - Describe each of your
[sources]honestly so chunking and re-index cadence fit how each one actually changes. - Set
[stack]to your real components (e.g. Next.js, a vector DB, a chosen model) so the code sketch is usable, not generic. - Insist on the grounding rule: an assistant that fabricates answers is worse than no assistant at all.
- Make citations clickable source links from the start; bolting them on after retrieval is built is harder than it looks.
- Ask for the eval set up front so you can measure regressions instead of discovering them from user complaints.
