NL asset search by hand vs with an AI agent: what changes for data teams
The manual catalog hunt, the agent version, and what still needs a human
NL asset search by hand means an engineer translates a business question into catalog keywords, filters, lineage clicks and Slack messages until the right table turns up. With an AI agent, the same person states the need in plain English and the agent maps intent and constraints to candidate assets, then refines the result through follow-up questions. In our opinion the real difference is not speed alone; it is that the agent keeps the intent and constraints in context across steps, where a person re-types them into each tool. This post walks through both workflows and what we would check before trusting an agent with the job.
Key Takeaways
- •Manual asset search is a chain of lookups across a catalog, a warehouse console, lineage views and colleagues; the engineer carries the intent between them.
- •An agent skill for this job takes a plain-English data need, resolves intent and constraints, returns matching catalog assets, and accepts follow-up refinement.
- •Search is a read operation. In the open-source edition of Data Workers (dw-claw, Apache 2.0) the agents are read-only by default, so searching needs no write approval.
- •Humans still decide whether an asset is the right one to build on, and approve any write that follows from the search.
- •Evaluate an agent on your own questions, with known-correct answers, before you rely on it.
NL asset search by hand vs with an AI agent: the job and who does it today
The job is simple to state: someone has a data need, such as "show freshness scores for all gold tables" or "which table holds net revenue by customer segment", and has to find the assets that satisfy it. Today that person is usually an analytics engineer, a data engineer, or an analyst who has been in the company long enough to know where things live. New hires and downstream consumers ask them in Slack.
The cost of the job is mostly interruption and uncertainty rather than compute. Senior people become the human search index, and everyone else guesses between tables that look alike. We are not citing a time figure here because we have not measured one in a way we can publish; if you want a number for your team, time a handful of real requests.
The manual workflow, step by step
This is the sequence we see most often. Each step is a different tool or person, and each handoff is where context gets lost.
- •Restate the need in catalog terms. The business question ("active customers last quarter") becomes keywords the catalog might index ("customer", "active", "fact").
- •Keyword search the catalog. Results are ranked by name and description match, so tables with sparse descriptions sink and near-duplicates rise.
- •Apply filters by hand: domain, owner, tag, tier, freshness. Constraints such as "only certified" or "no PII" are re-applied in each tool.
- •Open candidates one at a time and read schemas, descriptions and sample rows, usually in a separate warehouse console.
- •Check lineage to see which candidate is upstream of which, and which one dashboards actually read.
- •Ask a colleague. When the descriptions disagree or are missing, the answer comes from someone's memory.
- •Write down the result. It usually ends up in a ticket or a message, not back in the catalog, so the next person repeats the search.
It breaks in three places. First, the vocabulary gap: the question and the catalog use different words. Second, constraints get dropped between tools, so a table that violates the original requirement can slip through. Third, refinement is expensive: "actually, I need it at order-line grain" sends you back to step 2.
What an AI agent does instead
We describe only what the skill is built to do. Our dw-nl-asset-search skill, part of the Catalog Agent, turns a plain-English data need into the right catalog assets. It handles three things: the intent behind the question, the constraints attached to it, and follow-up refinement when the first answer is close but not right.
The skill runs where the engineer already works. Every Data Workers agent is an MCP server, and the Model Context Protocol is the open standard that lets clients such as Claude Code and Cursor call it. You ask in the terminal or editor; you do not open another dashboard. The Catalog Agent) is built to federate across the catalogs a team already runs, so the question does not depend on which one holds the metadata.
For a request like "find the gold tables that report daily revenue and are not PII-tagged", the agent treats "gold", "daily revenue" and "not PII-tagged" as intent and constraints, not keywords. If you reply "only the ones refreshed today", that is a refinement of the same search, not a new one.
Manual vs agent: side by side
| Step | By hand | With an AI agent |
|---|---|---|
| Stating the need | Translate into catalog keywords yourself | Ask in plain English; the skill resolves intent |
| Constraints | Re-apply filters in each tool | Constraints travel with the request |
| Refinement | Restart the search | Follow-up question refines the previous result |
| Where it happens | Catalog UI, warehouse console, chat | Your MCP client (Claude Code, Cursor and others) |
| Candidate review | Open each asset in turn | Agent returns matching assets for you to review |
| Final judgment | Engineer | Engineer |
| Effort | Depends on who knows the estate; high for newcomers | Lower and more uniform; measure it on your own questions |
What still needs a human
Finding an asset is not the same as endorsing it. A person still decides whether the table is the authoritative source, whether its grain fits the analysis, and whether the owner is comfortable with a new consumer. The agent can surface candidates; it cannot know that finance quietly redefined "active" last month unless that is written down somewhere it can read.
Writes are a separate matter. The OSS edition is read-only by default, so searching never changes anything. Pro adds writes with approval workflows and audit trails, so a follow-on action, such as tagging the asset you picked, goes through an explicit approval and leaves a record. Our rule of thumb is that read access can be broad and write access should be narrow, per domain.
How to evaluate an agent for this job
Do not judge it on a demo question. Build a small evaluation set from your own history, as in the practice described in Anthropic's documentation on building evaluations, where success criteria are defined before you test.
- •Collect 20 to 30 real requests from Slack or tickets, including vague ones and ones with hard constraints.
- •For each, write down the correct asset or assets before you run the agent. Freeze that answer key.
- •Score whether the right asset appears, whether the constraints were honored, and whether the agent says so when nothing fits.
- •Include follow-up refinements, since that is where manual search is worst.
- •Check access behavior: an asset a user cannot see should not show up for them.
- •Re-run the set after any catalog or agent change so it works as a regression suite.
We cover how catalog context stays current in a separate post on the Catalog Agent, and our Quality and Governance agents are the natural next stops once you have found an asset and want to check its freshness or who can access it. All of these are reachable from the same MCP client.
Frequently Asked Questions
Is NL asset search by an AI agent more accurate than searching by hand? Not automatically. An agent that understands intent and constraints can beat keyword matching on vague questions, but accuracy depends on how good your catalog metadata is. Measure it against an answer key built from your own requests.
Does the agent change anything in my catalog when it searches? No. Search is a read operation, and the open-source dw-claw edition is read-only by default. Any write after the search, such as tagging, needs Pro with approval workflows.
Do my engineers need a new tool to use it? No. The skill is exposed through MCP, so it works from Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot or any MCP-compatible client. Our MCP server repository index lists the wider ecosystem of servers these clients can call.
Where does the data go? Data Workers is designed so data stays inside the customer's infrastructure, with SSO, RBAC and audit trails applied across every agent.
What if the catalog has poor descriptions? Then both approaches struggle. The agent will still apply your constraints and let you refine, but we would fix the worst gaps in metadata first and treat the evaluation set as a map of where they are.