Ask: policy search.

An employee should not have to figure out where to go.

One front door.

Ask, and see where the answer came from.

One front door. This chapter is the search behind it.

This agent calls no tools at all: the access filter, the passage, an answer from it. Nothing in this chapter writes to any system, which is why search can sit in front of everything else. It is the safe first thing to ship. The agents in 02, 03 and 04 do the acting.

1. You sign in once.

   Through the company's sign-in. The assistant learns who you are, where you are based, and which groups you belong to. In the demo, a persona switch stands in for this and keeps the same groups.

2. You ask.

   "Can I carry over unused PTO?" The orchestrator sees a question rather than a request and sends it to search. Had you typed "I want to book a vacation," it would have gone to the time-off agent instead. You never choose.

3. Search checks what you can see, before it searches.

   The library is filtered to your groups first, then searched by meaning, or by the question's own words when it is too short to search by meaning. Filter after searching and the model has already seen what it shouldn't. Filter first and it fails closed. This is the one decision the whole chapter hinges on.

4. You get the passage, the source, and the reason.

   The answer is the policy text itself, the section it came from, and the line "Checked access · 6 documents apply to you." When nothing you can see covers the question, it says exactly that, with no hint of what else exists.

5. Sometimes the right answer is a person, and no record.

   A harassment report, a retaliation claim, someone in crisis: the stop rule catches it before anything is searched. It names the ethics line, the HR business partner and the EAP, and offers to bring that person into this window. It writes no ticket and keeps no account of what was said, because a narrative like that has no business sitting in a ticket table that IT support can read. A pay dispute or an accommodation request is different: there the assistant explains how the process works and who owns it, and decides nothing.

Where the policies come from.

Every connector produces the same three things per document: the text, the list of groups that may read it, and a few facts such as country and last updated. That is all the index ever needs, whatever the source. The identity provider, Entra ID or Okta, is where the groups on both sides get their names.

One connector, built for real: Google Drive over MCP.

The table above is a design. This part is not. The ten policies also live in a real Google Drive folder, and a connector reads them the way a production one would: it asks a Google Drive MCP server for the files in the folder, reads each one, and reads each file's sharing settings. The sharing settings become the document's access list. Nothing is typed in by hand. If HR shares a document with one more person in Drive, the next sync picks that up, and that person can find it.

Two things had to be true for this to count. First, the connector is a real MCP client. It speaks the protocol over the server's standard input and output, and the same code runs against any Drive MCP server that exposes list, read, and permissions tools. Second, the demo could not rely on my own access. So the sync runs as the account that owns the folder, and the check below asks as each account Drive granted, and as one it did not.

Synced from the Drive folder through the Google Drive MCP server: 10 documents, 13 passages. Sharing settings were read from Drive, not typed in.

Then the check. For every account Drive granted, plus one it never granted, ask seven questions that between them touch every document, and confirm nothing comes back from a document that account may not open.

No document was retrieved for anyone Drive had not granted. The report itself is published here and regenerated by scripts/drive_sync_report.py after every sync.

What I learned building it. Google Docs come back from the server with markdown escaped, so a heading arrives as \#. A four-line cleanup fixes it, and without it the passages index badly. A personal Drive has no groups, only people, so the demo grants are to individual accounts. A company Drive would share with groups, and the connector already maps a group grant to a group on our side, the same name Entra ID would give it. And the folder's owner can open everything, which is right for the account that runs the sync and wrong for an employee, so the owner is a separate line in the check rather than a persona.

The connector is rag/connectors/mcp_drive.py in the demo repository. It has two entry points: a live sync that spawns the server, and a manifest path for a client that already has Drive connected. The demo index on the public site is still built from the local folder so every persona keeps working; switch the ingest flag and it is built from Drive instead.

What has to be true, and how I check it.

One number: the question that never becomes a ticket.

Personas are a better nav than features.

1. Organize by who's asking, not by domain.

   The first rail grouped things as Ask, Do, Decide, Oversee. It read well and meant nothing to an employee. Approvals and the org view are steps in the time-off flow, so that's where they live now, and the persona decides which steps you see.

2. Search is a capability, not a destination.

   I had "Policy search" as its own entry for a week. Nobody picks a use case called search. They ask a question. Folding it into Ask made the routing the showcase instead of the menu.

3. Filter first, then retrieve.

   You can search everything and hide what the person can't see, or hide it first and search what's left. They sound the same. Only the second fails closed, and in security the direction of failure is the whole game.

4. Never show a lock.

   The first version listed locked documents with a padlock, and the trace said "4 of 6 documents visible." It looked like a security feature. It was a leak. Now nothing outside your scope is named, flagged, or counted, anywhere. The demo got less flashy and more honest.

How to build this yourself.

1. Write a one-page spec, then start with the riskiest question.

   Not the whole thing. One page: who asks, what each of them may see, which actions write and which only read, and what must never happen. Then build the thinnest version that proves the one thing that could sink it: a user can never retrieve content they can't access.

   Prompt

   Here are the people who will use this and the documents they may see. Write a one-page spec: users, what each may read, what must never happen, and the one test that would prove a leak. Then help me build the thinnest version of permission-aware RAG that proves one thing: a user can never retrieve content from a document they can't access. What's the smallest test that would prove or break that?

2. Model access as a list on every chunk.

   Attach who-can-see-this to every chunk. Retrieval returns chunks, so the check has to live there, and the document alone is too coarse.

   Prompt

   Design a small access-control model I can attach to every chunk, plus one function that decides whether a given user may see a given chunk.

3. Filter before you retrieve.

   Apply the access check to the candidate set before ranking, so restricted chunks are never scored or returned. Filtering after retrieval fails open.

   Prompt

   Apply the access check to the candidate set before ranking, so restricted chunks are never scored or returned, and explain why filtering after retrieval would be unsafe.

4. Ground the answer and let it abstain.

   The model uses only the retrieved chunks, cites the source, and says "I don't have that" when nothing relevant came back.

   Prompt

   Write the answer step so the model uses only the retrieved chunks, cites the source, and abstains when nothing relevant came back.

5. Build the first connector.

   Start with wherever most policies actually live, usually SharePoint. A connector does three things and nothing else: read the text, read who may open the file, and note a few facts such as country and last updated. Then it asks only for what changed. Everything downstream is the same whether the source is SharePoint, ServiceNow, or Workday, so the second connector is a copy of the first with a different API behind it.

   Prompt

   Design a SharePoint connector that returns, per document, the text, the groups allowed to read it from its real sharing settings, and a little metadata, using a delta query so only changes are re-read. Show the same interface for ServiceNow.

6. Prove it with canaries and an eval.

   Hide a unique phrase in each restricted document, then fail the run if an unauthorized user ever pulls it out. Score retrieval separately.

   Prompt

   Put a unique canary string in each restricted document, write cases where an unauthorized user tries to extract it, and fail the run if any canary appears. Score retrieval separately with precision and recall.

Definitions, in plain language.

Worth your time.

• Introducing Contextual Retrieval

  Anthropic. How to make the retrieval half of RAG a lot more accurate.

• Building Effective Agents

  Anthropic. Where retrieval fits in the bigger picture: a model that uses tools on feedback, over and over.

• Demystifying evals for AI agents

  Anthropic. How to know whether an output is actually good, instead of trusting instinct.

• Use case 02: Parental leave

  The same question from Bengaluru and from California, answered from the right documents and turned into a request.

• Use case 03: Time off

  Balance, policy, holidays, coverage, a draft, a yes, and a manager who approves from chat.

• How I knew it worked

  67 cases across personas, and the no-leak assertion that runs on every one.