Build: Policy assistant

In one line. A chat assistant that answers employee policy questions in plain English and cites the exact policy page — RAG over a Knowledge collection. You’ll build. An HR Policies Knowledge collection, an ingest path for your policy PDFs, a Policy Assistant chat agent wired to the corpus, and a consumer Chat experience that answers with citations. You’ll use. D1 · Collections & schema, D4 · Ingestion & connectors, A3 · Your first agent, E4 · Chat & search experience, E7 · Shaping the experience.

HR fields the same handbook questions all day: “How many remote days am I allowed?”, “What’s the bereavement policy?”, “Which policy covers a sabbatical?”. The answers exist — buried across a dozen PDFs nobody reads. This build turns those PDFs into an assistant that answers in plain English and cites the exact policy page, so employees self-serve and HR stops being a search engine. Budget about 35 minutes plus index build time. You need a project (E1 · Getting oriented), at least one language model registered (A2 · LLMs & services), and your policy PDFs ready to upload.

policy PDFs ── upload / Drive job ──► HR Policies (KNOWLEDGE collection)
                                      intake: slice → index
                                      (a search index scoped to this collection)
                                                │ attach on the agent's Knowledge tab
                                                ▼
                                  Policy Assistant (chat agent)
                                  persona · model · Knowledge = HR Policies
                                                │
                                                ▼  App ▸ Chat
        You: "How many days can I work remotely?"
        Assistant: "Up to 3 days a week … [1]"
          References: [1] Remote-Work.pdf p.3   ◄── the citation

Two halves: the knowledge pipeline (turn docs into searchable knowledge) and the consumer experience (ask, answer, cite). The single wire that joins them — attaching the collection on the agent’s Knowledge tab — is what makes answers grounded and stops the agent leaking knowledge it was never given.

Steps

Stage 1 — Create the “HR Policies” Knowledge collection

A Knowledge collection is the passive corpus category: you don’t decide on each document (no review stages, no field-by-field extraction), you answer over the whole body. That’s the opposite of the Processing collection behind B3 · Invoice settlement. Picking the right category is the most important decision in this build — and it’s permanent.

	Processing (invoices)	Knowledge (policies) — what you want here
Each document…	gets fields extracted, moves through review stages	is sliced and indexed for retrieval
The agent…	works it (a Worker)	reads it (a Reader)
Has a lifecycle?	Yes	No

1. Go to Studio ▸ Data ▸ Collections (D1 · Collections & schema).
2. Click + Collection at the bottom of the list. The General form opens.
3. Purpose: select Knowledge. Collection Name: HR Policies. Description: Company HR policy documents employees can ask questions about.
4. A Knowledge settings group appears (only for Knowledge purpose). It needs a Search model — the model used to index your text; the first available one is preselected and Save is blocked without it. Leave chunk size 2000 and chunk overlap 10 as they are: they control how documents are sliced before indexing, and the defaults suit prose policies.
5. Click Save.

Watch out — category is permanent. Processing vs Knowledge is chosen once, at create time, and afterward shows as a read-only chip. There is no converting later. Pick Knowledge deliberately.

If you don’t see a Purpose selector. Knowledge collections are switched off for your workspace — ask your administrator to turn them on. Everything from Stage 3 onwards still works over an ordinary collection.

A knowledge collection is set up for you — you do not have to define fields. Terms are in the Glossary.

Checkpoint. HR Policies appears in the collection list on the left. Selecting it shows General · Taxonomy · Lifecycle · Tags · Events · Ingestion · Agents — plus an Index Health tab, which only knowledge collections have.

Stage 2 — Ingest the policy PDFs

Two routes from D4 · Ingestion & connectors; for a one-off policy library, Upload is fastest.

Quick path — Upload (recommended for a fixed library):

1. From the HR Policies collection, open its Ingestion tab (or Studio ▸ Data ▸ Ingestion).
2. Click Upload in the toolbar.
3. Drag-drop your policy PDFs (Remote-Work.pdf, Leave-Policy.pdf, Travel-Policy.pdf, Code-of-Conduct.pdf, …). Each shows its size with a remove control.
4. Confirm Target collection = HR Policies (pre-filled when you launched from the collection).
5. Click Submit. The result panel reports “N of M registered”, the run id, and a per-file breakdown. Click Done.

Recurring path — a Drive job (for a library that grows): if HR drops updated PDFs each quarter, wire a recurring pull instead (D5 · Drive & datasheet for Drive as a staging area): + Connector ▸ Botminds Drive, then + Job scoped to the policy folder, Target collection = HR Policies, schedule Recurring or On-demand. Dedup (the Dup counter) means re-runs are safe.

