“Why did new-customer conversion fall this month?” A warehouse may contain a production funnel model, a similarly named test table, and a spreadsheet from last quarter’s campaign. All three are reachable. All three have plausible columns. If the agent chooses the wrong one, polished SQL and charts only make the error more persuasive.
Before query generation, the access layer must answer three questions: What may this identity access? What should this task use? Is the selected evidence sufficient for the claim? It is not a pipe that dumps every schema into a prompt. It is a permission-aware discovery and context-routing system.
Notice the two authorization boundaries. Discovery begins inside a restricted catalog view, and execution rechecks permission against the source. “Discoverable in metadata” never means “authorized to execute.”
Boundaries with the neighboring layers
The access layer discovers assets, checks provenance and visibility, and delivers the smallest sufficient context. The semantic layer owns definitions, grain, and valid relationships. The planner chooses analytical steps. The execution layer holds credentials, runs queries, and performs the final authorization check.
Those responsibilities should not collapse into one service. A similar table name is not a business definition, and a catalog result is not an execution credential. Mixing the boundaries produces two recurring failures: the agent answers a current question with a popular obsolete table, or a shared service identity silently exceeds the user’s rights.
Four components and their contracts
| Component | Minimum output | Failure behavior |
|---|---|---|
| Source registry | Stable source ID, environment, domain, owner, credential reference, allowed operations, and budget | Unregistered sources are never added silently |
| Catalog and collectors | Schema version, descriptions, lineage, quality status, observation time, and data watermark | Missing signals remain unknown |
| Context router | Candidates, inclusion and exclusion reasons, required fields, definition references, and gaps | Clarify or stop when no reliable source exists |
| Connector runtime | Identity binding, pagination, timeout, retry, normalized results, and audit events | Credentials never enter model context |
Reuse catalog infrastructure where possible. OpenMetadata connects ownership, terms, lineage, profiling, and quality signals, while its ingestion framework collects several classes of metadata. Installing a catalog does not decide routing policy, however. A team still needs to define which signals rank candidates and which conditions block them.
Six steps in a reliable route
1. Turn the question into retrieval constraints
Extract the business domain, entity, metric, time range, grain, purpose, and deliverable. Resolve relative time to a concrete interval and time zone. If “customer” or “order” is ambiguous, clarify before retrieval rather than after a query fails.
2. Retrieve inside the current visibility boundary
Keywords, business terms, and vector search can all contribute candidates, but retrieval must be identity-aware. Table names, column descriptions, and samples may themselves be sensitive. Do not expose a global catalog to the model and hope it ignores forbidden assets.
3. Apply hard policy filters first
Environment, purpose, region, sensitivity, metadata visibility, and source authorization are gates—not ranking features. A test table must not outrank a production model merely because its name is more similar to the question.
4. Rank and trim compliant candidates
Compare business coverage, authority, freshness, quality evidence, join completeness, and expected cost. Historical popularity is only a supporting signal; otherwise a newly governed model can never displace an old favorite. Multi-source work also needs valid relationship paths, not a bag of individually similar columns.
5. Bind references and reauthorize at execution
The router sends asset references, versions, and budgets. The runtime binds the real identity and rechecks access because permission, schema, and source state may have changed since discovery. Microsoft Fabric Data Agent’s sharing documentation makes the same distinction: sharing an agent does not grant access to its underlying data sources.
6. Record outcomes and corrections
Keep candidates, exclusion reasons, selected versions, execution outcomes, and human corrections. A click or acceptance event is an experience signal, not proof of correctness. Only confirmed corrections should become regression cases or authority signals.
A context package must carry limitations
A list of columns is not enough. A useful package records the evidence state as well as the selected data:
{
"asset_ref": "warehouse.prod.funnel",
"schema_version": "v12",
"selected_fields": ["day", "channel", "new_users", "converted_users"],
"definition_ref": "metrics/new_customer_conversion/v3",
"grain": "day × channel",
"metadata_observed_at": "2026-09-07T09:00:00+08:00",
"data_watermark": "2026-09-06",
"quality_status": "unknown",
"policy_ref": "policy/read-funnel/v4",
"allowed_operations": ["read"],
"limitations": ["coverage of all channels is not confirmed"],
"requires_runtime_authorization": true
}
metadata_observed_at and data_watermark describe different clocks. A catalog synchronized today may point to business data that stopped last week. A policy reference is not a credential; authorization handles and secrets remain in the trusted runtime.
Failures need distinct exits
An access failure should not collapse into “please retry.” Different conditions require different behavior:
NEEDS_AUTH: stop reading and provide a safe authorization path without revealing hidden asset names.NO_RELEVANT_ASSET: clarify or ask an owner; do not guess a table.STALE_METADATA: refresh and compare versions; expose uncertainty if recovery fails.SOURCE_UNAVAILABLE: retry only eligible failures with a limit; prove any substitute is equivalent.BUDGET_EXCEEDED: narrow the scope, use an aggregate, or seek approval; never scan indefinitely.
If the production funnel lacks one channel, the safe result is “the available sources cannot explain the total decline,” not an undisclosed switch to a convenient table. The ability to stop is a core access-layer capability.
Evaluating whether the agent found the right data
An acceptance set should include identity, question, correct asset set, forbidden assets, expected refusal, and version. Cover similarly named tables, stale data, revoked access, missing metadata, cross-source joins, and tasks with no valid answer.
- Hit@K asks whether at least one correct asset appears among the first K candidates.
- Recall@K asks whether a multi-source task retrieved the full required set.
- Unauthorized allow rate is a separate blocking metric; never average it into accuracy.
- Freshness reports catalog lag and business-data lag independently.
- Cost includes scanned data, context size, p95 routing latency, and retries.
- Refusal quality checks whether the system stops explicitly when evidence is inadequate.
Hold identity, questions, and data snapshots constant when comparing keyword retrieval, hybrid retrieval, and governance-aware ranking. Connector count is not a capability metric. Source choice, authorization, and failure behavior on real work are.
A safer rollout sequence
Begin with one domain, a read-only warehouse, and the minimum document collection. Establish owners, refresh expectations, and a human-labeled task set. Next, add lineage, quality signals, versioned context packages, and tests for revocation, staleness, and source failure. Scale connector registration and caching only after routing value, cost, and security blocks are measured.
The access layer creates a smaller data space that downstream reasoning can explain, authorize, and verify. If it chooses the wrong evidence, every later layer mostly amplifies the mistake.