203 - Discovery: one search, then fetch

If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.

A question rarely announces where its answer lives. "How did the Southwest region do last quarter" might be answered by a dataset, by a glossary term that pins down what the company means by "region," by a knowledge page a steward wrote after the last reorganization, or by a note you left yourself three sessions ago. An agent that has to pick a search tool before it starts looking is guessing at that answer before it has any evidence, and a wrong guess costs a round trip and often a wrong answer.

So Plexara does not offer a search tool per backend. It offers one. A single search call fans across every source the caller can reach and reports what it found in each. Where an answer lives becomes something the response tells the agent rather than something the agent had to know in advance.

Fanning across a dozen sources creates a problem a flat relevance list makes worse: the largest source wins. A catalog with forty thousand datasets will out-match a knowledge base of two hundred pages on almost any query, and the one page that actually answers the question ends up below the fold behind thirty datasets that merely mention the topic.

Search returns results bucketed by source instead, built from a display budget with a floor per source so every matching source stays visible and a ceiling per source so none of them runs away. Alongside the hits comes a coverage summary: how many records each source matched against how many are being shown. That second number is what keeps the agent honest about what it is looking at.

Semantic ranking is the feature people expect from a search tool. Every text query gets it: results rank hybrid, a semantic vector comparison combined with lexical matching, which is what lets a question find a dataset description sharing none of its words while an exact table name still lands where you expect it.

The response reports which path produced a result rather than leaving it implied, because not every lookup is a text search. That distinction is what the ranking field is for.

A search hit is a pointer, not a document. It carries a title, a short snippet, a relevance score, and a reference. That shape is deliberate: a response that returned every matching record in full would spend the context window on material the agent has not yet decided it wants.

The reference is what turns a pointer into content. Fetch takes one and returns the complete record behind it, whatever kind of record that is. A knowledge page comes back as full markdown, a dataset as its catalog context, a glossary term as its definition and the datasets carrying it, a prompt as the prompt. The scoped readers that used to exist per source collapsed into this one verb.

Because the tools are separately grantable, it is possible to configure a persona that can search and cannot fetch. It is worth knowing what that looks like from the user side, because the symptom does not point at the cause.

The operating manual that platform_info loads tells the agent to search before writing any query against the data, and usually to pull curated query templates for whatever dataset it settles on. This is not a style preference. It is how the agent avoids inventing schemas, misreading column names, or picking the wrong definition of a metric. This is the difference between searching the capability instead of the manual: the agent finds what exists before it acts.

Even with a thorough catalog and a well-tended knowledge base, exploratory sessions benefit from a short domain warm-up at the start. Giving the agent a moment to describe the data estate in its own words activates the relevant slice of its training-time world knowledge and surfaces any obvious gaps before you ask a question that depends on them.

What the platform returns is thorough, but it covers only what somebody documented. Obvious-to-humans context (a retailer sells physical goods through stores, a bank charges fees across customer accounts, a SaaS vendor tracks monthly recurring revenue) is not written down anywhere unless it was written down on purpose. A short warm-up closes that gap.

The governance vocabulary deserves its own note, because it changed shape. A glossary term, a tag, and a domain used to exist only as attributes hanging off a dataset: asking what a business term meant returned the datasets tagged with it and never the term itself. They are now searchable and fetchable entities in their own right, which means the question "what does this word mean here" finally has a direct answer.

Search answers "what is there about this." It does not enumerate, and it does not walk a graph. Once the agent knows which dataset it wants, the questions turn structural: what columns does it have, what feeds it, what consumes it, what queries have already been written against it. Those go to the catalog directly.

The distinction is worth holding onto because it explains why the DataHub toolkit did not shrink when discovery moved out of it. Relevance ranking and structured navigation are not two implementations of the same idea.

Not every session needs a domain warm-up, and not every question needs a fetch. Narrow, specific questions with clear entity references ("daily revenue by region for 2025") carry enough context in the question itself that the snippets in a single search response fill in the rest. The warm-up pays off most for new users, cross-domain questions, and anything where you are not already sure which dataset you want.

With the right dataset identified and a curated query template in hand, the agent is ready to run the query. The next lesson covers how Plexara reaches data through Trino and why picking the right query shape matters so much for performance.

Eight terms cover the vocabulary you will see across search responses, catalog documentation, and every conversation about the discover step.