botminds.aiRequest a demo

Academy · Solutions · Agentic Search

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 LLM registered (A2 · LLMs & services), and your policy PDFs ready to upload.

policy PDFs ── upload / Drive job ──► HR Policies (KNOWLEDGE collection)
                                      intake: chunk → embed → index
                                      (scoped vector index, entity_id)
                                                │ 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.

Honest status — read before you start. The Knowledge-collection category is a shipped release feature (knowledgeCollections, default on); an environment can disable it as a kill-switch. The part still maturing is auto-vectorise-on-ingest: the design is settled (a system-seeded “knowledge spine” that chunks, embeds, and indexes every document), but the wiring may not run in every build. What is shipped and load-bearing today: (1) attaching a corpus on a chat agent’s Knowledge tab, and (2) the chat-with-citations consumer experience — scoped retrieval, grounded answers, reference chips back to the source page. Every step below that leans on a not-yet-fully-shipped piece carries its status and a shipped fallback, so you still finish with a working, citing assistant.

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 chunked, embedded, indexed for retrieval
The agent… works it (a Worker) reads it (a Reader)
Has a lifecycle? Yes No
  1. Go to Studio ▸ Data Model ▸ Collections (D1 · Collections & schema).
  2. Click + Collection (rail footer). 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). Leave the defaults: Embedding model (your project default), chunk size 2000, chunk overlap 10. These control how documents are sliced before embedding — defaults are fine for 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.

Status. The Purpose = Knowledge switch and the Knowledge settings group ship behind the knowledgeCollections release flag, default on. If you don’t see a Purpose selector, the environment has disabled the category; use the fallback at the end of Stage 2 — a plain collection plus a chat agent still gets you citations.

The UI says Collection; the API and URL still say Entity / EntityId. A Knowledge collection needs a Learner under the hood even without structured fields — the platform seeds one. Terms are in the Glossary.

Checkpoint. HR Policies appears in the left rail. Selecting it shows a tab strip; for a Knowledge collection that strip includes an Index Health tab (flag-gated) that a Processing collection doesn’t 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 ▸ Connector ▸ 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 docId / error 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.

Under the hood. For a Knowledge collection, intake doesn’t extract fields — it runs the “knowledge spine” pipeline: resolve blob → extract text → chunk (~2000-char overlapping slices) → embed (batches of ~16 chunks) → index. Each chunk carries {entity_id, knowledge_collection:true} metadata, and that entity_id tag is the whole game: at question time, retrieval is filtered to only this collection’s chunks, so an agent can never surface knowledge from a corpus it wasn’t given — and a 100-doc and a 100,000-doc corpus answer just as fast.

Status — the partly-forward-looking part. The automatic chunk-embed-index on ingest is still rolling out; the operator behind it is implemented but not shipped in every build. Do not assume a freshly uploaded policy is instantly answerable. If the pipeline is live, the collection’s Index Health tab (D3 · Taxonomy, lifecycle, tags & events) shows the index building and a readiness chip (e.g. “141/146 ready”) — wait for it. If it isn’t wired yet, the shipped fallback is to build the chat agent (Stage 3) over the project’s existing search index: retrieval and citations behave the same regardless of which path filled the index. Don’t promise end-users “instant” until your build’s Index Health confirms it.

Checkpoint. Your PDFs appear as documents in HR Policies with a Processing… chip that climbs to 100%. With the flag on, the Index Health tab shows each document reaching a ready state. If a doc sticks at 0%, the background worker likely isn’t running (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 ▸ Agent Builder ▸ 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 LLM 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 leak from the model’s own training. 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.

Flag-gated. The Knowledge collections sub-tab is gated by the same knowledgeCollections flag. With the flag off, attach knowledge via a View over the collection instead (also on the Knowledge tab) — retrieval and citation behaviour are identical; 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 surface (E7 · Shaping the experience).

  1. Go to Studio ▸ Chat ▸ 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 embeds your question, runs a scoped nearest-neighbour match against the HR Policies index, and composes an answer from the retrieved passages. 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, to review in Studio ▸ Chat ▸ Feedback (E7 · Shaping the experience).

The reference chip isn’t decoration — it’s the actual passage the agent retrieved, tagged with this collection’s entity_id. 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. Vector 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 Schema tab with Labels like policy_name, topic, owner_department, effective_date, applies_to (D1 · Collections & schema); build a View surfacing those columns (E7 · Shaping the experience); in Studio ▸ Data Model ▸ Data 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” hits the vector index and cites the page; “which department owns the travel policy?” runs a SELECT.

    Status. A Knowledge Schema that auto-extracts structured fields during knowledge ingest is part of the same forward-looking design. The shipped fallback is fully real: build the View and Datasheet yourself and bind a SQL tool.

  • 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. Gate who can open each agent’s chat with Access Roles (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

Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.

See the platform live