An agent cannot read a 50,000-table catalog into its context, and the standard workaround — dump the schema, hand over one query tool — fails on cost, latency, and accuracy at the same time. What works against Unity Catalog is a narrow probing tool set, retrieval-driven discovery, and a hard rule that oversized results never enter the model context.
This is a deployment playbook. It describes how the connector is shaped, what the agent is permitted to do at each step, and the three failure modes that only appear once a real catalog is behind it.
From the standard
“Pre-trained models with a differentiable access mechanism to explicit non-parametric memory can overcome this issue”
Why schema injection stops working
Every demo works against twelve tables. Load the schema into the prompt, give the model a query tool, and it performs well. The approach has no upper bound problem until it does, and then it has three at once: the schema costs more tokens than the question, retrieval accuracy falls as the table list grows, and latency rises with a context the model must re-read on every turn.
An enterprise Unity Catalog is not twelve tables. Treat the catalog the way a competent analyst treats an unfamiliar warehouse: search for candidates, look at a few, discard most, narrow.
The tool surface
One general-purpose query tool is the wrong shape. It gives the agent maximum reach and gives the platform nothing to reason about — every call looks identical, so nothing can be gated, ranked, or costed differently. Replacing it with a small set of narrow tools makes each step inspectable.
| Step | Tool shape | Why it is separate |
|---|---|---|
| Find candidates | catalog search | Retrieval over metadata, not a scan of the catalogue |
| Inspect | table preview | Bounded row count, so an inspection can never become an extraction |
| Size the work | row count | Lets the agent decide before it commits to a query |
| Answer | aggregate metrics | The common case is a number, not a table |
| Search free text | text / log search | A different index, and a different cost profile |
| Hand off bulk | dataset pointer | Materialise, then a pre-signed URL — the rows never enter the context window |
The separation is the control. A preview cannot return a million rows because previews are bounded by definition, not by a parameter the model chooses. An aggregate cannot leak row-level data because it does not return rows. Narrow tools mean the policy layer has something specific to allow or deny.
The pointer pattern
Past a row threshold, the connector materialises the result to object storage and returns a pre-signed URL rather than the rows. The model receives a pointer and a summary; the user receives the data. Nothing large ever transits the context window.
This is a security control, not only a cost one
Bounding tokens is the obvious benefit. The larger one is that a result the model never saw is a result the model cannot restate, summarise incorrectly, or leak into a later turn. The pointer keeps bulk data on a path that runs from the warehouse to the user without passing through an inference call.
Three failure modes that only appear at scale
1. The agent answers without looking
Give a model a set of probing tools and it will sometimes skip them, producing a confident answer from the table names alone. The output is fluent, plausible, and grounded in nothing. This is the most dangerous failure of the three because it looks exactly like success.
The fix is structural rather than instructional: constrain the agent so an answer that cites no probe result is not deliverable. Asking the model in the prompt to please check first is not a control — it is a request addressed to the component that just failed to do it.
2. The pointer URL becomes an egress channel
The moment the system hands back a URL, it has a server-side request forgery surface. A destination the model influences is a destination an attacker who can influence the model may also reach. Restrict the pointer target to an allowlist of storage domains you control, and validate it where the model cannot reach the check.
3. Subquery evasion
A table allowlist checked by string matching is not an allowlist. A permitted table name in the outer query with a restricted one nested inside passes a naive check and reads exactly what the policy forbade. The query has to be parsed to its syntax tree and every referenced relation checked, including inside subqueries, CTEs, and joins.
All three were found by attacking the system rather than by reading about them. That is the argument for red-teaming a data connector before it reaches a customer catalog: none of these appears in a functional test, because in each case the system does exactly what it was asked to do.
Where the connector runs
Inside your own cloud account, on the execution plane. Unity Catalog governs access by identity, and that governance is only meaningful if the agent acts under the identity of the person driving it rather than a shared service principal — otherwise every user inherits the union of everyone's permissions and the catalog's access model has been quietly bypassed.
The connector itself is a declarative manifest rather than code: tools, authentication, gate rules, and blast-radius definitions in configuration. Adding a system becomes a configuration commit reviewed like any other change, not a release.
What this costs
More round trips. A question that schema injection answers in one model call may take four or five probing calls here, and on a small catalog that is strictly worse — slower and no more accurate. The pattern earns its complexity somewhere north of a few hundred tables, and below that the simple approach is the right one.
The question to settle before building is not how large the catalog is today. It is whether the agent will be pointed at a catalog nobody on the team can enumerate from memory.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.