Cross Catalog Search by Hand vs With an AI Agent: What Changes for Data Teams
The manual workflow, what an agent does instead, and what still needs a human
Cross catalog search by hand means running the same keyword query in each catalog's own UI or API and reconciling the results yourself, while an AI agent runs one federated query and returns a single normalized result set. The agent route is practical because MCP, the Model Context Protocol, gives clients like Claude Code and Cursor a standard way to call catalog tools. The decision for your team is not whether search can be automated. It is which parts of the job you want a person to keep.
Key Takeaways
- •Manual cross catalog search costs one query per catalog, plus a reconciliation step where the engineer compares names, owners and descriptions by eye.
- •An agent can issue one federated keyword or asset search across every connected catalog and return one normalized result set, which removes the per-catalog querying and most of the reconciliation.
- •Search is a read operation. It needs no write approval, but anything that changes a catalog (tags, owners, deprecations) should still go through a human approval step.
- •Evaluate an agent on result normalization, coverage of your connected catalogs, read-only guarantees, and whether it shows its sources, not on how fluent the answer sounds.
- •In our opinion, an agent is the better default once you run more than one catalog, because the integration work stops falling on the engineer.
Cross catalog search by hand vs with an AI agent: the job and who does it
The job is simple to state: someone asks "where is the customer orders table, and which one is the trusted copy?" and the answer lives in more than one catalog. Teams end up with several catalogs for ordinary reasons. A warehouse ships its own, a governance team adopted another, an acquired company brought a third, and a notebook platform keeps its own asset registry.
Today the person doing this is usually an analytics engineer, a data engineer on call, or an analyst who happens to know the right people. It is rarely anyone's assigned role, which is why it is easy to underestimate. Each lookup is small, but they recur every time someone onboards, migrates a model, investigates an incident or checks whether a column is safe to drop.
The manual workflow, step by step
We see the same sequence in most teams that search across catalogs by hand.
- •Pick the catalog you trust most and search it first, using the keyword you guess the asset is named after.
- •If the result is empty or ambiguous, open the second catalog and repeat the search with a different spelling, because naming conventions differ between systems.
- •Open each candidate asset and read its description, owner, tags and last-updated date, since there is no shared schema for these fields.
- •Copy candidate names into a scratch document or a chat thread and compare them by hand to decide which are duplicates of one another and which are different assets.
- •Ask the likely owner in chat which copy is current, then wait for the reply.
- •Record the answer somewhere, usually a message that nobody will find next quarter.
The handoffs are where it breaks. Every catalog has its own search semantics, its own tag vocabulary and its own idea of what an owner is. Stale entries look as authoritative as fresh ones. The engineer is the integration layer, and the result depends on which catalog they happened to open first and how many they remembered to check. Nothing about the process is wrong in isolation. It simply does not scale with the number of catalogs.
What an agent does instead
Our Catalog Agent ships a skill, dw-cross-catalog-search, that does one thing: federated keyword and asset search across every connected catalog, returning a single normalized result set. That is the whole scope of the skill, and we think it is worth keeping the claim that narrow.
In practice an engineer asks in Claude Code or Cursor, in plain language, something like "find everything called orders across our catalogs". The agent, exposed as an MCP server, queries each connected catalog and merges the hits into one list with a consistent shape. The engineer reads one list instead of opening several tabs. Because the agent is an MCP server, it works from whichever client the team already uses; the Anthropic documentation on MCP in Claude Code explains how a client connects to a server like this.
We covered how Data Workers keeps catalog metadata current in a separate post. Search quality depends on that freshness, because a fast search over stale entries only returns wrong answers sooner.
Manual vs agent, side by side
| Step | By hand | With an agent |
|---|---|---|
| Querying | One search per catalog, each in its own UI or API | One federated search across all connected catalogs |
| Result format | Different fields, tags and owner models per catalog | Single normalized result set |
| Coverage | Depends on which catalogs the engineer remembers | Every connected catalog, by configuration |
| Duplicate spotting | Visual comparison in a scratch document | Presented together in one list for review |
| Repeatability | Varies by person and by day | Same query path every time |
| Effort | Grows with the number of catalogs | Roughly flat as catalogs are added |
| Judgement on which copy is trusted | Engineer, often after asking the owner | Still the engineer or data owner |
We deliberately give no time-saved figures here. We have not published a measured number for this specific skill, and a made-up one would be worse than none. The qualitative difference is that the manual route scales its effort with catalog count, while the agent route mostly does not.
What still needs a human
Search is read-only. The open-source edition of Data Workers, dw-claw, is Apache 2.0, runs locally and is read-only by default, so a search cannot change anything in your catalogs. That makes this a low-risk first job to hand to an agent.
Three things should still involve a person:
- •Deciding which result is the trusted one. A normalized list shows candidates side by side. It does not know your team's definition of authoritative.
- •Writes. Tagging, assigning owners, deprecating an asset or merging duplicates change shared state. In Pro these go through approval workflows with audit trails, and we think that boundary should exist in any tool you adopt.
- •Edge cases in naming. If two catalogs describe genuinely different assets with the same name, someone who knows the domain has to say so.
Our Catalog Agent) chains with the quality, governance and schema agents, so a follow-up such as "what is the blast radius if I drop this column?" can reuse the asset you just found. That follow-up is a separate question with its own review step.
How to evaluate an agent for cross catalog search
Whatever product you evaluate, we suggest testing against your own catalogs rather than a demo dataset. These are the checks we would run.
- •Normalization: do results from two different catalogs come back with the same fields, so you can compare them without reading each source?
- •Coverage: can you list exactly which catalogs are connected, and does a search against a deliberately obscure asset in each one return it?
- •Provenance: does every result say which catalog it came from, so you can click through and verify?
- •Read-only by default: can you confirm the search path has no write permissions?
- •Failure behavior: when one catalog is down or times out, does the agent tell you it skipped it, or silently return a partial list?
- •Client fit: does it work as an MCP server in the editor your engineers already use, so nobody opens a new dashboard?
- •Data residency: does the metadata stay in your infrastructure? Ours does, since data never leaves the customer's environment.
The failure-behavior check is the one we see skipped most. A silent partial result is worse than an error, because it looks like a complete answer.
When doing it by hand is still fine
If you run a single catalog, there is nothing to federate and a native search box is enough. The same is true when searches are rare and the team is small enough that everyone knows where things live. The case for an agent starts when you have more than one catalog, or when the question comes up often enough that people have stopped asking it.
Frequently Asked Questions
Can an AI agent search several data catalogs at once? Yes, if each catalog is connected to it. The Data Workers skill dw-cross-catalog-search issues a federated keyword and asset search and returns one normalized result set, so you read a single list instead of querying each catalog.
Does cross catalog search change anything in my catalogs? No. Search is a read operation, and the open-source edition is read-only by default. Writes such as tags or owner changes belong to the Pro edition and go through approval workflows with audit trails.
Do we need a new interface to use it? No. Each Data Workers agent is an MCP server, so you call it from Claude Code, Cursor, Windsurf, VS Code or any MCP-compatible client. The MCP specification describes how clients and servers communicate.
Will the agent tell me which asset is the right one? It shows you the candidates together, with their source catalogs, so you can decide faster. Choosing the trusted copy is a judgement about your definitions, and we think a person or data owner should keep it.
How should we measure whether it works for us? Run ten real lookups your team did recently by hand, including some that needed several catalogs, and compare the agent's list with what the engineer eventually found. Count misses and wrong rankings, not just speed.