What ingest does here. A Knowledge collection doesn’t extract fields. It slices each document into overlapping passages and adds them to the collection’s search index. Every passage is tagged with the collection it came from, so an agent can only ever retrieve from the collections you attached to it — a corpus it was not given is invisible to it. That scoping is also why a 100-document and a 100,000-document corpus answer just as fast.

Give the index a moment. Uploaded documents are chunked, embedded and indexed automatically — but on a large library that is not instant. Watch the collection’s Index Health tab (D6 · Search, indexes & vectorization): it shows each document reaching a ready state and a readiness chip (e.g. “141/146 ready”). Wait for that before you promise employees an instant answer.

Checkpoint. Your PDFs appear as documents in HR Policies with a Processing… chip that climbs to 100%, and the Index Health tab shows each document reaching a ready state. If a document sticks at 0%, processing has stalled — see D4 · Ingestion & connectors.

Stage 3 — Build the “Policy Assistant” chat agent

The corpus exists; now build the Reader that answers over it, in the agent editor from A3 · Your first agent.

1. Go to Studio ▸ Agents ▸ Agent Toolkit ▸ Agents. Click + Agent ▸ Agent — the tabbed editor opens beside a live Playground.

2. Persona tab — who the agent is. Name: Policy Assistant. Description: Answers employee questions about HR policies, with citations. For Instructions (the system prompt — the soul of the agent), use the field co-pilot to draft, then edit to roughly:

   You are the HR Policy Assistant. Answer employee questions **only** from the attached HR
   policy documents. Quote or paraphrase the relevant policy and **always cite the source
   document and page**. If the policies don't cover the question, say so plainly and suggest
   they contact HR — never guess or invent a policy.

3. Model tab — what powers it. Pick your project’s language model. Set Agent Mode = Thinking while you tune (you’ll watch its retrieval reasoning); flip to Fast for production later. Leave Advanced sampling at defaults.

4. Knowledge tab — the load-bearing step. Open the Knowledge collections sub-tab and attach HR Policies. A readiness chip beside it (e.g. “141/146 ready”) tells you the index is built and the agent can actually retrieve. Then consider the two locks: turn Knowledge lock on so the agent answers only from attached knowledge (no model-memory freelancing — exactly what you want for policy), and leave Exact-match lock off (you want semantic matching, so “WFH” finds “remote work”).

5. Capabilities / Output / Governance tabs — leave at defaults. This is a read-and-answer agent: no Structured-output schema (that’s for extraction agents), no tools, no guard rails to start.

6. Click Save Agent.

Watch out — the number-one “why won’t it answer or cite?” mistake. Skip the Knowledge-tab attachment and the agent has nothing to read: you get vague, source-less, un-citable answers, and it may fall back on the model’s own general knowledge. No attachment = no retrieval = no citations. Check the Knowledge tab first. The scoping is also your security boundary — an agent sees only the collections explicitly attached here.

If you don’t see the Knowledge collections sub-tab. Knowledge collections are switched off for your workspace — ask your administrator. You can still attach knowledge as a View over a collection, on the same tab; retrieval and citation behave identically, only the attach control differs. See A3 · Your first agent, Knowledge tab.

Don’t confuse the two agent-to-collection relationships: a Worker (intake agent) runs on each document and is set on the collection’s Agents tab; a Reader answers over the collection and is set here, on the agent’s Knowledge tab. A Knowledge collection wants a Reader.

Checkpoint. In the editor’s Playground, set Input Type = Text, ask “How many remote days are allowed?”, and press Enter. You should see it retrieve and answer with a reference back to the policy doc. If the answer is vague or uncited, re-check step 4.

Stage 4 — Configure the Chat experience

A working agent isn’t a product until end-users can find and use it. Configure the consumer Chat channel (E7 · Shaping the experience).

1. Go to Studio ▸ Experience ▸ Channels ▸ Chat. The page has its own tabs — General, Audit, Feedback. Stay on General.
2. Default Questions — add the prompts employees actually ask, as one-click starters: How many days can I work remotely? · What's our bereavement-leave policy? · Which policy covers a sabbatical? · How much notice do I give to resign?. Drag to reorder; tick Pin default questions so they stay visible on an empty chat.
3. Chat Greeting Text: Hi — ask me anything about our HR policies. I'll point you to the exact policy and page.
4. (Optional) Chat Placeholder: e.g. How many sick days do I get?
5. Leave Hide Chat References off — references (the citation chips) are the whole point here.
6. Save. The unsaved-change red dot clears on a successful save.

Default questions are the cheapest UX win on the platform — they double as documentation and a demo script. Write ones whose answers you’ve already verified in the Playground, so a first-time user’s first click always lands a clean, cited answer.

