Enterprise-search
This video explains the enterprise-search skill, which answers from a company's own knowledge by searching, reading full documents and giving feedback. It covers index-first searching, cursor pagination and why an empty result is ambiguous.
Questions about a company's own policies, prior decisions or named projects seem like they should be answered by a single search. This video explains why they are not. The enterprise-search skill treats search as the first step of a three-step loop, and it adds two rules and one caveat that keep the loop reliable.
Why one search is not enough
The video imagines someone asking, "What's our policy on contractor onboarding, and is there a prior decision already on file?" Answering requires the company's own knowledge across chat, drives, tickets and wikis, not the open web. The easy assumption is to run one search and treat the top result as the answer.
The problem is what a search result is. It is a snippet of about 35 words, enough to judge whether a document is worth opening, and never built to answer a question by itself.
Search, read and feedback
The skill works as a loop in three steps. Search returns ranked snippets across every connected source. Read fetches the full text of the documents that matter, using the ID that search returned. Feedback means upvoting what you used and downvoting what you rejected, which trains the ranker; the video says this happens before the task is called done.
Two bundled scripts do the busy work. One handles searching with pagination, and the other reads up to 50 documents at a time.
Rule one: the shared index first
The first design rule is to always search the shared index first. According to the video, it already ranks across every source, removes duplicates and respects permissions. Only after that does the skill fall back to one connector directly.
Rule two: cursors come from the system
The second rule concerns pagination, which is cursor-based. The cursor must be passed back exactly as it was given. You never build one yourself, and you stop when there is no cursor.
The ambiguity in an empty result
There is one catch. An empty result can mean two different things: the content genuinely is not indexed, or the identity asking cannot see it. The API does not say which. The video presents the Glean Client REST API as its worked example of this behavior, and it does not claim every enterprise search product works the same way.
Seeing the loop on one question
Returning to the onboarding example, search turns up a snippet that mentions a policy. That is step one. Reading the full document is what surfaces the exception buried in the next paragraph. Marking that document as used is step three, and it makes tomorrow's search better.
The video adds two cautions. Finding something does not mean you have everything, since some sources might not be connected yet. Finding nothing does not mean the answer does not exist, since it might be a permissions gap or a query that needs broadening first.
Key takeaways
- Enterprise search is a loop, not a single lookup.
- Search returns ranked snippets of about 35 words for triage.
- Read fetches the full document using the ID from search, and one script reads up to 50 at a time.
- Feedback upvotes what you used and downvotes what you rejected, before the task is done.
- Search the shared index before falling back to a single connector.
- Pass pagination cursors back exactly as given and stop when none is returned.
- An empty result could mean not indexed or no permission, and the API does not say which.
Try it yourself
Ask your assistant to search your internal docs for your policy on contractor onboarding, read the full document rather than the snippet, and tell you whether a prior decision is on file. Ask it to report what it used to answer before it finishes, and check whether it opened the document.
Chapters
- 0:00Does Claude just search our docs and answer from the results?
- 0:12One question, many sources — the anchor
- 0:24A snippet, not an answer
- 0:38Search, read, feedback — the loop
- 1:00Design rules — index first, cursor pagination, empty-results logic
- 1:24The anchor returns — snippet, document, feedback
- 1:39Both directions — found isn't complete, empty isn't proof
- 1:52Carry-out
- 2:00Your turn
- 2:15Outro
Full transcript(auto-generated, with timestamps)
Does Claude just search our docs and answer from the results?
[0:00]Someone assumes Claude just searches the company's docs and answers straight from the results. It's closer to this. Search finds candidates, reading the document is what actually answers you. Lay them, take them through it. Say you ask,
One question, many sources — the anchor
[0:12]"What's our policy on contractor onboarding, and is there a prior decision already on file?" Answering that means reaching into the company's own knowledge, chat, drives, tickets, wikis, not the open web. The easy assumption, run one search and
A snippet, not an answer
[0:25]The top result already has the answer. But a search result is a snippet, about 35 words, just enough to judge whether a document is worth opening. It was never built to answer anything by itself. The loop runs in three steps. Search returns
Search, read, feedback — the loop
[0:40]Ranked snippets across every connected source. Read fetches the full text of the documents that matter using the ID from search. Feedback upvote what you used, downvote what you rejected, trains the ranker, and it happens before the task is called done. Two bundled scripts handle the busy work, one for searching with pagination, one for reading up to 50 documents at a time. Two rules keep
Design rules — index first, cursor pagination, empty-results logic
[1:00]It honest. Always search the shared index first. It already ranks across every source, deduplicates, and respects permissions before falling back to one connector directly. And pagination is cursor-based. Pass the cursor back exactly as given, never build one yourself, stop when there isn't one. One catch, an empty result can mean two different things. The content genuinely isn't indexed, or the identity asking simply can't see it. The API doesn't say which. Back to the
The anchor returns — snippet, document, feedback
[1:24]Onboarding question, search turns up a snippet that mentions a policy. That's step one. Reading the full document is what actually surfaces the exception buried in the next paragraph. Marking that document as used is step three, and it's what makes tomorrow's search better.
Both directions — found isn't complete, empty isn't proof
[1:39]Finding something doesn't mean you have the whole picture. Some sources might not be connected yet. And finding nothing doesn't mean the answer doesn't exist. It might be a permissions gap, or a query that needs to broaden before you conclude that. Enterprise search isn't
Carry-out
[1:52]One lookup. It's search for candidates, read the document that matters, then say what you used so the next search ranks better.
Your turn
[2:00]Your turn. Here's the prompt. Read it with me. Search our internal docs for our policy on contractor onboarding. Read the full document, not just the snippet, and tell me if there's a prior decision on file. Then tell me what you used to answer before you finish. Liam in for Bear. Enterprise search Liam in for Bear.