Checkpoint. Your four starter questions are saved and pinned, and the greeting is set.

Stage 5 — The end-user experience: ask, read citations, give feedback

Now use it as an employee would (E4 · Chat & search experience).

1. Open App ▸ Chat. The empty chat shows your greeting and the pinned starter questions.
2. Click a starter — e.g. “How many days can I work remotely?” — or type your own.
3. Watch the thinking… footer: the agent matches your question against the HR Policies index and composes an answer from the passages it retrieves. Expand the Agent Build Log to watch each step.
4. Read the streamed answer and the References block beneath it — [1] Remote-Work.pdf p.3.
5. Click a reference chip. The source policy opens at the exact cited page so the employee can verify the claim themselves. This round-trip back to the source is the entire value of the solution — the answer is grounded, not invented.
6. Click a follow-up chip (or ask one) — “Does that apply to contractors?” — and notice the assistant remembers the thread.
7. Give the answer a thumbs-up or thumbs-down. That feedback is recorded for you, the builder, on the Feedback tab of Studio ▸ Experience ▸ Channels ▸ Chat (E7 · Shaping the experience).

The reference chip isn’t decoration — it is the actual passage the agent retrieved from this collection. The agent answered from that passage; the chip is the receipt. That’s the difference between this and a generic chatbot.

Checkpoint — the success condition for the whole build. You asked a policy question in chat and got a cited answer pointing back to the source policy page. That’s a Policy assistant.

Stage 6 — Test it

A two-minute acceptance pass — confirm the load-bearing behaviour, not just that it talks:

1. Grounded and cited. Ask “What’s our remote-work allowance?” — expect a specific answer with a [1] reference chip. Click it — it opens the right policy at the right page.
2. Honest refusal. Ask something the policies don’t cover — e.g. “What’s the pet-bereavement policy?” — with Knowledge lock on, the agent should say it’s not covered and point to HR, not invent one. If it invents an answer, re-check the Knowledge lock and the “answer only from attached knowledge” instruction in Stage 3.
3. Scoping, no leakage. Ask about a topic that lives in a different collection in your project (e.g. an invoice detail) — the Policy Assistant should not answer it. Its world is exactly the HR Policies you attached.
4. Conversation memory. Ask a follow-up that depends on the previous answer — it should resolve the pronoun correctly. Then + New chat and ask the follow-up alone — now it has no context.

If all four pass, the assistant is grounded, honest, scoped, and conversational — ship it.

Make it production-worthy

• Add structured answers. Retrieval is great for “explain it to me”, but “which policy covers sabbaticals, and who owns it?” is a table lookup. Add a small Learner on the collection’s Taxonomy tab with Labels like policy_name, topic, owner_department, effective_date, applies_to (D1 · Collections & schema); build a View surfacing those columns on Studio ▸ Data ▸ Views; on Studio ▸ Data ▸ Datasheets click + Datasheet and point it at that View (D5 · Drive & datasheet); then give the agent a SQL tool bound to that Datasheet (A5 · Tools & functions). One chat then handles both shapes: “explain the remote-work rules” reads the policy passages and cites the page; “which department owns the travel policy?” runs a SELECT.
• Scope by department. If not every employee should see every policy, split the corpus: one Knowledge collection per sensitivity tier (e.g. HR Policies — General vs HR Policies — Manager) and a chat agent per audience, each attaching only its tier. Retrieval is scoped by the attached collection, so a general-audience agent cannot surface manager-only policies — the attachment is the access boundary. Then give each audience a persona on Studio ▸ Governance ▸ Users & Access ▸ Personas and scope it to the collections that audience may read.
• Know where access is actually decided. Studio ▸ Governance ▸ Users & Access is the one page that answers “who can use this assistant?”. People lists everyone in the project and the personas they hold. Personas is where you create each audience role and choose the collections and stages it covers. Effective policy is a read-only summary of the rules your workspace set — how people join, whether you may add someone yourself, and who to ask when you may not. If a colleague cannot open the assistant, start there. Full tour: G1 · Access & roles.
• Starters per audience. Pair each scoped agent with its own Default Questions (E7 · Shaping the experience) so each audience lands on the prompts they actually ask.
• Reusable shape — “ask-my-documents”. Knowledge collection → ingest → attach on the Knowledge tab → tune Chat settings → cited chat. Re-skin it for a product manual, an FAQ corpus, an SOP library, contract clauses — the build is identical; only the documents change.

Where to go next

• B2 · Enterprise data Q&A — the structured sibling: the agent writes SQL over a Datasheet instead of quoting passages.
• B6 · SEC filings analyst — read a stream of public filings and surface the few things that matter.
• The Search pattern — the capability ladder this build sits on.