Data platforms for AI assistants and agents

Agent-Ready Data Platforms: Evidence Dossier on What Changes When AI Becomes a Data Consumer

Research snapshot: October 3, 2026
Scope: enterprise structured-data platforms consumed by analysts, BI, deterministic applications, AI assistants, analytical agents, data/coding agents, and operational agents.
Research stance: “AI-ready” and “agent-ready” are treated as hypotheses to be decomposed, not accepted architecture categories. The scope, questions, and requested evidence distinctions follow the supplied research brief. 1

Executive synthesis and methodology

Executive synthesis

The strongest conclusion from the evidence is that an “agent-ready data platform” is not, at present, a clearly distinct data architecture. Most of its substrate—data modeling, quality, ownership, contracts, lineage, access control, catalogs, observability, semantic modeling—predates generative AI. What changes is the degree to which previously implicit, human-interpreted or application-embedded context must become explicit, machine-readable, selectable at runtime, enforceable outside the model, and traceable into an answer or action. Recent open data-contract standards themselves illustrate this evolution: ODCS v3.2.0, released in September 2026, added optional context, verified statements, constraints, synonyms, semantic types, and authoritative definitions specifically usable by AI agents and semantic tools rather than inventing a separate “AI data” object. 2

Five changes stand out.

First, ambiguity moves from a usability problem to a correctness-control problem. A human analyst can see “revenue” and ask which revenue, inspect unusual joins, notice that a table looks stale, or challenge an implausible result. A deterministic application normally has those choices frozen into code, schemas, API contracts, or tests. An LLM instead dynamically resolves mappings between natural language, schemas and business concepts, and can return an executable, fluent and plausible result even when the question is underspecified. Enterprise text-to-SQL research shows that large schemas require metadata, documentation and project context; research on unanswerable text-to-SQL shows that underspecified requests may still produce executable but misleading programs. 3

Second, semantic and operational context has to become machine-consumable. Current production systems from multiple vendors independently expose table/column descriptions, keys, business terms, synonyms, instructions, examples or verified queries, and semantic definitions to conversational agents. Google explicitly reports that direct conversations without agent context can be less accurate, recommends scoped agents, and warns that large scopes can introduce conflicts and ambiguity. Databricks similarly exposes table metadata, descriptions, PK/FK relationships, local knowledge, example SQL and instructions to its data agent. These are documented architectures rather than independent evidence that any one product design is optimal, but the convergence is notable. 4

Third, quality, freshness, version and provenance increasingly become part of the runtime meaning of an answer. A quality dashboard that a person might inspect separately is less useful to an autonomous consumer unless its state can accompany source selection or query execution. Existing standards already provide pieces: data contracts can encode executable quality rules and ownership; OpenLineage emits timestamped run/job/dataset events and states; W3C PROV provides a general provenance representation. The AI-specific step is not a new quality dimension, but exposing these signals to the machine at the point where it decides whether and how to answer. 5

Fourth, the security boundary must be deterministic even when the reasoning is probabilistic. Authentication establishes a principal; authorization decides what that principal may do; model reasoning decides which permitted operation it wants to request. These are separate mechanisms. NIST’s 2026 agent-identity work explicitly frames identification, authorization, auditing and non-repudiation as agent concerns. MCP’s security guidance identifies confused-deputy and token-passthrough risks, while OWASP documents indirect prompt injection through retrieved/tool content and over-permissioned tool execution. Prompt wording is therefore not an authorization mechanism. 6

Fifth, provenance and observability expand from “what query ran?” to “how did this question become this answer or action?” The relevant chain can include the user or agent identity, selected sources, semantic definitions, retrieved metadata, quality/freshness state, generated SQL, tool arguments and outputs, model/tool versions, authorization decisions, and subsequent side effects. Existing lineage, provenance and telemetry standards provide much of the vocabulary, but there is not yet one mature cross-platform standard that binds all of these into an answer-level evidence object. 7

The concise distinction is therefore:

A well-governed conventional platform becomes materially more “agent-ready” when its semantics, trust state and policy are available as machine-readable runtime context; ambiguity can trigger clarification/refusal rather than silent inference; authority is constrained by deterministic tool and identity boundaries; and every material answer or action is reproducible through provenance.

That does not imply that every platform needs a knowledge graph, semantic layer, MCP server, vector database, new warehouse, or “agentic data platform.”

Evidence method

The investigation prioritized original empirical research, open standards, protocol specifications, official security guidance, and primary platform documentation. Provider documentation is used to establish actual design and supported capability, not independent proof of business value. Public marketing pages are used only to analyze terminology. No same-topic Decision-maker, Practitioner or Academic companion research was consulted.

The evidence categories used below are:

Evidence label	Meaning	Appropriate inference
Empirical	Benchmark, experiment or peer-reviewed/original research	Evidence of observed model behavior under stated conditions
Standard/specification	W3C, IETF, open specification, protocol	Evidence that a machine-readable mechanism exists or is standardized
Documented architecture	Official product documentation	Evidence of implemented design/capability, not proof of superiority
Production change	Documented behavior correction/change in a deployed system	Strong evidence of a concrete failure class
Security guidance	NIST, OWASP, protocol security guidance	Threat/control evidence; not necessarily frequency estimates
Provider claim	Vendor interpretation or marketing assertion	Evidence of terminology/use only
Interpretation	Synthesis across sources	Conditional conclusion, explicitly not direct empirical finding
Hypothesis	Plausible but insufficiently validated proposition	Research frontier

A particularly important limitation is temporal. The original Spider 2.0 paper reported very low performance for contemporary systems in late 2024—17% for one code-agent configuration, versus much higher performance on older benchmarks—but the Spider 2.0 leaderboard changed substantially afterward. The original results are therefore evidence that realistic enterprise context materially changed task difficulty, not a defensible estimate of October 2026 state-of-the-art accuracy. 3

Taxonomy and consumer differences

Agent-ready data taxonomy

Current terminology mixes architectural concepts, governance practices, interfaces and marketing labels. The evidence does not support treating them as synonyms.

Term	Best classification	Agent-specific?	Evidence-based interpretation
AI-ready data	Umbrella/provider label	Weakly	Used variously for clean/governed data, contextualized data, ML-ready data, or data exposed to AI. Provider definitions materially differ. TDengine emphasizes structured/contextualized industrial data; IBM’s “data intelligence” positioning combines metadata, definitions, lineage, quality and governance. 8
Agent-ready data	Emerging umbrella label	Partly	Usually adds discoverability, machine-readable context and an agent-facing interface. There is no normative definition in the standards reviewed.
Agentic data platform	Ambiguous product/category label	Partly	Can mean a platform used by agents, or a platform whose own engineering/operations are performed by agents. It does not identify a stable architecture.
Semantic layer	Architectural abstraction + modeling discipline	No	Provides governed entities, dimensions, metrics or relationships above physical schemas. AI raises its usefulness but did not create the concept. Current conversational systems commonly consume semantic models or equivalent metadata. 9
Metric layer	Narrower semantic abstraction	No	Centralizes metric definitions, aggregation and dimensional behavior; useful where NL questions must map to governed metrics. 10
Business glossary	Metadata/governance discipline	No	Gives terms explicit definitions and aliases; conversational products now inject them into model context. 4
Ontology / knowledge graph	Semantic representation architecture	No	Formalizes concepts and relationships. W3C OWL and SKOS demonstrate that machine-readable vocabularies, relationships and alternative labels long predate LLM agents. 11
Data contract	Producer-consumer contract / metadata artifact	No, but evolving	Traditionally encodes schema, ownership, quality and service properties. ODCS v3.2.0 now optionally encodes agent context, constraints, verified statements, synonyms and semantic roles. 12
Data product	Product/ownership boundary	No	The product concept remains; agent support becomes another consumer requirement. ODPS has similarly added optional agent-facing context. 13
Catalog	Discovery/metadata infrastructure	No	DCAT formalizes machine-interoperable discovery of datasets and services; being discoverable does not make meaning unambiguous. 14
Governed data	Governance state/practice	No	Ownership, policy, quality and access control remain general requirements.
Data intelligence	Broad vendor/category label	No stable meaning	Commonly bundles catalog, metadata, lineage, quality, governance and AI features; it is not a technical standard. IBM is one current example. 15
Context engineering	AI runtime-system practice	Yes	Describes choosing and shaping what an AI sees; the standards reviewed do not define it as a data-storage architecture.
Tool / API	Interface design	No	Controls which operations are exposed and at what abstraction level.
MCP	Agent/tool interoperability protocol	Yes	Standardizes discovery/calling of tools/resources and structured input/output shapes. It does not itself make underlying data semantically correct or authorize arbitrary business operations. 16

The important boundary is between representation and guarantee. A semantic layer can represent a metric but still encode or permit an unsafe combination. A contract can state quality expectations without proving current data are accurate. A catalog can make a table discoverable without making it authoritative. MCP can describe a tool schema without making the tool’s business semantics trustworthy. Snowflake’s 2026 change disabling a semantic-view query pattern is a concrete example: combining facts and dimensions had been syntactically allowed but could return arbitrary fact values per dimension group, so the platform changed the behavior to fail rather than produce nondeterministic data. 17

Human, deterministic software and AI consumers

The meaningful difference is not simply “human versus machine.” Dashboards and conventional software have been machine consumers for decades. The crucial distinction is where interpretation is performed and how failure is expressed.

Dimension	Human analyst	Dashboard / BI	Deterministic application	AI assistant	AI agent
Ambiguity tolerance	Can notice and ask	Usually removed during dashboard design	Must be resolved in code/contract	May silently infer a meaning	May silently infer and then continue acting
Semantic mapping	Uses domain knowledge	Embedded in model/BI logic	Encoded in application logic	Generated at runtime from context	Generated and repeatedly revised during multi-step execution
Discoverability	Browses catalog/docs, asks colleagues	Preselected sources	Fixed endpoint/schema	Searches metadata/tools	Dynamically searches and selects sources/tools
Metadata need	Can work with incomplete docs using tacit knowledge	Mainly build-time	Usually contract/schema focused	Runtime descriptions, relationships and business context become important	Same, plus tool constraints, state and authority context
Freshness handling	Can inspect timestamps/pipeline alerts	Typically predefined refresh behavior	Often explicit SLA/error handling	Needs freshness exposed in answer context	Needs freshness before decisions/actions
Error behavior	Suspicion, investigation, correction	Visible failure or incorrect dashboard	Exception/retry/contract failure	Can produce fluent wrong answer	Can propagate a wrong inference through several steps
Permissions	User identity	Viewer/service identity	Service/user principal	Delegated user or scoped agent principal	Same, often across multiple tools
Provenance	SQL/notebook/history may suffice	Dashboard lineage	Request/application logs	Sources + query/definition increasingly useful	End-to-end question→tool→action provenance
State	Human memory/notebook	Dashboard/session filters	Explicit application state	Conversation context	Conversation + workflow/tool state; persistent memory may appear
Validation	Human judgment + tests	Prebuilt QA	Deterministic validation	Must combine model checking with deterministic checks	Validation becomes a control loop before further actions
Failure blast radius	Usually one analysis/decision	Shared report consumers	Bounded by application behavior	Potentially many downstream readers	Potentially downstream systems and durable side effects

This comparison is a synthesis rather than a benchmark. Its central empirical support is that large enterprise schemas demand contextual schema linking, documentation and reasoning, that text-to-SQL remains sensitive to ambiguity and schema evolution, and that underspecified questions can produce executable rather than cleanly failing outputs. 3 Current production designs consequently inject metadata, verified examples and instructions and, in some cases, add separate SQL-validation steps. 18

The new requirement is therefore not that agents need metadata while software did not. It is that an AI consumer often performs at runtime the semantic binding that deterministic applications performed at development time and humans performed cognitively. That moves semantic metadata from documentation toward executable runtime context.

Data-to-context stack, semantics, quality, lineage and contracts

Data-to-context stack

No evidence supports one mandatory stack implementation. The following is a functional decomposition of information an AI consumer may need, not a reference architecture.

Layer	Examples	Importance for dynamic AI consumption	Why
Physical data	tables, columns, types, partitions, physical names	Essential	Defines what can physically be queried.
Structure	grain, entities, PK/FK, cardinality, relationships	Essential for multi-table use	Schema names alone do not reliably identify valid joins or aggregation behavior. Spider 2.0 and contemporary agent documentation both emphasize relationships and metadata. 3
Business semantics	metric formulas, dimensions, business definitions, units, fiscal periods	Essential where business language differs from schema	Reduces runtime semantic inference. Current conversational platforms explicitly support business terminology, instructions and semantic models. 4
Vocabulary	synonyms, aliases, preferred labels, ontology links	Conditional but high-value for NL interfaces	Connects user wording to governed concepts. SKOS provides long-standing machine-readable patterns for preferred/alternative terminology; ODCS 3.2 adds synonyms. 11
Operational trust metadata	last successful refresh, run status, freshness SLA, quality state, restatement/version	Essential when timeliness or quality can alter interpretation	Allows a consumer to distinguish “query succeeded” from “source is currently trustworthy.” OpenLineage and ODCS expose pieces of this. 7
Ownership	data owner, metric owner, domain, support/escalation route	Important; runtime need is conditional	Enables responsibility and escalation when semantics cannot be resolved. ODCS exposes team/roles/support information. 12
Behavioral context	verified queries, canonical examples, tool instructions, known caveats	Optional, often high-value	Reduces degrees of freedom for recurring or critical questions. Google, Snowflake, Databricks and ODCS now expose variants of this idea. 4
Policy / authority	row/column policy, tenant boundary, allowed operations, purpose constraints	Essential	Determines what may be accessed or changed independently of model preference. 19
Provenance	source IDs, query/tool calls, semantic version, timestamp, transformations	Essential for consequential answers/actions	Supports reproduction, explanation and incident investigation. W3C PROV and OpenLineage provide interoperable building blocks. 20

Ontologies and knowledge graphs are not universally essential. They are useful when entity relationships, terminology or inference cannot be represented economically in tables, metric definitions and metadata, but OWL/SKOS are general semantic technologies, not requirements invented by agentic AI. 11

Verified queries are also not universally essential. They trade breadth for stronger anchoring on known business logic. Google’s current implementation can execute deterministic SQL when a verified query matches a user prompt, while Snowflake explicitly warns that incorrect verified queries can harm accuracy. This makes them closer to curated testable behavior than to a substitute for complete semantics. 4

The diagram is deliberately a control-flow abstraction rather than a proposed architecture: discovery, context and semantics might live in one semantic service, multiple catalogs, application code, a contract registry or the warehouse itself.

Business-semantics requirements

Can an agent infer semantics safely from schemas? Sometimes; not reliably as a general enterprise assumption. Spider 2.0’s tasks frequently require metadata, external documentation and project code in addition to schema. The benchmark’s average enterprise schema is vastly larger than older text-to-SQL datasets, and its authors identify schema linking and external context as major obstacles. Current provider designs independently expose descriptions, PK/FK relationships, business terms, examples and instructions rather than relying solely on physical schemas. 3

Metric conflicts are qualitatively more dangerous when resolved invisibly. The evidence does not establish one standard resolution mechanism. A defensible synthesis is that competing definitions should be represented as distinct governed artifacts carrying scope, owner, version and effective period; absent a deterministic default, the agent should expose the ambiguity or ask for clarification rather than choose from lexical similarity alone. This is an interpretation supported by research showing the risk of underspecified query execution and by Google’s warning that agents spanning teams with different metric definitions can suffer ambiguity and instructional conflict. 21

Temporal semantics must be versionable when the meaning itself changes. “Revenue FY2025” is not reproducible if the organization later changes recognition logic and only the current definition survives. Neither a table timestamp nor column-level lineage alone captures that. The evidence supports storing versioned contracts and semantic artifacts; treating effective-from/effective-to definitions as first-class runtime context is a design inference rather than an established universal standard. ODCS itself versions contracts, while schema-evolution research shows that database change can materially degrade model behavior. 12

A semantic layer is neither necessary nor sufficient. It is not necessary because agents can successfully query physical schemas with enough metadata, examples, retrieval and reasoning. It is not sufficient because semantic models themselves can be incomplete or allow unsafe combinations: Snowflake’s 2026 behavior change converted one previously nondeterministic semantic-view pattern into a compile-time error after identifying the risk that users could make decisions from arbitrary values. 17 The actual requirement is therefore enforced semantic constraints, which can be implemented through a semantic layer, domain API, curated views, metric service, verified templates or combinations.

Data quality and freshness

Traditional dimensions such as completeness, uniqueness, validity, consistency, freshness and accuracy do not change because an LLM reads the data. What changes is the failure mode: the model can convert bad data into a polished explanation without independently noticing the quality incident. Google’s own conversational-analytics documentation explicitly warns that output may appear plausible while being factually wrong and recommends validation. 4

This makes machine-readable quality state more important than an additional “AI quality” dimension. ODCS already allows human-readable, library-based, SQL and custom quality rules, demonstrating that executable quality metadata does not require an AI-specific architecture. 22 The agent-specific extension is to make relevant status available during source selection or before an answer/action is finalized.

Freshness similarly becomes part of semantic interpretation when a question is temporal. For an AI consumer, useful runtime information can include:

source_as_of, last successful refresh, current pipeline state, expected freshness/SLA, late-arriving-data status, restatement status, semantic-definition version and cache age.

OpenLineage’s event representation contains event time, run state and input/output datasets, while data contracts can encode lifecycle and service expectations; together they provide building blocks, but no reviewed standard fully defines the “trust envelope” that should accompany every AI answer. 7

Lineage and ownership

Existing machine-readable lineage is a useful substrate rather than a complete answer. OpenLineage represents jobs, runs, datasets, timestamps, state transitions and input/output relationships. That is suitable for determining where data came from and whether a producing run failed. 7

An AI-generated analytical answer can require more: which metric definition was selected, which version applied, why one source was considered authoritative, what query was emitted, what quality state existed, and which transformations produced the returned number. W3C PROV can represent generalized provenance across entities and activities, but neither OpenLineage nor PROV automatically supplies business-semantic justification simply by being deployed. 7 Thus pipeline lineage is necessary in many cases but insufficient by itself for answer provenance.

Ownership remains an old requirement with a new possible machine use. Contracts already represent teams and roles; current contract standards also define support channels. 12 Whether an agent should automatically route an unresolved ambiguity to a named metric owner is not established by empirical evidence, but ownership metadata makes such escalation possible. Research on answerability supports the more fundamental requirement that the system have a state other than “guess.” 21

Data-contract implications

Data contracts become particularly relevant because an agent may discover a dataset dynamically rather than being compiled against one API at development time. A machine-readable contract can expose:

Contract element	What it protects against	What it cannot guarantee
Schema/types/keys	structural incompatibility	correct business interpretation
Business description/semantic role	some semantic ambiguity	completeness or truth of definition
Quality checks	known detectable data defects	real-world accuracy beyond measured checks
Freshness/SLA	unnoticed staleness when enforced/exposed	correctness of fresh data
Ownership	orphaned responsibility	timely human response
Version/deprecation	silent structural evolution	all model sensitivity to change
Synonyms/context	terminology mismatch	perfect natural-language mapping
Verified statements/examples	common-query drift	correctness for novel questions
Constraints	declared prohibited usage	enforcement unless a deterministic mechanism honors them

ODCS v3.2.0 is unusually relevant to this investigation because its September 2026 additions explicitly include context.instructions, verifiedStatements, constraints, synonyms and semantic types while remaining additive to the conventional data-contract concept. 2 This is evidence against the idea that agent readiness necessarily requires a replacement architecture; an existing governance artifact is instead becoming more machine-legible.

Contracts also cannot eliminate AI fragility under change. EvoSchema reports performance degradation under schema evolution and finds table-level changes especially impactful. 23 A contract can notify or describe a change; it does not prove that an LLM will correctly reinterpret every dependent question after that change.

Interfaces, tool design, identity and the read/write boundary

AI-facing interface patterns

The relevant design axis is degrees of semantic and operational freedom, not whether the transport happens to be REST, SQL or MCP.

Interface pattern	Model freedom	Semantic constraint	Typical strength	Typical failure mode
Generic SQL execution	Very high	Low unless views/policies constrain it	Novel analysis, broad exploration	wrong table/join/grain; overbroad scanning; unsafe SQL surface
Curated SQL views	High	Moderate	Restricts physical complexity and unsafe joins	business meaning can still be inferred incorrectly
Semantic SQL / metric API	Moderate	High for modeled concepts	Governed metrics/dimensions	incomplete model; unsupported questions; semantic-model defects
Parameterized verified query	Low–moderate	Very high for covered task	Repeatable critical questions	template may become stale or encode wrong logic
Domain-specific typed tool/API	Moderate	High	Clear intent and parameter boundaries	tool semantics can still be poorly documented
Metric-specific tool	Low	Very high	High-control recurring metric retrieval	tool proliferation and limited composability
High-level business action	Low in execution, potentially broad consequence	Can be very high	Allows policy and validation around a business operation	severe side effects if authorization/validation fails
MCP or comparable protocol	Orthogonal	Depends on exposed tools	Standardized discovery/invocation and structured schemas	protocol interoperability mistaken for semantic/governance safety

MCP’s July 28, 2026 specification supports JSON-schema input and output definitions and structured tool results. That gives tools a syntactic machine contract. It does not define the underlying business meaning of get_revenue, prove its freshness, or decide who should be authorized to call it. 16

MCP is therefore best categorized as an emerging interface protocol, not an agent-ready data architecture. Its current stateless design also illustrates an agent-specific systems issue: cross-call workflow state must be represented explicitly, such as server-minted handles, and its security guidance says possession of a state handle must not substitute for authentication. 24

Tool-design trade-offs

The evidence does not support “always give the agent SQL” or “never give the agent SQL.”

Generic SQL maximizes analytical coverage. Spider 2.0 demonstrates why it is challenging at enterprise scale, but rapid benchmark progress also shows that raw or lightly mediated SQL should not be dismissed as inherently unworkable. 3

Narrower tools remove degrees of freedom. Current provider implementations increasingly expose verified queries, functions, semantic models or curated knowledge sources for high-confidence recurring behavior. Google ranks verified queries above glossary and natural-language instructions in its current conversational-analytics guidance, and Databricks exposes example SQL/functions together with metadata and instructions. 4 This is production-design convergence, not independent proof that a particular granularity optimizes total accuracy.

A useful evidence-backed continuum is:

exploration → constrained analysis → repeatable governed question → business action

As the consequence of an operation increases, current security guidance consistently argues for stricter tool boundaries, input validation, least privilege and explicit approval for high-impact actions. 25

The unresolved technical question is where to place the abstraction boundary for each workload. There is no evidence of a universally optimal ratio of generic SQL tools to domain-specific tools.

Permission and identity model

Three concepts must remain distinct:

Layer	Question it answers	Appropriate enforcement
Authentication	Who/what is making the request?	Identity provider, credentials, token validation
Authorization	May this principal perform this operation on this resource now?	IAM/RBAC/ABAC, RLS/CLS, policy engine, scoped token/tool permission
Model reasoning	Which operation does the agent believe will accomplish the task?	Model + context; not a security boundary

Traditional row- and column-level controls remain applicable because they are evaluated by the data system rather than by the LLM. BigQuery, for example, documents query-time row- and column-level access mechanisms independent of how the query text was produced. 19

User-delegated identity preserves the opportunity to evaluate existing per-user data policy. Agent/service identity is legitimate when the agent owns an explicit workload authority, but creates a different risk if a broadly privileged principal is used on behalf of many users. NIST’s 2026 concept work specifically calls out identification, authorization, auditing and non-repudiation for software agents accessing data, tools and applications. 6

OAuth remains relevant rather than being displaced by agent protocols. RFC 9700 is the current OAuth 2.0 security best-current-practice specification, and MCP security guidance applies resource/audience-bound authorization principles while explicitly prohibiting unsafe token passthrough. 26

Purpose limitation is a harder problem than basic access. A user may be allowed to see customer email addresses for support but not use them for unrelated marketing analysis. Row/column access alone does not encode all such purposes. Agent instructions can describe the constraint, but deterministic policy must enforce any requirement that cannot safely depend on model compliance. The exact enforcement architecture remains domain-specific.

Read versus write

The evidence supports treating authority escalation, rather than “AI access,” as the key transition:

Consumer mode	Typical capability	Additional concern
Assistant	Read selected data and answer	semantic correctness, provenance
Analytical agent	Discover sources, issue several queries, validate, synthesize	multi-step error propagation, costs, state
Data/coding agent	Generate SQL/code, perhaps produce derived artifacts	execution sandbox, resource scope, schema change
Operational agent	Update records, trigger workflows, call transactional APIs	durable side effects, idempotency, transactions, approvals, rollback

Current analytics agents provide concrete evidence that read-only surfaces are practical boundaries: Databricks documents generated Genie queries as read-only, while conversational systems commonly separate analysis from operational mutations. 18 This is not proof that all read and write infrastructure should be physically separated.

The stronger conclusion is logical separation of authority. A write tool should have its own authorization, validation and audit boundary instead of inheriting authority merely because an agent can read related data. OWASP’s current guidance treats tool execution as a high-risk boundary, calls for input allowlisting and least privilege, and recommends confirmation before irreversible or high-impact actions. 25

For writes, several conventional distributed-systems concerns become much more prominent: idempotency, duplicate-action prevention, preconditions, transaction boundaries, retry semantics, rollback/compensation and explicit actor identity. These principles are not AI inventions; probabilistic planning simply creates another mechanism that can trigger them incorrectly.

Provenance, discovery, observability, security and platform architecture

Provenance requirements

Three concepts should not be conflated:

Lineage describes how data assets and transformations relate.
Provenance describes the origin and processing history of a particular result/artifact.
Observability records operational behavior so the system can be monitored and debugged.

W3C PROV has provided interoperable provenance representation since 2013, while OpenLineage provides data-pipeline-oriented run/job/dataset metadata. 20 AI therefore does not invent provenance; it creates a richer provenance object.

For a consequential AI answer, a useful evidence envelope may include:

Provenance field	Why it matters	End-user visibility
Source dataset/table/view IDs	establishes source	Often useful
Source snapshot/as-of time	distinguishes current from stale historical answer	Usually useful when temporal
Metric/semantic definition + version	reproduces meaning	Useful for disputed/important metrics
Generated SQL / query template / tool call	reproduces computation	Often link/details rather than primary display
Transformations/lineage	traces derivation	Usually detailed view
Quality/freshness state	indicates known trust condition	Useful when degraded
Principal and policy context	reconstructs authority	Mostly audit/security log
Agent/model version	reconstructs model behavior	Mostly log
Tool/server version	reconstructs execution behavior	Mostly log
Validation/check results	shows what was checked	Useful for high-consequence workflows
Result/action identifier	connects answer to side effects	Important for operational agents

This is a synthesized target, not a single existing standard. W3C PROV, OpenLineage and GenAI telemetry conventions cover overlapping pieces, but the reviewed evidence does not show a mature universal specification for an end-to-end question → context → semantic choice → query/tool → answer/action evidence bundle. 20

Discovery and catalog requirements

A machine-readable catalog is not uniquely an AI need. DCAT 3, a W3C Recommendation from August 22, 2024, standardizes interoperable descriptions of datasets and data services and enables catalog aggregation and federated discovery. 14

What changes for AI is that discovery can move from a human search step to an autonomous decision inside execution. That increases the consequences of poor ranking, duplicates, obsolete datasets and competing definitions. Schema-linking research similarly identifies source/schema selection as a central text-to-SQL challenge. 3

There is no strong evidence that unrestricted discovery across an entire enterprise estate is desirable. Current Google guidance actually points in the other direction: data agents have selected knowledge sources, and the documentation says broadly scoped agents can suffer instructional conflicts, ambiguous outputs and inconsistent performance, particularly where teams use different metric definitions. 4

The emerging pattern is therefore broad catalogability but scoped execution context: an asset may be discoverable to an authorized principal without every discoverable asset being simultaneously injected into the model context or considered an equally authoritative query target. This is an interpretation supported by both context-window/schema-linking research and production system design. 3

Data-product implications

The data-product concept does not need to be redefined merely because one consumer is an AI. The additional consumer contract can, however, include machine-facing semantics, quality, constraints, examples and interfaces.

This has already begun in an open standard: Bitol’s Open Data Product Standard v1.1.0 added optional structured context for AI agents and semantic tools, including guidance on which output port to use. 13 That is evidence of an existing data-product abstraction accommodating agents rather than agents requiring a fundamentally different product boundary.

Agent-specific acceptance criteria could include whether the supported semantic concepts are machine discoverable, whether ambiguous questions have defined behavior, whether freshness/quality is inspectable, whether the interface carries deterministic permissions, and whether answers/actions can be traced. Those criteria are synthesis, not yet an industry-wide standard.

Observability requirements

Conventional query telemetry remains necessary: SQL, latency, errors, scanned bytes, costs, pipeline failures and authorization denials have not become obsolete.

Agentic execution adds useful correlations among:

question/task → selected sources → retrieved semantic context → generated SQL/tool selection → exact parameters → tool result → validation → answer → downstream action.

OpenTelemetry’s current GenAI semantic-convention work includes concepts for agents, conversations, data sources/retrieval and tool calls/results, showing that the observability ecosystem is actively extending conventional traces into this domain. 27

More telemetry creates a privacy conflict. Prompts, retrieved documents, SQL, tool arguments and outputs can themselves contain PII, credentials or commercially sensitive data. The correct conclusion is not “log everything”: exact action parameters may be valuable for audit, while free-form content may need opt-in collection, redaction, access segregation or retention controls. OWASP recommends recording tool invocations and relevant action context for security investigation, while telemetry specifications separately recognize sensitive payload concerns. 28

Security threat model

Some agent risks are genuinely new pathways; others are old security failures with a probabilistic intermediary increasing reach or exploitability.

Threat	New or amplified?	Mechanism	Deterministic control class
Indirect prompt injection through data/metadata/tool output	Qualitatively new AI pathway	Retrieved content is interpreted as instructions	Treat external content as untrusted; separate instructions/data; restrict tools; confirmation for consequential actions. 29
Malicious descriptions/catalog metadata	New pathway, old untrusted-input principle	Poisoned metadata changes reasoning/source selection	Provenance/trust tier for metadata; context isolation; review governed definitions
Tool-description manipulation	New agent surface	Agent selects/calls a misleading tool	Trust server/tool registry; signed/governed definitions where appropriate; least privilege
Excessive agency	Amplified privilege problem	Model can chain individually permitted operations into harmful outcome	Narrow scopes, action allowlists, budgets, approval gates. 25
Unrestricted SQL	Old DB risk amplified	dynamic query synthesis explores unintended data/cost surface	read-only roles, RLS/CLS, query controls, allowlisted environments
Cross-tenant leakage	Old isolation risk amplified	source/tool selection crosses tenancy boundaries	tenant-scoped identities and data enforcement
Confused deputy	Old security class, important agent amplification	intermediary uses its authority for another principal incorrectly	per-client consent and explicit delegation. 24
Token passthrough / audience confusion	Old OAuth failure, agent-protocol relevance	token intended for one service is reused downstream	resource-bound tokens, audience validation; no passthrough. 24
Tool-input/code execution abuse	Old injection/sandbox problem amplified	generated input escapes intended operation	schemas + validation + sandbox + low privilege. 28
Persistent memory/context poisoning	Agent-specific persistence pathway	malicious context survives across future tasks	scoped state, provenance, expiry, write authorization for memory
State-handle hijacking	Old object-authorization problem in new protocol context	workflow handle is mistaken for identity	bind handle to authenticated principal; unpredictable/expiring handles. 24
Cascading wrong actions	Amplified	incorrect semantic inference becomes operational side effect	validation, idempotency, transactional boundary, circuit breaker
Prompt-as-policy	Category error	natural-language instruction treated as access control	authorization enforced by platform/tool, never by model obedience

OWASP’s current agentic guidance explicitly documents indirect prompt injection from tool output leading to exfiltration, unauthorized API calls, deletion or lateral movement, and separately warns that over-permissioned tool contexts increase execution risk. 29 NIST’s February 2026 work likewise identifies agent identification, authorization, auditing, non-repudiation and prompt-injection controls as open standards/practice concerns. 6

Platform-architecture changes

Evidence supports localized architectural extensions, not wholesale replacement of the data stack.

Platform component	Material agent-driven change	Degree of novelty
Warehouse/lakehouse/database	No inherent storage-engine change required	Low
Transformation/modeling	Grain, relationships and semantic intent become more important inputs to automated consumers	Amplified old requirement
Semantic/metric layer	Can become a machine-facing contract for governed interpretation	Existing component with expanded consumer
Catalog	Search/retrieval becomes runtime agent infrastructure rather than only human documentation	Qualitative usage change
Metadata	Must be machine-readable, scoped and retrievable with source/version/trust information	Significant amplification
Quality system	Current quality status ideally consumable during source choice/answer validation	Runtime integration change
Lineage	Pipeline lineage increasingly connected to answer/action provenance	Extension
Orchestration	Pipeline status/freshness becomes useful agent context	Integration change
API/tool layer	Typed model-facing tools, semantic APIs and/or protocol adapters are often new	Most visibly new component
Identity	User delegation, agent principals and cross-tool authority need explicit treatment	New usage of established security primitives
Governance/policy	Policies must survive probabilistic reasoning through deterministic enforcement	Amplified old requirement
Observability	Trace expands across model/context/tool/data/action chain	Significant extension

There are at least three valid patterns in the evidence:

agent → SQL/database

agent → semantic/metric abstraction → database

agent → narrow domain tools/APIs → data/operational systems

Hybrid systems combine them. Current evidence does not justify declaring one of these “the” agent-ready architecture.

What does not actually change

The following remain foundational rather than newly AI-specific:

clear ownership; explicit data modeling; quality controls; stable contracts; testing; access control; lineage; freshness monitoring; observability; versioning; least privilege; error handling.

Indeed, recent agent-oriented standards evolution strengthens rather than replaces those mechanisms. ODCS adds agent context to its existing schema/quality/ownership contract; MCP builds on established OAuth security principles; conversational data systems still depend on ordinary warehouse permissions. 12

The defensible interpretation is that agents make the cost of implicit semantics and weak governance visible more quickly. They transform accumulated documentation and modeling debt into runtime model uncertainty.

Failure modes and contradictions

Failure-mode catalogue

Failure mode	Mechanism	Why agents alter severity	Likely detection/control	Classification
Wrong metric definition	ambiguous term mapped to one of several metrics	plausible answer hides unresolved choice	versioned definitions; scoped defaults; clarification	Amplified
Wrong table/source	semantic retrieval selects obsolete/non-authoritative source	dynamic source choice	authority metadata; curated domains; source provenance	Amplified
Wrong join	FK/grain unclear	generated SQL can execute successfully	modeled relationships; validation queries	Amplified
Double counting	incompatible grain/aggregation	result may remain numerically plausible	metric semantics, grain constraints, query checks	Amplified
Underspecified question answered anyway	model guesses missing conditions	executable misleading output instead of exception	answerability gate/refusal/clarification; empirically motivated by LatentRefusal. 21	AI-specific behavior
Stale source treated as current	freshness omitted from context	model sees values, not pipeline operational state	source-as-of, run state, freshness SLA	Amplified
Pipeline failure invisible	last good data remains queryable	SQL succeeds despite failed refresh	machine-readable run status from orchestration/lineage	Amplified
Restated history not disclosed	values changed after prior answer	apparently identical query gives different history	snapshot/version/restatement provenance	Amplified
Semantic definition changed	same term now means something different	natural-language query remains unchanged	effective semantic versions	Amplified
Schema evolution	renamed/moved/added entities alter mappings	text-to-SQL models degrade under evolution	contracts, compatibility tests, regression evaluation. 23	Amplified
Verified query is wrong/stale	supposedly trusted exemplar encodes defect	trusted context can anchor model to the wrong logic	lifecycle/version/tests; Snowflake warns invalid verified queries can degrade accuracy. 30	Old defect, stronger propagation
Too much metadata/context	relevant schema diluted by enterprise-scale context	context retrieval itself becomes a reasoning task	selective schema/context retrieval. 3	AI-specific scaling issue
Conflicting agent instructions	multiple domains encode different defaults	model reconciles instead of failing deterministically	scope agents/context by domain. 4	AI-specific
Prompt injection in catalog/data	untrusted string interpreted as command	data becomes part of instruction surface	context isolation, least privilege. 29	AI-specific pathway
Overbroad service identity	agent sees more than initiating user	natural-language interface expands reach of privilege	delegation, scoped credentials, RLS/CLS	Amplified
Confused deputy	agent/tool proxy misuses authority	multi-tool chaining creates transitive authority	audience binding/per-client consent. 24	Amplified
Duplicate write	retry/reasoning repeats action	probabilistic workflow can retry without idempotent semantics	idempotency key, transaction/action state	Amplified
Failed validation ignored	model decides warning is nonessential	warning becomes another piece of text	hard deterministic gate	AI-specific control requirement
Insufficient provenance	answer cannot be reproduced	dynamic context/model choices disappear	answer-level evidence record	Amplified
Sensitive debug logs	prompts/tool results persisted	richer context increases logged sensitive data	redaction, access segregation, minimal logging	Amplified

The catalogue illustrates an important pattern: relatively few core data failures are newly invented by AI. Newness concentrates at the interpretation boundary—silent semantic inference, indirect prompt injection, instruction/context conflicts and refusal behavior. Many other failures are familiar data or security problems with a new mechanism for amplification.

Contradictions in the evidence

Tension	Evidence on one side	Evidence on the other	Resolution supported by evidence
“A semantic layer is required for agents.”	Looker/dbt-style systems expose explicit semantic models; provider docs emphasize governed metrics. 9	Text-to-SQL agents can operate directly over databases and metadata; no empirical paper establishes a semantic layer as necessary. 3	Conditional. The need is explicit/enforced semantics, not necessarily a product called a semantic layer.
“Raw SQL is too unreliable.”	Enterprise benchmarks expose difficult schema-linking and semantic errors. 3	Spider 2.0 systems improved rapidly after the original paper; flexible SQL remains useful for novel analysis. 31	Risk depends on novelty and consequence. Constraining degrees of freedom trades analytical coverage for predictability.
“More context makes agents better.”	Production systems add descriptions, glossaries, instructions, examples and keys. 4	Large schemas create long-context/schema-linking difficulty; context-compression research specifically treats representation size as a bottleneck. 3	Relevant context beats maximal context. Retrieval/routing is part of the problem.
“Verified queries create trustworthy answers.”	Google prioritizes verified deterministic queries; Snowflake supports verified-query repositories. 4	Snowflake warns incorrect verified queries can harm performance/accuracy. 30	Verified examples are governed executable artifacts, not ground truth by definition.
“A semantic model prevents semantic errors.”	Semantic abstractions reduce arbitrary schema reasoning.	Snowflake had to disable a fact+dimension pattern because its semantic view could produce nondeterministic values. 17	Representation without enforced constraints is insufficient.
“Enterprise-wide discovery is desirable.”	DCAT and catalogs are explicitly designed to improve cross-catalog discoverability. 14	Google’s agent guidance warns broad scopes can cause ambiguity/conflicting definitions. 4	Broad metadata discovery and narrow runtime execution context are compatible; they need not be the same scope.
“MCP makes data agent-ready.”	MCP standardizes model-facing tools and structured schemas. 16	MCP security guidance still requires authorization controls; the protocol does not define company metrics, quality or authoritative sources. 24	MCP solves interoperability/interface plumbing, not semantic or governance correctness.
“Agents create new data-quality requirements.”	AI may convert defects into plausible narratives; runtime quality context matters. 4	Quality rules, SLAs and contracts long predate agent consumers. 32	Mostly an exposure/timing change, not new quality dimensions.
“Humans should approve agent actions.”	Security guidance recommends confirmation for irreversible/high-impact actions. 25	Requiring approval for every read or low-risk operation destroys autonomous-agent utility; no standard establishes a universal threshold.	Approval is risk-dependent; deterministic authority limits remain necessary even without a human checkpoint.

Claim-to-source dossier, unresolved questions and research frontier

Claim-to-source table

The table below records the most load-bearing claims. “Supported” means the evidence directly supports the stated claim within its context; it does not imply universal validity.

Exact claim	Evidence type	Architecture / context	Source date	Inspected	Direct URL / DOI	Status	Main limitation
Realistic enterprise text-to-SQL requires more than schema alone: tasks can require metadata, dialect documentation and project code.	Empirical benchmark	Enterprise SQL/data engineering	2024-11-12	2026-10-03	https://arxiv.org/abs/2411.07763	Supported 3	Original model scores are historical by 2026; benchmark approximates, not perfectly reproduces, every enterprise estate.
Underspecified or unanswerable text-to-SQL requests may yield executable but misleading programs rather than clean refusal.	Empirical research	LLM text-to-SQL	2026	2026-10-03	https://aclanthology.org/2026.findings-acl.1007/ ; DOI: 10.18653/v1/2026.findings-acl.1007	Supported 21	Specific experimental setting; does not quantify all production agent failure rates.
Schema evolution can degrade text-to-SQL robustness, with table-level perturbations having greater effect in the reported evaluation than column-level ones.	Empirical benchmark	Dynamic database schemas	2026-03-11	2026-10-03	https://arxiv.org/abs/2603.10697 ; DOI: 10.48550/arXiv.2603.10697	Supported 23	Benchmark perturbations may not match a specific enterprise’s change distribution.
Current conversational-data systems expose metadata, business terms, instructions, glossaries and verified queries as agent context.	Documented architecture	BigQuery conversational analytics	Living docs, 2026 state	2026-10-03	https://docs.cloud.google.com/bigquery/docs/conversational-analytics	Supported 4	Provider design, not independent proof of optimality.
Broadly scoped conversational-data agents can encounter conflicting instructions/metric definitions; the provider recommends scope reduction.	Production/provider guidance	BigQuery agents	Living docs, 2026 state	2026-10-03	https://docs.cloud.google.com/bigquery/docs/conversational-analytics	Supported in that product 4	Provider observation; not a controlled cross-platform study.
A semantic abstraction does not by itself guarantee deterministic semantics: Snowflake disabled one fact+dimension query pattern that could return arbitrary values.	Production behavior change	Snowflake semantic views	2026-07 bundle	2026-10-03	https://docs.snowflake.com/en/release-notes/bcr-bundles/2026_07/bcr-2287	Supported 17	Specific semantic-view behavior; not evidence against semantic layers generally.
Open data contracts can represent structure, semantics, quality and ownership, and ODCS v3.2 adds optional context, verified statements and constraints for AI/semantic consumers.	Open standard/specification	Data contracts	2026-09	2026-10-03	https://bitol-io.github.io/open-data-contract-standard/latest/context/	Supported 2	Standard availability does not establish adoption or enforcement quality.
Machine-readable quality checks do not require an AI-specific architecture.	Open standard/specification	ODCS quality	Current v3.2.0	2026-10-03	https://bitol-io.github.io/open-data-contract-standard/v3.2.0/data-quality/	Supported 22	A rule describes/tests a property; it cannot guarantee unmeasured accuracy.
Pipeline lineage can be expressed as machine-readable events containing run/job/dataset identity, timestamps, state and input/output datasets.	Open specification	Data-pipeline lineage	Living specification	2026-10-03	https://openlineage.io/apidocs/openapi/	Supported 7	Does not automatically encode business semantic choices or full answer provenance.
Interoperable provenance representation predates generative AI.	W3C Recommendation	General provenance	2013-04-30	2026-10-03	https://www.w3.org/TR/prov-overview/	Supported 20	Generic provenance model; application must populate relevant events/artifacts.
Interoperable machine-readable catalog discovery predates agentic AI.	W3C Recommendation	Dataset/data-service catalogs	2024-08-22	2026-10-03	https://www.w3.org/TR/vocab-dcat-3/	Supported 14	Discovery metadata does not establish business authority or semantic correctness.
MCP tools can declare structured input/output schemas.	Protocol specification	Agent/tool interoperability	2026-07-28	2026-10-03	https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx	Supported 16	Syntactic schemas do not establish business semantics or correctness.
MCP introduces no substitute for proper authorization; its guidance identifies confused-deputy, token-passthrough and state-handle risks.	Protocol security guidance	Agent/tool interoperability	2026-07-28	2026-10-03	https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/docs/2026-07-28/tutorials/security/security_best_practices.mdx	Supported 24	Guidance focuses on MCP deployments; underlying security classes are broader.
Agent identity/authority requires explicit treatment of identification, authorization, auditing and non-repudiation.	Government concept paper	Software/AI agents	2026-02-05	2026-10-03	https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents	Supported as problem framing 6	NIST document is a concept paper, not a normative standard or proven architecture.
Retrieved/tool content can carry indirect prompt injection that causes unauthorized operations or data exfiltration if treated as trusted instructions.	Security guidance	Tool-using agents	Current 2026 guidance	2026-10-03	https://cornucopia.owasp.org/cards/AAI7	Supported as threat class 29	Threat guidance does not establish population-wide incidence.
Tool input requires deterministic validation/sandbox/least privilege because model-generated tool parameters can cause unintended execution.	Security guidance	Tool-executing agents	Current 2026 guidance	2026-10-03	https://cornucopia.owasp.org/cards/AAI8	Supported as control principle 28	Specific controls vary with tool and environment.
OAuth security principles remain applicable to agent protocols rather than being replaced by model instructions.	IETF Best Current Practice + MCP guidance	Delegated authorization	RFC 9700, 2025	2026-10-03	https://www.rfc-editor.org/rfc/rfc9700.html ; DOI: 10.17487/RFC9700	Supported 26	Does not itself solve business-purpose authorization or multi-agent delegation.
Existing row/column access controls can remain authoritative even when an AI generates the query.	Documented architecture	BigQuery authorization	Living docs	2026-10-03	https://docs.cloud.google.com/bigquery/docs/column-level-security ; https://docs.cloud.google.com/bigquery/docs/managing-row-level-security	Supported conditionally 19	Correct only if execution preserves the appropriate principal and policies.
Agent observability increasingly includes model, agent, retrieval and tool telemetry.	Open telemetry specification	GenAI observability	Living specification	2026-10-03	https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/	Supported 27	Conventions are evolving; capturing payload content raises privacy concerns.
“AI-ready/agent-ready” does not currently identify one canonical technical architecture.	Cross-source interpretation	Industry terminology	2026 snapshot	2026-10-03	Examples: https://tdengine.com/ai-ready/ ; https://www.ibm.com/products/watsonx-data-intelligence ; https://bitol-io.github.io/open-data-contract-standard/latest/context/	Supported as reviewed-corpus interpretation 8	Absence of a canonical definition cannot be universally proven; terminology can still converge later.
Most agent-ready requirements are existing data-platform practices made explicit, machine-readable and runtime-accessible; the clearest genuinely new areas are probabilistic semantic resolution, hostile model context, tool mediation and answer/action provenance.	Cross-source synthesis	Overall architecture	2026 snapshot	2026-10-03	Derived from sources above	Conditional synthesis	Independent comparative production research remains limited.

Unresolved questions

The evidence is considerably stronger about what information and controls matter than about which architecture implements them best.

Unresolved question	Current evidence state
How much does an explicit semantic layer improve end-to-end agent accuracy compared with excellent schemas, metadata and retrieval?	Provider designs strongly favor semantics/context, but independent controlled enterprise comparisons remain limited.
What is the optimal tool granularity?	Security arguments favor narrow tools; analytical novelty favors generic SQL. No general empirical optimum is established.
What quality/freshness signals should automatically force refusal rather than merely generate a warning?	Standards can express quality; decision thresholds remain application-specific.
How should conflicting metric definitions be resolved automatically?	Scoping, versioning and clarification are defensible; no universal algorithm or standard exists.
What exact metadata should be injected versus retrieved on demand?	Large-context research argues against indiscriminate context, while production systems expose increasingly rich context. Retrieval policy remains active research. 3
How should purpose limitation propagate through multi-tool/multi-agent workflows?	OAuth/IAM solve parts of identity and resource authorization; semantic business purpose and transitive delegation remain less mature.
What constitutes sufficient answer-level provenance?	PROV, OpenLineage and telemetry provide primitives; a shared cross-system AI-answer schema is not mature.
Can an agent reliably determine when it does not know enough to answer?	Refusal research is active and demonstrates the problem, but calibration/generalization remain unresolved. 21
Who owns compatibility when AI is a data-product consumer?	Existing producer/data-product ownership suggests the domain remains responsible for its contract; responsibility for model-specific adapters is organization-dependent.
How should historical metric definitions and data restatements interact?	Versioning primitives exist, but end-to-end temporal semantic provenance is fragmented.
How much enterprise discovery should an autonomous agent receive?	Catalog standards favor discoverability; current agent systems and context research favor scoped execution. Optimal routing policies remain unsettled.
At what consequence threshold should an operational agent require human approval?	Security guidance establishes the principle for high-impact/irreversible operations but not universal thresholds. 25

Research frontier

The most valuable future evidence is unlikely to come from another definition of “AI-ready data.” It will come from controlled tests of specific additional requirements.

Semantic robustness under real organizational ambiguity. Existing text-to-SQL benchmarks increasingly capture schema scale and schema evolution, but enterprise evaluations need competing metric definitions, aliases, unmodeled grain, fiscal calendars, restatements and intentionally underspecified questions. Spider 2.0, EvoSchema and answerability work are important foundations rather than complete tests of business semantics. 3

Runtime trust-state contracts. Data quality, freshness, pipeline health, semantic version and authoritative-source status currently live in partly separate systems. ODCS, OpenLineage and semantic layers are converging toward richer machine-readable metadata, but evidence is missing on the best interoperable representation for “safe to answer now.” 33

Answer-level provenance. There is room for a standardized evidence object linking principal, source, source version, semantic definition, query/tool call, quality/freshness state, model/tool versions and output. W3C PROV is general enough to model provenance, but the ecosystem lacks a ubiquitous agent-data profile. 20

Authorization across agent chains. User delegation, agent identity, resource-bound credentials, purpose restrictions and transitive authority across tools are active security problems. NIST’s 2026 initiative and MCP’s rapidly evolving security specification show that this layer is not settled. 6

Metadata as hostile input. Data catalogs historically treated descriptions as documentation. For an LLM, descriptions and even data values can become behavior-shaping context. The research frontier is not merely sanitizing obvious strings but building trust tiers, provenance and instruction/data isolation that remain robust against indirect injection. 29

Tool-granularity experiments. Strong comparative evidence is needed for generic SQL versus semantic APIs versus verified templates versus domain tools across four metrics simultaneously: semantic correctness, task coverage, security exposure and maintenance cost. Current evidence documents the trade-off but does not identify a universal optimum.

Change compatibility for probabilistic consumers. Conventional schema compatibility asks whether software still parses. Agent compatibility must additionally ask whether the same natural-language intent maps to the same meaning after schema or semantic changes. EvoSchema begins measuring the structural part; semantic-contract regression remains comparatively immature. 23

Operational-agent transaction safety. The transition from analysis to action needs empirical evidence around duplicate actions, retries, partial failures, compensation, approval policies and cascading mistakes. Current security guidance establishes guardrails, but systematic production evidence remains sparse. 25

Most defensible bottom line: the evidence does not justify a separate storage paradigm called “agent-ready data.” It does justify a new consumer contract. Compared with a strong conventional platform, that contract makes semantics and trust state machine-legible at runtime, makes ambiguity/refusal explicit, adds a governed model-facing interface, preserves deterministic authorization regardless of model reasoning, treats retrieved context as potentially hostile, and connects questions to data and actions through reproducible provenance. Everything else—including whether this is implemented with a semantic layer, contracts, curated views, APIs, knowledge graphs, MCP, or some combination—remains an architectural choice rather than part of the definition.

AI-Ready and Agent-Ready Data: What the Evidence Actually Establishes

Research snapshot: October 3, 2026
Scope: empirical and technical evidence on data-platform requirements for LLM assistants and agents. Vendor material is used only to identify terminology and audit industry claims, not as evidence that an architecture improves AI performance. The review deliberately distinguishes controlled evaluations, benchmark evidence, technical standards, threat models, and commercial assertions.

Executive synthesis and construct map

The central finding is fairly sharp:

“Agent-ready data” is not an established scientific construct. The literature supports a narrower collection of mechanisms—schema grounding, selective metadata, retrieval, temporal grounding, well-described tools, constrained interfaces, and especially security controls around untrusted context and actions. It does not establish a new, general data-platform architecture that agents require.

Research does show that LLM systems are unusually sensitive to how information is exposed. Schema size matters; relevant database content matters; descriptions can help; irrelevant or excessive descriptions can hurt; tool descriptions measurably affect tool choice; current information must often be retrieved externally; and untrusted data can be mistaken for instructions. Those are real empirical findings. 1

The strongest genuinely agent-specific result is not about semantic layers, data contracts, lineage, or data products. It is about authority and instruction boundaries. Once a model can act through tools, data returned by those tools becomes a potential control channel. AgentDojo explicitly evaluates agents whose external-tool results contain adversarial instructions; InjecAgent reports substantial attack success across more than a thousand indirect-prompt-injection cases; capability/policy-based systems such as CaMeL show that separating trusted control from untrusted data can materially improve security, though generally with utility and deployment assumptions attached. 2

The strongest evidence for metadata is similarly narrower than the rhetoric. SQL-PaLM found that query-specific database content improved BIRD execution accuracy from 55.15% to 58.80%, but supplying full column descriptions reduced it to 54.69%. Soft schema selection could make modest gains while aggressive hard pruning sometimes made performance worse. The same work reports degradation as schemas become wider. The implication is not “more metadata is always better”; it is relevant, correctly retrieved context is useful, while context overload and recall failures are costly. 1

Enterprise realism also changes the picture dramatically. Spider 2.0 contains 632 enterprise-style data tasks over systems including BigQuery and Snowflake, with roughly 812 columns per database on average and tasks that can require metadata, dialect documentation, data-model descriptions, and project code. Early agentic systems achieved only roughly the high teens to low twenties in task success depending on track/setup—far below results on classic Spider—showing that “LLM can do text-to-SQL” does not imply “LLM can reliably navigate an enterprise data platform.” 3

Construct and terminology map

Term	Status in research	What can safely be inferred
AI-ready data	No stable scientific definition found. Current definitions are primarily enterprise/vendor umbrella definitions combining quality, accessibility, governance, context, and traceability. DataHub, IBM and others define overlapping but non-identical properties. 4	Treat as a business label unless an author operationalizes the exact properties being tested.
Agent-ready data	Even less standardized. Recent practitioner definitions add real-time access, context, guardrails and tool/API accessibility. 5	Not an independently validated data-management maturity level.
Semantic layer	Longstanding BI/data architecture concept, but current implementations vary in metrics, entities, dimensions, joins and access semantics; dbt and Databricks describe overlapping but product-specific constructs. 6	A meaningful engineering category, but not one standardized intervention in AI research.
Metadata-rich data	Descriptive phrase rather than a distinct research construct.	Evidence must be decomposed into descriptions, types, keys, examples, values, timestamps, provenance, etc.
Data product	Established practitioner/data-mesh concept; “AI-ready data product” is an emerging extension rather than a benchmarked AI construct. The BDVA publication explicitly presents AI-ready data products as a new paradigm. 7	Claims of improved AI consumption remain mostly extrapolation.
Knowledge graph	Established technical/research representation used extensively in KGQA and graph-RAG research. ToG, for example, has LLMs explicitly explore KG entities and relations. 8	Benefits are task-dependent; existence of a mature KG literature does not establish that enterprise agents require one.
Ontology	Established formal knowledge-representation family; RDF and related Semantic Web work provide explicit model-theoretic semantics. 9	Much more formally grounded than “AI-ready data,” but ontology usefulness to an LLM still requires empirical evaluation.
Context layer	Mainly contemporary architecture/vendor terminology.	No stable intervention or benchmark corresponds to it.
Governed metrics	Practitioner semantic-model terminology describing centrally defined metric logic.	Logical value is clear where business questions depend on metric definitions, but AI-specific controlled evidence is weak.
Provenance	Stable technical construct. W3C PROV models entities, activities, agents, derivation, revisions and time, explicitly supporting traceability, trust assessment and reproducibility. 10	Do not conflate provenance with evidence that an LLM knows how to use provenance correctly.
Lineage	Mature data-management concept closely related to process/derivation provenance.	Direct experiments showing enterprise agents perform better when lineage is supplied are conspicuously scarce.
Data contract	Data/software engineering practice for machine-enforced expectations.	No strong direct evidence located that contracts are a prerequisite for agentic AI.
MCP	A defined interoperability protocol, not a data-quality or semantic model. Its own documentation calls it a standard for connecting AI applications to external data, tools and workflows. 11	Connectivity is not equivalent to correctness, governance, semantic consistency or security.

This distinction is crucial because several industry arguments effectively take a chain of plausible propositions—agents need context; metadata provides context; our semantic/metadata product provides metadata; therefore agents require our architectural layer—and present the conclusion with greater certainty than the empirical literature warrants. The first two links have evidence. The last one usually does not.

Structured-data evidence: schemas, metadata, semantics, graphs, quality, freshness and provenance

AI as a data consumer

There is now substantial empirical evidence for LLMs consuming relational schemas, table contents, database values, API descriptions, retrieved documents, knowledge graphs and structured tool definitions. The evidence base is strongest for text-to-SQL, table reasoning, retrieval, KG question answering, and tool calling; it is much weaker for the holistic enterprise data-platform abstractions described by vendors. 12

BIRD was an important step beyond classic Spider: it contains 12,751 text-to-SQL pairs over 95 databases, about 33.4 GB of data and 37 domains, including dirty database content and questions requiring external/domain knowledge. Its initial ChatGPT baseline achieved 40.08% execution accuracy versus 92.96% for humans. BIRD therefore established that database content and contextual knowledge are first-class parts of realistic text-to-SQL rather than mere SQL-syntax generation. 12

Spider 2.0 goes further toward enterprise workflows. Its tasks involve large schemas, multiple SQL dialects and real enterprise-derived databases, while context may include schema definitions, data-model documentation, repository/code context and external dialect documentation. This is strong evidence that an AI data consumer must often find and combine information that a human data engineer would also need. It is not evidence that any particular commercial semantic architecture is required. 3

Schema and metadata evidence

The schema evidence is one of the strongest areas in the review, but it undermines simplistic “metadata-rich is better” messaging.

SQL-PaLM provides unusually useful controlled ablations. On BIRD, adding query-specific database content raised execution accuracy from 55.15% to 58.80%. Yet adding all available column descriptions dropped performance from 58.80% to 54.69%. Retrieval-based and program-aided schema selection sometimes recovered small gains when relevant columns were described without aggressively removing the rest; oracle selection reached materially higher performance, confirming that identifying the right schema context is itself a significant bottleneck. 1

The same study found that performance falls as the number of available columns grows. Different selection mechanisms work better in different width regimes, and hard pruning can perform worse because a necessary column omitted from context cannot subsequently be recovered. 1

This leads to a fairly robust conclusion:

Table names, columns, relevant values and schema links matter; relevance management matters at least as much as metadata volume. The available evidence favors selective contextualization over dumping a catalog into the model context. 1

Evidence by metadata type is less complete than the marketing language implies:

Metadata	Evidence assessment
Table/column names	Directly important; schema grounding is foundational to text-to-SQL. Wider and ambiguous schemas degrade performance. 1
Column/table descriptions	Mixed/conditional. Relevant descriptions can help; exhaustive descriptions can hurt through context overload. 1
Database values / examples	Directly supported. Query-specific content improved SQL-PaLM; BIRD explicitly includes value grounding as part of the difficulty. 1
Schema linking	Strongly supported as an intermediate reasoning problem; DIN-SQL explicitly decomposes schema linking before generation, and Dr.Spider shows brittleness to schema/question perturbations. 13
Types	Routinely supplied in schema representations, but clean controlled isolation of “types versus no types” in frontier LLM enterprise settings is limited.
Primary/foreign keys and relationships	Architecturally sensible and widely represented in text-to-SQL systems; direct modern LLM ablations isolating their incremental enterprise value are much less common than the general schema-linking literature.
Human-authored business descriptions	Conditional evidence via text-to-SQL metadata; no evidence that every description is useful.
Examples / verified queries	Few-shot SQL examples are commonly effective, but this is not equivalent to proving a commercial “verified query repository” as a required platform layer.

Dr.Spider reinforces the brittleness point. It introduced 17 perturbation types over questions, schemas and SQL and found that even the most robust evaluated systems suffered an overall performance drop of about 14 points, with degradation of up to 50.7 points under the hardest perturbation. This shows that superficial changes to schemas and phrasing can materially affect correctness. 14

Semantic-information and semantic-layer evidence

The literature supports semantics as information, but it does not yet support the enterprise semantic layer as a uniquely necessary architecture.

A model clearly benefits when ambiguity is resolved: mappings from natural-language phrases to columns, relevant entity/value information, domain knowledge and examples can all improve results. BIRD, SQL-PaLM, DIN-SQL and CHESS-style systems collectively demonstrate that contextual information beyond bare SQL syntax helps. 12

What is notably missing is the controlled experiment that many industry claims implicitly presuppose:

same model + same enterprise questions + same underlying data, tested against raw schema, raw schema plus documentation, semantic model, governed metric API, and verified-query layer.

I did not find a credible published study performing that comparison across representative enterprise domains. Consequently, evidence for business semantics does not currently let us estimate the incremental causal benefit of a commercial semantic layer over simpler, well-retrieved textual metadata.

The same problem applies to governed metrics. If a question asks for “ARR,” “active customer,” “churn” or “gross margin,” and the organization has a non-obvious definition, the agent logically requires access to that definition somewhere. But research has not established that the definition must reside in a centralized semantic layer rather than documentation, a metric API, SQL exemplars or another machine-retrievable representation. SQL-PaLM’s results in fact warn that representation and context selection can matter as much as the presence of additional information itself. 1

Semantic-layer evidence audit: plausible value, inadequate controlled evidence.

Ontologies and knowledge graphs

Knowledge graphs have real empirical evidence behind them—but mostly for tasks where graph structure is naturally relevant.

Think-on-Graph has an LLM iteratively navigate entities and relations in a knowledge graph and reported state-of-the-art results on six of nine evaluated KG-reasoning datasets; the authors also found cases where smaller LLMs augmented with graph traversal surpassed much larger models. This establishes that explicit graph structure can be a useful reasoning/retrieval substrate. It does not establish necessity. 15

Microsoft’s GraphRAG work likewise showed substantial gains over naive vector-RAG on global sensemaking/query-focused summarization over corpora around one million tokens. The graph is used to create entity/community structure and hierarchical summaries that a simple local semantic retriever cannot easily provide. 16

But both examples contain an important confound: the graph changes retrieval and aggregation, not merely semantic representation. Better results may arise because the graph selects different evidence, supplies precomputed summaries, or provides multi-hop traversal—not simply because facts are “semantically modeled.” Graph-versus-text studies therefore often fail to isolate representation from retrieval strategy. 16

Moreover, successful text-to-SQL, RAG and tool-using systems operate without enterprise knowledge graphs. That directly falsifies a strong necessity claim. KGs are best described as conditionally useful for relationship-heavy, multi-hop or corpus-level tasks, not as a universal prerequisite for reliable agents. 1

Data-quality robustness and quality metadata

Evidence here is surprisingly thin relative to the strength of industry claims.

BIRD deliberately includes dirty and realistic database contents, establishing that real text-to-SQL cannot assume perfectly clean values. Dr.Spider shows large degradation under controlled perturbations. But neither study provides the kind of factorial quality experiment needed to estimate an agent’s sensitivity separately to nulls, wrong values, duplicates, inconsistent categories, delayed updates and schema drift. 12

The literature therefore supports the modest conclusion that LLM analytical systems are not magically robust to bad inputs. It does not yet provide robust enterprise curves such as “a 5% duplicate rate causes X% answer degradation” or “surfacing a freshness SLA reduces stale-answer errors by Y%.”

The related question—whether quality metadata itself changes model behavior—is even less studied. I found no convincing controlled enterprise study comparing, for example:

table only versus table + quality score / validation failures / completeness / freshness SLA / anomaly flags

while holding the data and task fixed.

That is a major evidence gap. Today, assertions that agents “need data quality metadata” are technically plausible, but mostly extrapolated from conventional data governance and from the obvious fact that bad evidence can produce bad conclusions.

Freshness and temporal information

Temporal grounding has substantially better direct evidence.

FreshQA was explicitly designed around fast-changing world knowledge and false-premise questions. Across evaluated models, fast-changing questions were difficult; FreshPrompt improved answers by inserting current search evidence. The authors also found that the quantity and ordering of retrieved evidence affected correctness. This directly supports external grounding when information changes after model training. 17

STALE, introduced in 2026, targets a related agent problem: a newer observation implicitly invalidates an older memory without explicitly saying “the previous fact is wrong.” Its benchmark contains 400 expert-validated conflict scenarios and 1,200 queries across more than 100 topics, documenting that belief revision in persistent agent memory is a nontrivial problem. 18

What the literature does not yet establish is that attaching a last_updated_at field or freshness score is sufficient. Most temporal work compares stale model memory with newer external evidence or evaluates conflicting versions; relatively little cleanly isolates:

• no temporal metadata;

• timestamps only;

• timestamps plus validity intervals;

• trusted source freshness;

• explicit supersession relationships.

Thus, fresh access is supported; a specific freshness-metadata architecture is not. 17

Provenance and citations

Provenance is a mature non-AI construct. W3C PROV explicitly represents derivation, activities, agents, revisions and temporal relationships, with intended uses including reproducibility, source assessment and tracking how outputs were generated. 19

LLM research supports a narrower claim around citation-backed verifiability. ALCE evaluates answer correctness and whether citations actually support generated statements. Even the best systems in the original evaluation lacked complete citation support on roughly 50% of ELI5 answers, demonstrating that citation generation itself remains imperfect. 20

This distinction matters:

Citation/provenance availability ≠ correctness.
Citation/provenance availability ≠ correct use of provenance.
Citation/provenance availability ≠ calibrated human trust.

ALCE measures answer correctness and citation quality and validates its automatic metrics against human judgments; it does not demonstrate that showing citations causes users to detect more AI errors or calibrate trust appropriately. 20

Accordingly, provenance is strongly justified for traceability and reproduction independently of AI, while claims that provenance automatically makes agents more trustworthy are only conditionally supported.

Interfaces and access: curation, tool abstraction, machine-readable documentation and protocols

Curated versus open access

The empirical literature argues against the intuitive idea that an agent should simply see everything.

SQL-PaLM’s schema experiments show the central trade-off particularly clearly. Reducing irrelevant schema can help, but hard selection may hurt when necessary columns are accidentally removed. “Soft” approaches that identify or describe likely-relevant elements while retaining recoverability perform better in several settings. 1

ToolLLM addresses a still larger action space: more than 16,000 real-world APIs. Rather than putting every API directly in context, its architecture includes an API retriever that selects likely-relevant tools for the task. The very architecture of the benchmark/system reflects the practical impossibility of unconstrained all-tool prompting at that scale. 21

At the document level, τ-Knowledge is particularly sobering. Its 2026 banking environment contains roughly 700 interconnected knowledge documents plus tools; even frontier models operating with high reasoning budgets achieved only about 25.5% pass@1, with failures involving retrieval of the right policies and reasoning across them. This is closer to the enterprise problem of “there is lots of relevant organizational knowledge somewhere” than classic single-document RAG. 22

The conclusion is therefore conditional rather than simplistic:

Curating/retrieving a task-relevant subset usually addresses a genuine model limitation, but premature filtering creates its own failure mode.

The desirable property is not “closed access” but high recall with controlled distraction.

Scale effects

Four strands of evidence converge on scale sensitivity.

First, SQL-PaLM explicitly reports lower text-to-SQL performance as available column counts increase. 1

Second, Spider 2.0’s roughly 812-column average schemas and frequently thousand-plus-column environments are dramatically harder than classic benchmark schemas. 3

Third, ToolLLM resorts to retrieval in a 16,464-API environment rather than treating every tool as an equally visible candidate. 21

Fourth, τ-Knowledge shows that a few hundred interdependent policy/knowledge documents can remain extremely difficult even for 2026 frontier systems. 22

What is not known is a stable scaling law. There is no generally established function mapping “number of tables/tools/metrics/documents” to task failure across model families. Relevant-context density, naming quality, retrieval, model generation and task complexity interact strongly.

So the evidence supports degradation with larger search spaces, not a universal threshold such as “agents can handle N tables.”

Tool abstraction

Tool-use research clearly establishes that models can interact with typed APIs and that tool selection is itself difficult.

τ-bench gives agents domain-specific APIs and business-policy instructions while requiring multi-turn interaction with a simulated user. Even GPT-4o succeeded on fewer than half of tasks in the original evaluation, and repeated-trial reliability was much worse; retail pass^8 fell below 25%. Structured APIs therefore do not eliminate reasoning, policy-following or execution failures. 23

ToolSandbox adds stateful environments, implicit dependencies and conversational interaction and finds persistent difficulties when correct actions depend on changing state, canonicalization or obtaining missing information. 24

What is much less established is the specific claim that high-level domain tools outperform low-level generic data tools in a controlled enterprise-data experiment. Few studies hold the underlying capability fixed while comparing something like:

execute_sql(sql)
versus
get_net_revenue(period, region).

The engineering argument for higher-level tools is compelling—smaller parameter spaces and embedded domain logic—but the comparative empirical literature is still thin. This should be classified as plausible but inadequately tested, not established fact.

Machine-readable documentation

The best recent evidence concerns tool descriptions, not data catalogs.

A 2026 empirical study examined 856 tools across 103 MCP servers. It found that 97.1% of descriptions contained at least one identified “smell,” and 56% failed to clearly state purpose. Augmenting descriptions increased median task success by 5.85 percentage points and partial goal completion by 15.12%. But it also increased execution steps by 67.46% and made performance worse in 16.67% of cases. 25

This is valuable because it experimentally demonstrates that interface metadata is behaviorally consequential. It also reinforces the “more context is not automatically better” finding from SQL-PaLM. 25

However, note what the experiment does not prove. MCP tool descriptions are still primarily natural-language descriptions attached to structured tool schemas. The study does not establish that JSON/typed documentation universally outperforms equally complete prose, nor that human-readable catalog descriptions must be redesigned into some specific new machine-oriented format. 25

The data-specific evidence for structured documentation versus prose containing the same facts remains sparse.

Agent protocols

MCP is a protocol/interoperability specification. Official documentation describes it as an open-source standard for connecting AI applications to external data sources, tools and workflows—the analogy used is a “USB-C port” for AI applications. 11

That establishes interface standardization. It does not establish:

• semantic consistency between connected sources;

• correct metric definitions;

• data quality;

• source freshness;

• safe authorization;

• correct tool selection;

• resilience to prompt injection;

• reliable multi-step execution.

Indeed, the MCP tool-description study demonstrates that two MCP-compliant tools can differ enough in documentation quality to cause measurable differences in agent behavior. 25

Therefore:

“MCP-compatible” is evidence of connectability, not evidence of agent readiness.

The protocol may be commercially and operationally important without being a scientifically validated data-readiness criterion.

Governance and security: authorization, injection, lineage, contracts, data products and policies

Authorization and confused authority

Here the evidence becomes much more specifically agentic.

Traditional analytics mostly expose information to a human or application. An agent can additionally decide which tool to invoke and cause side effects. That turns failures of instruction interpretation into authorization failures.

AgentDojo was created specifically around this problem: agents use tools over untrusted data, and data returned by tools may contain instructions intended to hijack the agent into executing attacker goals. The benchmark confirms both substantial baseline task difficulty and prompt-injection vulnerability. 2

InjecAgent contains 1,054 test cases, 17 user tools, 62 attacker tools and evaluations across 30 agent configurations. The study reports a roughly 24% vulnerability rate for a ReAct GPT-4 agent under its attacks, while stronger malicious prompting can substantially increase attack success. 26

This is direct evidence that a system which merely gives an LLM authenticated access to tools does not thereby inherit safe authorization behavior.

The resulting platform requirement is more defensible than most “AI-ready data” claims: effective authorization must be enforced outside the model’s discretionary natural-language reasoning whenever the consequences matter. That inference is supported by the repeated empirical failure of models to reliably distinguish legitimate user instructions from hostile instructions embedded in retrieved data. 2

Prompt injection through data and metadata

The distinction between data and instructions is fundamentally unstable inside a plain language-model context. To the model, both arrive as tokens. AgentDojo directly demonstrates attacks embedded in external tool-returned data. 2

This is qualitatively different from ordinary bad data. A wrong revenue figure may produce a wrong analytical answer; an injected instruction inside a retrieved email, webpage, row or tool result may cause the agent to change what task it thinks it is executing.

Recent adaptive red-teaming indicates that the issue remains active even as model generations improve. PIMiner’s 2026 evaluations report high indirect-prompt-injection success against several frontier agent setups under adaptive attack, including attack-success rates above 50% for some GPT and Gemini configurations on evaluated benchmarks. As a fresh preprint, those exact rates should not be generalized beyond its threat model, but they argue strongly against declaring the problem solved. 27

Mitigation evidence favors architectural enforcement over instruction-only defenses. CaMeL separates control and data flow and uses capabilities/policies to prevent untrusted content from controlling sensitive actions; its evaluation reports completion of about 67% of AgentDojo tasks while providing its stronger security guarantees. 28

NetInjectBench provides another domain-specific example. In a network-operations benchmark, naive agents took unsafe actions in 82.5% of attack trials; prompt-oriented defenses still had double-digit unsafe-action rates, whereas a metadata-aware policy gate reported 0 unsafe actions in 240 attacks, subject to the key assumption that the policy metadata itself remains trustworthy. 29

That last qualification is central: machine-readable governance becomes valuable only when its integrity and enforcement boundary are stronger than the model’s susceptibility to untrusted content.

Lineage evidence

This review found a striking mismatch between industry rhetoric and direct evaluation.

Lineage/provenance clearly has conventional value for debugging, reproducibility, dependency analysis and tracing derivations; W3C PROV formalizes many of those relationships. 30

What is missing is a controlled AI-agent study demonstrating that giving an agent enterprise data lineage improves, for example:

• correct source selection;

• downstream impact analysis;

• root-cause diagnosis;

• interpretation of transformed metrics;

• debugging of wrong analytical results.

Security systems such as CaMeL sometimes track information flow or provenance-like labels, but security taint/provenance is not the same thing as warehouse lineage across tables, models and pipelines. 28

Therefore, “lineage is essential for AI reasoning” is currently unsupported as an empirical generalization. It is a reasonable research hypothesis and may be particularly useful for debugging and source selection, but the required controlled experiments have largely not been done.

Data contracts

The evidence is even weaker for data contracts.

I found no material controlled study in which otherwise identical AI agents were run against:

• data with machine-enforced contracts;

• documented but unenforced expectations;

• no contracts;

under controlled schema drift, nullability changes, unit changes or semantic changes.

Contracts may obviously prevent broken data from reaching any consumer. That is ordinary software/data reliability. It does not establish an AI-specific requirement.

Accordingly, “data contracts are prerequisites for agentic AI” is unsupported by direct evidence. A more defensible claim would be: machine-enforced contracts can prevent classes of upstream failures before they reach an AI consumer, a proposition that still needs AI-specific quantification.

Data products

The same distinction applies to data products. Recent industry and ecosystem publications explicitly advocate “AI-ready data products,” combining quality, semantics and accessibility as a design paradigm. 7

But I found no credible controlled study evaluating agents as consumers of formally managed data products versus otherwise equivalent datasets or APIs.

Thus:

Data-product principles may transfer well to AI because discoverability, ownership, documentation and quality are valuable to many consumers. But the AI-specific benefit is presently extrapolation, not demonstrated causal evidence.

Claims that every data product must now become “agent-ready” go beyond the literature.

Human-readable versus machine-readable governance

There is meaningful evidence that simply handing agents the same policies humans read is not enough.

τ-bench supplies domain policies together with structured tools, yet frontier systems still fail a large fraction of end-to-end tasks. 23

τ-Knowledge goes further with hundreds of interdependent banking documents and reports only about 25.5% pass@1 for strong models under its more difficult knowledge-intensive setting. 22

In contrast, domain-specific experiments such as NetInjectBench show that an externally enforced policy gate can dramatically outperform merely reminding a model to behave safely, although such results depend on trusted policy metadata and do not automatically transfer to arbitrary enterprise systems. 29

The evidence therefore supports machine enforcement of critical governance rules more strongly than it supports wholesale “machine-oriented redesign” of catalogs, glossaries or documentation.

Benchmark validity, scale and contradictory evidence

Benchmark map

Benchmark / study family	What it tests	Enterprise relevance	Major blind spots
Spider	Cross-domain text-to-SQL	Foundational schema grounding	Small, clean schemas; static; no enterprise permissions/governance.
BIRD	Large DB text-to-SQL with values and external knowledge	Better data-size/content realism; 95 DBs, 37 domains, 33.4 GB. 12	Still benchmark-style, mostly static analytical queries; limited organizational semantics/permissions.
Spider 2.0	Enterprise-style SQL/data workflows	Strongest public match in this set: hundreds of tasks, large schemas, multiple industrial DB systems. 3	No full real-enterprise organizational environment; limited live permission, ownership and temporal change.
Dr.Spider	Robustness to schema/question/SQL perturbations	Strong evidence against brittle schema assumptions. 14	Perturbations are designed experiments, not production-quality incidents.
FreshQA	Current knowledge, changing facts, false premises	Strong temporal-grounding evidence. 17	Web factual QA rather than warehouse freshness or table versions.
STALE	Detecting newer information that invalidates agent memory	Relevant to supersession and persistent agent context. 31	Personal/everyday memory scenarios, not enterprise temporal data governance.
ALCE	Correctness and support of generated citations	Relevant to provenance/verifiability. 20	Not structured-data provenance; not a user trust-calibration experiment.
ToG/KGQA	Multi-hop reasoning over explicit KGs	Tests whether graph traversal can aid reasoning. 8	Public/static KGs; graph and retrieval effects often confounded.
GraphRAG evaluations	Global synthesis over large text collections	Relevant where cross-document relationships matter. 16	Not relational analytics; graph construction itself uses LLMs and introduces cost/error.
ToolBench/ToolLLM	API retrieval and invocation across 16k+ APIs	Strong tool-search-scale evidence. 21	Many instructions/tasks generated synthetically; not enterprise data governance.
ToolSandbox	Stateful conversational tool use	Better approximation of dynamic applications. 24	Still sandboxed and narrow relative to enterprise systems.
τ-bench	Stateful tools + user interaction + policy constraints	Particularly relevant to business agents. 23	Few domains and simulated users/environments.
τ-Knowledge	Hundreds of connected enterprise-style knowledge documents + tools	Good evidence on document/policy scale. 22	Banking benchmark, not heterogeneous live corporate infrastructure.
AgentDojo	Indirect prompt injection through tool-returned data	Highly relevant to agent security. 2	Synthetic/sandboxed attack environment.
InjecAgent	Large-scale indirect prompt-injection cases	Strong attack-surface evidence. 26	Constructed attack scenarios; model results age quickly.

The major shared limitation is that even the better benchmarks rarely combine large schemas + messy data + live temporal change + conflicting documentation + row/column permissions + multiple identity domains + side-effecting actions + malicious content + organization-specific metrics in one environment.

That is the environment implied by much “agent-ready enterprise data” rhetoric, and it remains largely unbenchmarked.

Contradictory evidence

Several apparent disagreements in the literature disappear once the intervention is examined carefully.

More metadata helps / more metadata hurts. SQL-PaLM finds both. Relevant database content gives a substantial improvement, while full column descriptions reduce accuracy. Soft schema highlighting can help slightly; hard filtering can hurt badly when recall is lost. The contradiction is explained by a trade-off among relevance, context length and schema recall—not by metadata being inherently good or bad. 1

More retrieved evidence helps / more context distracts. FreshPrompt finds the number and order of current search evidences affect answer correctness; SQL-PaLM and large-schema results show that indiscriminate context can degrade reasoning. These are compatible: marginal evidence is useful only while its information value exceeds its distraction/context cost. 17

Knowledge graphs improve reasoning / KGs are unnecessary. ToG and GraphRAG show real gains on graph-suited and global-synthesis tasks. Text-to-SQL and ordinary tool agents demonstrate successful reasoning without KGs. The correct conclusion is task-conditional usefulness, not architectural necessity. 32

Richer tool descriptions help / richer descriptions increase cost and sometimes hurt. The MCP-description study observes a median +5.85-point success gain, but 67.46% more execution steps and regressions in 16.67% of cases. This is unusually direct evidence that metadata quality and metadata quantity should not be conflated. 25

Prompt defenses help / prompt injection remains severe. Some defenses reduce attack success under fixed attacks, but adaptive red-team studies continue to recover high success rates. More structural approaches—capabilities, policy gates, trusted execution boundaries—show stronger results under their evaluated assumptions. Differences in adversary adaptiveness and enforcement model explain much of the apparent conflict. 28

Evidence-quality interpretation

The field is dominated by benchmarks rather than deployment experiments. That matters.

A result on 100 clean benchmark databases is not a production study of a data mesh. A result using synthetic tool descriptions is not proof of enterprise catalog redesign. A KGQA gain over Freebase does not demonstrate that an ontology program will pay for itself in a Fortune 500 warehouse. A prompt-injection benchmark does, however, demonstrate a mechanism that production systems must address, because the attack relies on a fundamental property of language-model context rather than a particular vendor stack. 12

Enterprise transferability is highest when a paper isolates a causal mechanism that clearly survives environmental changes—schema overload, stale knowledge, prompt injection, tool-description ambiguity—and lowest when the “intervention” bundles an entire architecture whose components are not independently ablated.

Industry claim audit and what current evidence does not support

Claim audit

Industry claim	Classification	Evidence judgment
“AI requires a semantic layer.”	Contradicted as a universal necessity; conditional benefit is plausible.	Models can and do operate directly over database schemas and values. Semantics/context improve many tasks, but no controlled literature establishes a commercial semantic layer as a necessary condition. 1
“Metadata is the new interface for agents.”	Conditionally supported.	Schema context and tool descriptions measurably affect performance, but excessive metadata can reduce it. Metadata is an important model-facing interface, not a guarantee of reliability. 1
“Every data product must become agent-ready.”	Unsupported.	“AI-ready data products” are being advocated as a new paradigm, but direct agent-consumer evaluations were not found. 7
“Data contracts are prerequisites for agentic AI.”	Unsupported.	No controlled AI evidence establishes contracts as a prerequisite. Benefits are extrapolated from general interface/data reliability.
“Knowledge graphs are necessary for reliable agents.”	Contradicted as a necessity.	KGs improve some multi-hop/global tasks, but many successful agent and text-to-SQL systems work without them. 32
“Agents need governed metrics.”	Plausible but inadequately tested.	Agents need correct metric definitions when questions depend on organization-specific semantics, but no controlled evidence establishes a governed metric layer as the required representation.
“MCP makes data platforms agent-ready.”	Unsupported as a broad readiness claim.	MCP standardizes connections. It does not provide data quality or semantic correctness, and MCP tool-description quality itself materially affects success. 11
“Lineage is essential for AI reasoning.”	Unsupported.	Lineage has clear non-AI value, but direct agent-consumption studies demonstrating reasoning improvements are missing. W3C provenance capabilities should not be mistaken for LLM evaluation evidence. 30
“AI will force companies to modernize data platforms.”	Unsupported as a technical necessity.	Current studies expose scaling, metadata and security problems; they do not demonstrate that a particular modernization program is causally necessary.
“Companies with modern data stacks are automatically better positioned for agents.”	Unsupported.	No benchmark maps “modern stack maturity” to agent task success. Poor tool descriptions and unsafe authority boundaries can exist on modern infrastructure just as easily as legacy infrastructure. 25
“AI-ready data requires a fundamentally new architecture.”	Unsupported.	Most demonstrated requirements—accurate schema, relevant metadata, fresh information, source traceability, authorization and validation—have pre-AI antecedents. The genuinely new pressure is chiefly around model context selection and the security consequences of agents interpreting data while wielding actions. 33

The most defensible statement is therefore weaker but more useful:

Agents raise the value of some existing data-management properties and introduce new interface/security failure modes. They do not, on current evidence, imply a universally new data architecture.

What current evidence does support

A conservative evidence hierarchy looks like this:

Proposition	Evidence strength
LLM analytical accuracy depends on receiving the relevant schema/context.	Strong. 1
Wider schemas and larger choice spaces can degrade reliability.	Strong. 1
Relevant DB values/examples can improve query generation.	Strong. 1
More metadata is not monotonically better.	Strong. 1
Tool-description quality affects selection/execution behavior.	Directly supported. 25
Retrieving fresh external information improves changing-world questions.	Strong for factual QA. 17
Agents can fail to supersede stale memory correctly.	Direct benchmark evidence. 31
Knowledge graphs can improve graph-heavy/multi-hop/global retrieval tasks.	Direct, task-conditional evidence. 32
Citations enable inspectable evidence but are themselves often incomplete.	Strong. 20
Data returned from external systems can prompt-inject tool-using agents.	Very strong empirical security evidence. 2
Critical authorization/policy enforcement should not depend solely on model obedience.	Strong inference from security evaluations; supported by enforcement-based mitigations. 28

What current evidence does not support

Current evidence does not justify treating any of the following as established scientific findings:

“Every AI system requires a semantic layer”; “ontology is inherently superior to textual metadata”; “lineage materially improves generic agent reasoning”; “data contracts are a prerequisite”; “quality scores cause agents to abstain appropriately”; “MCP provides reliability”; “a modern data stack predicts agent success”; “data products designed for humans automatically become better AI inputs”; or “AI requires replacing the current enterprise data architecture.”

Those ideas range from sensible engineering hypotheses to aggressive commercial positioning, but the causal evidence needed to distinguish them is mostly absent.

A particularly important absence is the semantic representation comparison. There is abundant work comparing systems, but very little work holding factual information constant while encoding it alternately as:

DDL + prose
semantic-model entities/metrics
ontology/KG triples
high-level metric API

and then measuring correctness across the same tasks and models.

Without that experiment, claims about the superiority of a representation often confound what information was available, how it was retrieved, how much context was supplied, and what reasoning scaffold surrounded the model.

Material study table

The table below prioritizes studies that materially constrain the answer rather than trying to catalogue every text-to-SQL, RAG or agent paper.

Core structured-data and semantic studies

Study	Publication status / date / direct URL	Model / system	Task and data environment	Intervention / context	Baseline / comparator	N / metric / result	Limitations and enterprise transferability
Li et al., BIRD	NeurIPS 2023; arXiv 2023. https://arxiv.org/abs/2305.03111	ChatGPT and contemporary text-to-SQL baselines	Large database-grounded text-to-SQL; 95 DBs, 37 domains, 33.4 GB	Schemas, DB content, external knowledge	Existing text-to-SQL systems; human performance	12,751 pairs; execution accuracy; ChatGPT 40.08%, human 92.96%	Much more realistic than Spider but static benchmark; no enterprise authorization/organizational governance. 12
Sun et al., SQL-PaLM	arXiv 2023–24. https://arxiv.org/abs/2306.00739	PaLM-2 Unicorn / SQL-PaLM	Spider and BIRD text-to-SQL	DB values, schema filtering, column descriptions, execution feedback	Same model without each intervention	BIRD ablations: query-specific content 55.15→58.80 EX; full descriptions 58.80→54.69; oracle schema selection substantially higher	Excellent causal ablations; model generation now old; still not enterprise business semantics. 1
Pourreza et al., DIN-SQL	NeurIPS 2023; https://arxiv.org/abs/2304.11015	GPT-family prompting pipeline	Complex text-to-SQL	Explicit schema linking, decomposition, generation, self-correction	Less decomposed prompting	Improved benchmark execution accuracy	Pipeline evidence for schema linking, but components interact and do not isolate metadata types. 13
Chang et al., Dr.Spider	ICLR 2023; https://arxiv.org/abs/2301.08881	Multiple text-to-SQL models	Robustness under question/schema/SQL perturbation	17 perturbation types	Original unperturbed examples	Best systems still ≈14-point aggregate drop; up to 50.7 points on hardest perturbation	Strong brittleness evidence; perturbations do not model full production data corruption. 14
Lei et al., Spider 2.0	arXiv 2024; https://arxiv.org/abs/2411.07763	Code/LLM agents incl. frontier models	Enterprise-style SQL/data workflows on BigQuery, Snowflake, etc.	Large schemas plus metadata/docs/code context	Modern text-to-SQL/agent frameworks	632 tasks; avg ≈812 columns; early success roughly 17–21% depending setup/track	Best public enterprise approximation, but still curated/static and lacks full organizational permissions/change. 3
Sun et al., Think-on-Graph	ICLR 2024; https://arxiv.org/abs/2307.07697	LLM + iterative KG beam search	KG question answering/reasoning	Explicit entities/relations and path traversal	LLM-only and prior KGQA systems	State of art on 6/9 evaluated datasets; smaller augmented models beat GPT-4 in some settings	Supports KG usefulness, not necessity; static public KGs unlike enterprise data landscapes. 15
Edge et al., GraphRAG	arXiv 2024; https://arxiv.org/abs/2404.16130	GraphRAG pipeline	Global question-focused summarization over ≈1M-token corpora	LLM-created entity graph, communities and summaries	Naive vector RAG	Substantial gains in comprehensiveness/diversity on global questions	Graph representation, retrieval and pre-summarization are confounded; not structured enterprise analytics. 16
Vu et al., FreshLLMs / FreshQA	Findings of ACL 2024; https://arxiv.org/abs/2310.03214	Multiple LLMs + FreshPrompt	Fast-changing factual QA and false-premise QA	Current search evidence	Model memory, Self-Ask and search-augmented baselines	>50k human judgments; current evidence materially improves FreshQA; evidence number/order matters	Strong freshness evidence, but web facts rather than database freshness fields. 17
Chao et al., STALE	arXiv preprint, 2026. https://arxiv.org/abs/2605.06527	LLM agents with persistent memory	Detection of implicit supersession/conflict	New observations against old memory	Static-memory behavior	400 conflict scenarios, 1,200 queries, >100 topics; models struggle with implicit invalidation	Important temporal-agent result; does not directly evaluate data-warehouse timestamps or freshness SLAs. 18
Gao et al., ALCE	EMNLP 2023; DOI 10.18653/v1/2023.emnlp-main.398; https://aclanthology.org/2023.emnlp-main.398/	Retrieval + LLM generation	Long-form QA with citations	Retrieved source evidence and inline citations	Multiple retrieval/generation approaches	ASQA/QAMPARI/ELI5; even best system lacks complete citation support ~50% on ELI5	Excellent citation-quality benchmark; does not test enterprise lineage or human trust calibration. 20

Tool, governance and security studies

Study	Publication status / date / direct URL	Model / system	Task and environment	Intervention / context	Baseline / comparator	N / metric / result	Limitations and enterprise transferability
Qin et al., ToolLLM / ToolBench	ICLR-era 2024 work; https://arxiv.org/abs/2307.16789	ToolLLaMA + API retriever	Tool selection/invocation	Retrieval over real RapidAPI descriptions	General-purpose LLM/tool baselines	16,464 APIs across 49 categories; demonstrates scalable API retrieval/use	Many instructions synthetic; API ecosystem ≠ enterprise data estate. 21
Yao et al., τ-bench	arXiv 2024; https://arxiv.org/abs/2406.12045	GPT-4o and other agents	Stateful retail/airline tool-agent-user tasks with policies	Structured domain APIs + written policy rules	Multiple agent/model configurations	GPT-4o <50% original task success; retail pass^8 <25%	Strong end-to-end reliability evidence; few domains and simulated users. 23
ToolSandbox	Findings NAACL 2025; https://arxiv.org/abs/2408.04682	Multiple tool-using LLMs	Stateful conversational execution	Dynamic state, dependencies, simulated user	Existing tool-use agents	Models remain challenged by state dependencies and insufficient-information cases	Better interaction realism, but small compared with enterprise tool ecosystems. 24
Hasan et al., MCP Tool Descriptions Are Smelly	arXiv preprint, revised May 2026; DOI 10.48550/arXiv.2602.14878; https://arxiv.org/abs/2602.14878	FM agents over MCP tools	Tool understanding/selection/execution	Augmented tool descriptions	Original descriptions	856 tools / 103 servers; median +5.85 pp task success, +15.12% partial completion; +67.46% steps; regression in 16.67% cases	Excellent real-ecosystem metadata study, but not relational-data semantics; preprint. 25
Debenedetti et al., AgentDojo	NeurIPS 2024 Datasets & Benchmarks; https://arxiv.org/abs/2406.13352	Tool-using LLM agents	Legitimate tasks under indirect prompt injection	Adversarial instructions embedded in untrusted tool data	Benign environment / attack and defense variants	Demonstrates significant utility and security failures	Sandbox rather than live enterprise; nevertheless directly models the key data-as-instruction vulnerability. 2
Zhan et al., InjecAgent	arXiv 2024; https://arxiv.org/abs/2403.02691	30 LLM-agent configurations	Indirect prompt injection through external tool/content channels	Adversarial retrieved content	Benign agent runs	1,054 cases, 17 user tools, 62 attacker tools; ReAct GPT-4 ≈24% vulnerable under reported setup	Attack construction and older models limit exact current rates; mechanism transfers strongly. 26
Debenedetti et al., CaMeL / Defeating Prompt Injections by Design	IEEE SaTML 2026; https://arxiv.org/abs/2503.18813	Capability/data-flow constrained agent system	Prompt-injection-safe tool use	Trusted control/data separation and capability policies	Standard LLM-agent execution	≈67% AgentDojo utility while providing its stronger security guarantees	Utility cost and integration complexity; assumes trusted enforcement layer. 28
NetInjectBench	arXiv preprint 2026; https://arxiv.org/abs/2607.10490	Qwen/Llama/Mistral network agents	Network-configuration attacks and authorized changes	Prompt defenses vs metadata-aware policy gate	Naive agent	240 attacks; naive unsafe 82.5%; policy gate 0/240 under trusted-metadata assumption	Narrow domain/small models; unusually clean evidence for external policy enforcement. 29

The publication-status distinction matters. BIRD, Dr.Spider, DIN-SQL, ToG, ALCE, AgentDojo and CaMeL have stronger publication vetting than the newest 2026 preprints. The 2026 work is useful for mapping the frontier but should not be treated as settled consensus merely because its numbers are recent.

Research gaps and research frontier

Most important research gaps

Enterprise semantic-layer trial.
A serious evaluation should select several real company schemas and freeze the model and questions while varying only the representation:

raw DDL → DDL + descriptions → retrieved catalog metadata → semantic entities/metrics → governed metric API → verified-query examples.

It should measure execution correctness, business-semantic correctness, source selection, abstention, token cost and latency. Without this trial, “semantic layer for AI” remains mostly architecture-led reasoning.

Business-semantic benchmark.
Current text-to-SQL benchmarks usually have one canonical interpretation. Real businesses often have several technically valid queries but one organizationally correct definition. A useful benchmark would include conflicting plausible definitions of customer, revenue, churn, headcount and attribution, along with effective dates and domain ownership. The central metric should be whether the model chooses the governed meaning, not merely executable SQL.

Quality-degradation experiment.
Take clean enterprise-style datasets and independently vary missingness, wrong values, duplicate rates, inconsistent identifiers, delayed partitions and schema drift. Compare no quality information against machine-readable quality metadata and enforced validation. Measure wrong-answer rate, anomaly detection, abstention and confidence calibration. This would directly answer whether agents benefit from surfaced quality indicators instead of merely inheriting ordinary garbage-in/garbage-out behavior.

Freshness-metadata trial.
Create parallel historical/current table versions and documents with contradictory values. Compare no timestamps, timestamps, validity windows, explicit supersession links and freshness/SLA metadata. Measure whether agents choose the correct current source. FreshQA and STALE establish the problem but not the optimal data representation. 17

Lineage-consumption benchmark.
Build realistic multi-hop transformation DAGs with duplicated sources, intermediate models, metric transformations and injected upstream errors. Test impact analysis, source selection and root-cause diagnosis with no lineage, textual lineage descriptions and graph-structured lineage. Until that exists, “agents need lineage” remains speculative.

Data-contract experiment.
Inject schema drift, unit changes, nullability changes and renamed fields. Compare: no contract, prose documentation, visible machine contract, and contract enforcement before agent access. This would separate “a contract helps the agent reason” from the much simpler “a contract prevents broken data from entering the system.”

Graph-versus-text semantics experiment.
Encode identical facts as prose, relational metadata, triples/ontology and a graph API, with equivalent retrieval recall. Current KG and GraphRAG work often improves the retrieval mechanism together with the representation, making the incremental causal value of graph semantics difficult to estimate. 32

Controlled tool-abstraction experiment.
Provide exactly the same underlying capabilities through low-level SQL/CRUD tools and high-level domain functions. Vary number of tools and overlapping scopes. Measure tool-selection accuracy, parameter errors, policy violations and end-to-end success. This would test the common claim that agent-facing platforms need higher-level domain APIs.

Scale curves rather than single benchmarks.
Systematically scale tables, columns, metrics, tools, documents and domains while keeping task difficulty fixed. SQL-PaLM and Spider 2.0 establish degradation, but the field lacks reusable scaling curves across model generations. 1

Authorization benchmark with real permission structure.
Enterprise evaluations should include user identity, role changes, row-level security, column-level restrictions, delegated authority, cross-system scopes, read-versus-write privileges and indirect prompt injection. Current security benchmarks demonstrate the vulnerability very convincingly, but not the full complexity of enterprise IAM. 2

Human trust-calibration study for provenance.
Independently manipulate answer correctness, citation correctness and citation presence, then measure whether users detect errors and calibrate reliance. ALCE establishes that citations can be objectively evaluated, but not whether they improve human decision quality. 20

Longitudinal production studies.
The field badly needs real before/after deployment data: agent incident rates, semantic errors, permission violations and successful task completion before and after metadata/semantic/governance changes. Architecture case studies without a counterfactual cannot establish which layer caused the improvement.

Research frontier

The frontier is uneven.

Independent evidence is moving relatively fast in four areas: large-schema grounding, retrieval/context selection, tool-interface quality, and prompt-injection/authorization security. SQL-PaLM, Spider 2.0, τ-bench, AgentDojo and the MCP-description study all expose measurable failure mechanisms and provide at least some controlled comparisons. 1

Practitioner architecture is moving substantially faster than independent evidence around enterprise semantic layers for agents, “context layers,” AI-ready data products, governed-metric APIs as an AI prerequisite, agent use of lineage, agent-oriented data contracts, and wholesale machine-oriented redesign of catalogs. Vendor definitions of AI-ready and agent-ready data are already broad and prescriptive, while the research literature generally evaluates the individual mechanisms rather than those architecture bundles. 4

MCP is another case where adoption is ahead of causal evidence. MCP provides a useful common connectivity protocol, but the empirical work so far is already showing that the quality of the descriptions carried through that interface can materially change agent behavior. Protocol standardization therefore removes integration friction without eliminating the underlying intelligence, semantic or security problems. 11

The deeper pattern is that most experimentally demonstrated requirements do not demand a wholly new kind of enterprise data architecture. They demand that existing information be made selectively retrievable, unambiguous enough for the task, temporally grounded, and enforceably governed, while recognizing that language models can confuse irrelevant context, stale evidence and hostile instructions with useful context. 1

The one important architectural discontinuity is agency. When a model only answers a question, bad data mainly threatens correctness. When a model can call tools, modify systems, send information or spend authority, untrusted data can alter the model’s control decisions. That turns the traditional “data quality” problem into a control-plane security problem, for which external authorization, capability boundaries and trusted policy enforcement have substantially stronger empirical justification than simply adding another metadata or semantic layer. 2

The current evidence therefore supports a narrower—and less commercially convenient—definition of what makes data usable by agents:

Agents benefit from accurate and task-relevant schemas, values and semantics; they need mechanisms to retrieve rather than indiscriminately ingest large environments; they need access to current information when facts change; tool interfaces and their descriptions materially affect performance; and action-taking agents require security boundaries that prevent untrusted data from becoming authority.

It does not follow from the evidence that organizations require a semantic layer, knowledge graph, data contracts, lineage system, data-product operating model, MCP, or fundamentally new stack as universal prerequisites. Those components may be good engineering choices in particular environments. As of October 3, 2026, treating them as empirically established constituents of “agent-ready data” would run ahead of the research.

Agent-Ready Data Platforms: Practitioner Evidence Dossier

Research snapshot: October 3, 2026
Operational question: How should a data platform expose data, business meaning, quality, freshness, permissions, and tools so that AI assistants and agents can use company data reliably without depending on undocumented human knowledge?

Executive recommendation and evidence boundary

The central conclusion is straightforward:

An agent-ready data platform is not a warehouse with an LLM attached. It is a governed context-and-action plane in which meaning, grain, state, authority, and allowed operations are machine-readable and enforceable.

The most reliable architecture separates five concerns:

• Meaning: entities, grain, relationships, dimensions, governed metrics, glossary terms, and metric versions.

• State: freshness, data-quality status, incidents, schema/contract compatibility, and lineage state.

• Authority: user/workload identity, row/column controls, data sensitivity, and allowed actions.

• Discovery: an authorization-aware catalog and semantic retrieval layer that returns a small, task-relevant subset of the estate rather than dumping the catalog into model context.

• Execution: narrow, typed tools—metric retrieval, catalog search, schema lookup, lineage, freshness, quality, validated query execution—with policy enforcement outside model reasoning.

There is strong empirical evidence that real enterprise text-to-SQL remains difficult precisely because schema discovery and grounding are hard at enterprise scale. LinkedIn’s production-oriented system builds a knowledge graph from database metadata, query history, wikis, and code, clusters data by team/product area, then retrieves and ranks context before SQL generation; its internal chatbot had more than 300 weekly users, but expert review still judged only 53% of responses correct or close to correct. 1 LinkAlign identifies database retrieval and schema-item grounding as major bottlenecks in large multi-database settings and reached 33.09% on Spider 2.0-Lite at publication time despite specifically optimizing schema linking. 2 KaSLA independently finds that both missing relevant schema and including excessive irrelevant schema hurt downstream SQL generation. 3

That evidence argues against two common approaches:

• “Give the model the whole catalog.” Large irrelevant contexts create both cost and grounding problems; selective retrieval performs better operationally. 4

• “Give the model SQL access and let it reason.” SQL does not encode business meaning, freshness acceptability, metric governance, authorization intent, or whether a technically valid join is semantically valid. Current semantic-layer systems therefore expose entities, relationships, dimensions, measures, metrics, synonyms, and related metadata explicitly rather than expecting consumers to reconstruct them from physical schemas. 5

What appears to materially matter

The evidence is uneven, and that distinction matters.

Context element	Operational value to an agent	Evidence assessment
Relevant database/table/column subset	Prevents grounding against irrelevant schema and reduces context load.	Strong empirical. Schema-linking work directly measures this effect. 2
Metadata + historical queries + docs/code	Improves enterprise discovery where physical names alone do not carry business meaning.	Production evidence. LinkedIn uses the combination in an internal deployed system. 1
Entity keys and relationships	Gives a machine enough structure to select joins and reason about entity connectivity.	Strong structural evidence; moderate direct agent evidence. dbt and Snowflake encode these as semantic primitives. 6
Grain	Prevents logically valid but analytically wrong aggregation/fanout.	Very strong engineering rationale; surprisingly little isolated agent benchmark evidence. dbt’s own semantic-model example explicitly declares “one row per transaction,” while entity type affects join semantics. 5
Governed metric definition + dimensions + aggregation rules	Prevents agents from independently reimplementing recognized business metrics.	Strong semantic-system evidence; limited independent head-to-head agent evaluation. 5
Synonyms/business terminology	Bridges organization language to semantic objects.	Strong product-design evidence; weak isolated causal benchmarking. Snowflake semantic views support synonyms on semantic objects. 7
Freshness / quality state	Changes whether an answer should be trusted or produced at all.	Strong operational evidence, not primarily a model-performance intervention. dbt exposes freshness thresholds programmatically; Snowflake exposes machine-readable quality-monitoring results. 8
Owner / support route	Enables escalation rather than hallucinated remediation.	Standard/operational evidence. ODCS includes team, roles, support and SLA concepts. 9
Sensitivity / allowed actions	Limits damage when model reasoning fails.	Strong security evidence. MCP requires server-side access control/input validation and recommends client-side confirmation, result validation and auditing. 10

The practical implication is that agent context should not be a big text blob. It should be a small signed/versioned context envelope containing the minimum invariants needed for the current task, plus identifiers for retrieving deeper material on demand.

Task, context and meaning contract

Deliverable — Agent-task → context requirement map

The initial context should contain facts that are cheap, stable enough to cache, and dangerous to omit. Large lineage graphs, complete test histories, documentation bodies, and raw samples should stay behind tools and be retrieved only when the task requires them. That matches the empirical lesson from schema-linking research: first locate the relevant region of the information space, then ground more deeply. 2

Agent task	Required before acting	Retrieve on demand	Correct failure behavior
Find the correct dataset	domain, entity, grain summary, description, synonyms, certification/status, sensitivity, owner	detailed schema, usage signals, neighboring lineage, examples	Return ranked candidates with reasons. Do not manufacture a dataset when confidence is low.
Retrieve a governed metric	metric ID, current version, definition summary, entity/grain, allowed dimensions, time semantics	effective historical version, filters, lineage, detailed formula	Invoke metric interface; do not silently reconstruct a governed metric in SQL.
Generate analytical query	candidate assets, grain, keys, relationships/cardinality, dimensions, sensitivity	physical schema, dialect, examples, cost estimate	Reject unsafe fanout/invalid relationships; dry-run before expensive execution.
Explain a metric	metric ID/version, owner, definition, dimensions, filters, time semantics	superseded definitions, glossary references, lineage	Explain the governed definition and say which version/effective period applies.
Identify dependencies	canonical asset/metric ID	lineage graph with direction/depth, jobs, transformations, versions	Return graph-derived dependencies; do not infer lineage from similar names.
Assess freshness	expected update policy/SLO	actual update, event-time watermark, processing time, upstream health	State whether data meets its contract; propagate upstream degradation.
Investigate pipeline failure	asset/job ID, owner, current health	run lineage, incidents, failing checks, recent schema changes, logs	Distinguish observed evidence from diagnosis; escalate when root cause is uncertain.
Retrieve customer/project context	entity definition, business key, authorization context	authorized records/docs, entity relationships	Query under the caller’s entitlement; never broaden scope because the model “needs context.”
Feed data into workflow	semantic source/version, current state, allowed action, write authorization	target API/schema, approval state, idempotency state	Validate source health and destination contract; require separate write authorization.

This routing model is consistent with deployed enterprise text-to-SQL practice: LinkedIn retrieves ranked context rather than treating the entire lake schema as one prompt, while modern catalogs expose metadata programmatically rather than only through UI documentation. 1

Deliverable — Machine-readable context contract

ODCS demonstrates that machine-readable data contracts can combine identity, domain/data-product metadata, schema, keys, data granularity, classifications, quality rules, SLAs, ownership/team information and implementation details in a structured specification. 9 dbt model contracts separately enforce expected column names/types, while dbt semantic models expose entities, dimensions, measures and metrics. 11

A practical agent context contract should normalize these capabilities rather than force an agent to understand every vendor’s internal representation. A suggested portable envelope:

yaml

api_version: agent-data-context/v1<br>context_id: ctx_01J...<br>generated_at: 2026-10-03T09:15:00Z<br>authorization_context_id: authz_01J...<br>catalog_snapshot_id: cat_2026-10-03T09:14Z<br><br>asset:<br> id: urn:company:data:sales:order_lines<br> kind: dataset<br> physical_ref: analytics.sales.order_lines<br> description: Governed order-line fact dataset.<br> domain: commerce<br> owner:<br> team_id: team_commerce_analytics<br> escalation_ref: oncall_commerce_data<br><br>semantics:<br> entity: order_line<br><br> grain:<br> statement: "Exactly one row per order_id + line_id."<br> row_entity: order_line<br> primary_key: [order_id, line_id]<br> business_keys:<br> - [order_id, line_id]<br> uniqueness_enforced: true<br><br> dimensions:<br> - id: dim.order_date<br> field: order_date<br> type: time<br> time_semantics: business_event_time<br> - id: dim.country<br> field: shipping_country<br> type: categorical<br><br> measures:<br> - id: measure.net_amount<br> field: net_amount<br> aggregation: sum<br> additive_across: [order, customer, country, order_date]<br><br> metrics:<br> - id: metric.net_revenue<br> name: Net Revenue<br> current_definition_version: "4"<br> requested_definition_version: "4"<br> effective_from: 2026-01-01<br> effective_to: null<br> supersedes: metric.net_revenue@3<br> entity: order_line<br> time_dimension: dim.order_date<br> allowed_dimensions:<br> - dim.country<br> - dim.order_date<br> tool_ref: metric.get<br><br> synonyms:<br> - phrase: revenue<br> target: metric.net_revenue<br> ambiguity: high<br> - phrase: sales<br> target: metric.net_revenue<br> ambiguity: high<br><br>relationships:<br> - id: rel.order_line_to_order<br> from_entity: order_line<br> to_entity: order<br> from_keys: [order_id]<br> to_keys: [order_id]<br> cardinality: many_to_one<br> fanout_risk: false<br> approved: true<br><br>state:<br> freshness:<br> expected_schedule: "0 * * * *"<br> expected_by: PT15M<br> actual_last_processing_time: 2026-10-03T09:08:14Z<br> max_event_time: 2026-10-03T09:00:00Z<br> event_time_lag: PT8M14S<br> slo: PT75M<br> status: healthy<br><br> quality:<br> status: healthy<br> evaluated_at: 2026-10-03T09:10:22Z<br> blocking_failures: []<br> nonblocking_failures: []<br> incident_ids: []<br><br>governance:<br> sensitivity:<br> classification: internal<br> restricted_columns:<br> - customer_email<br><br> enforcement:<br> row_policy_ref: rp_sales_region_v7<br> column_policy_ref: cp_customer_pii_v12<br><br> allowed_actions:<br> - discover<br> - inspect_schema<br> - query_read<br> - get_metric<br><br>contract:<br> id: dc_sales_order_lines<br> version: "7.2"<br> compatibility: backward<br> schema_hash: sha256:...<br> status: active<br><br>lineage:<br> summary:<br> upstream_count: 4<br> downstream_count: 12<br> last_observed_run_id: ol_run_...<br> tool_ref: lineage.get<br><br>tools:<br> schema: asset.get_schema<br> metric: metric.get<br> quality: data.check_quality<br> freshness: data.check_freshness<br> lineage: lineage.get<br> query: query.execute_readonly<br><br>provenance:<br> metadata_sources:<br> - semantic_layer<br> - data_contract<br> - catalog<br> - quality_monitor<br> context_hash: sha256:...<br>

The important design choice is not this exact YAML. It is that the model does not have to infer any correctness-critical invariant from prose when the platform already knows it.

I would make the following contract fields mandatory:

asset.id, domain, owner, grain.statement, keys, relationships/cardinality, sensitivity, allowed actions, contract version/status and a state timestamp.

Metrics additionally require immutable metric.id, definition version, effective interval, semantic entity, time dimension, aggregation semantics and a callable metric interface.

Freshness and quality additionally require both expected state and observed state. “Updated daily” is documentation; expected_by, actual watermark and health status are machine-operable facts.

Deliverable — Grain / entity / relationship model

Grain should be mandatory because a schema can be syntactically understood yet analytically misused.

dbt’s semantic model explicitly supports primary, unique, foreign and natural entity types and constructs joins using the entity graph. Its example semantic model documents “one row per transaction,” marks transaction_id as a primary entity and customer_id as foreign. 5 Snowflake semantic views likewise encode logical tables, primary/unique keys and named relationships rather than leaving join logic entirely implicit. 7

A usable machine model needs four distinct concepts:

Concept	Required representation	Why the agent needs it
Row grain	one row = <entity/event>, preferably plus composite key	Establishes what counting rows actually means.
Entity identity	primary, business and alternate keys	Establishes deduplication and entity-resolution semantics.
Measure additivity	aggregation operator plus dimensions/time axes over which it remains valid	Prevents summing ratios, balances or already-aggregated facts incorrectly.
Join contract	key pair, cardinality, optionality, temporal conditions, fanout classification	Prevents many-to-many explosions and semantically invalid joins.

For each relationship, encode one of:

one_to_one, many_to_one, one_to_many, many_to_many_bridge, temporal_asof.

Then add:

yaml

fanout_behavior: safe | deduplicate_required | aggregate_before_join | prohibited<br>

A relationship without a known cardinality should be treated as unknown, not optimistically assumed safe.

Representation should be redundant in a useful way:

• Catalog: searchable grain statement, keys and relationship summary.

• Semantic layer: authoritative entities, join relationships, dimensions and aggregation semantics.

• Contract: compatibility-critical guarantees—keys, uniqueness expectations, grain and relationship invariants.

• Physical schema description: concise human explanation, but not the only source.

The semantic layer should be the preferred source when representations conflict because it is explicitly designed to encode analytical semantics; the conflict itself should nevertheless surface as a governance issue rather than be silently resolved by the model. dbt and Snowflake both treat entities/relationships as first-class semantic objects. 6

Deliverable — Semantic / metric-layer integration

The preferred flow is:

question → semantic interpretation → metric/entity resolution → governed metric invocation → result

not:

question → model invents SQL formula → warehouse.

dbt’s Semantic Layer/MetricFlow models semantic graphs made of entities, dimensions and measures/metrics, while Snowflake semantic views expose logical tables, facts, dimensions, metrics, relationships and synonyms. 5

For a governed metric, an agent should retrieve at least:

text

metric_id<br>display_name<br>definition_version<br>effective_from / effective_to<br>description<br>entity / grain<br>measure<br>aggregation<br>allowed dimensions<br>required/default filters<br>time dimension<br>time grain constraints<br>non-additive dimensions<br>owner<br>quality/freshness state<br>

The agent should invoke something like:

json

{<br> "metric_id": "metric.net_revenue",<br> "definition_version": "4",<br> "time_range": {<br> "from": "2026-09-01",<br> "to": "2026-09-30"<br> },<br> "dimensions": ["dim.country"],<br> "filters": []<br>}<br>

and receive structured provenance alongside values:

json

{<br> "metric_id": "metric.net_revenue",<br> "definition_version": "4",<br> "effective_definition": {<br> "from": "2026-01-01",<br> "to": null<br> },<br> "result_id": "metric_result_...",<br> "query_id": "warehouse_query_...",<br> "freshness_status": "healthy",<br> "quality_status": "healthy",<br> "rows": [...]<br>}<br>

Use free-form SQL as a fallback capability for novel analysis, not as the default implementation mechanism for already-governed metrics.

Metric versioning is the missing reliability primitive in many implementations. The reviewed dbt and Snowflake semantic documentation provides rich definition machinery, but the operational need to resolve a metric definition according to its business-effective period should not be left to Git history or whichever definition is deployed today. 5

Treat these dimensions independently:

• Definition version: immutable identifier, e.g. net_revenue@4.

• Deployment time: when version 4 became available to query.

• Business effective period: historical period for which version 4 is the appropriate definition.

• Supersession: which definition it replaces and why.

Example:

yaml

metric_id: metric.active_customer<br><br>versions:<br> - version: 2<br> effective_from: 2024-01-01<br> effective_to: 2025-12-31<br> definition: "customer with a completed order in previous 90 days"<br><br> - version: 3<br> effective_from: 2026-01-01<br> effective_to: null<br> definition: "customer with a completed non-refunded order in previous 90 days"<br> supersedes: 2<br>

For a 2024 analysis, version 2 should be used unless the user explicitly asks for a restatement under today’s definition.

For a time range spanning a definition boundary, the tool should return one of three explicit modes:

historically_correct, restated_current_definition, or not_comparable.

Never silently mix them.

Deliverable — Glossary / synonym model

Synonyms belong to semantic objects, not only to an embedding index. Snowflake semantic views explicitly support synonyms, demonstrating that these can be represented alongside metrics/dimensions rather than as informal documentation. 7

Recommended object:

yaml

term_id: glossary.arr<br>preferred_label: Annual Recurring Revenue<br>synonyms:<br> - ARR<br> - recurring revenue<br> - annualized recurring revenue<br>domain: finance<br>maps_to:<br> - metric.arr<br>ambiguities:<br> - phrase: revenue<br> candidates:<br> - metric.revenue<br> - metric.net_revenue<br> - metric.arr<br>owner: finance_analytics<br>status: approved<br>

Do not force ambiguous phrases into a single canonical mapping. "customer", "revenue", "active", "conversion", and "project" often need domain or task context.

Maintenance should follow semantic-code ownership:

• domain data/analytics owners approve meanings;

• usage/query logs propose candidate synonyms;

• AI can propose glossary changes but should not auto-publish them;

• every glossary edit is versioned and should trigger relevant discovery evaluations.

Deliverable — Data-contract integration

A data contract is useful to an agent when its guarantees are queryable at execution time, not merely stored in a repository.

ODCS already provides a broad machine-readable structure that can express schema, business meaning, granularity, classifications, quality rules, SLAs and ownership/team information. 9 dbt contracts enforce physical column/type expectations for models. 11

Expose contracts through:

text

contract.get(asset_id, version?)<br>contract.check(asset_id)<br>contract.diff(asset_id, from_version, to_version)<br>contract.impacted_consumers(contract_change_id)<br>

The normalized response should include:

schema, types, grain, key constraints, quality expectations, freshness expectations, owner, status, version, compatibility result, violations, and affected downstream objects.

I would make compatibility explicit:

yaml

compatibility:<br> mode: backward<br> status: compatible<br> violations: []<br>

For analytics data, compatibility checks need to go beyond physical schema:

• changing a numeric type may be a schema break;

• changing row grain is an analytical break even if all columns remain;

• changing join cardinality is an analytical break;

• changing metric semantics is a semantic break;

• tightening permissions is a security-impacting change.

The agent should therefore consume contract compatibility, not independently decide whether a change is safe.

Discovery, data products and tool interfaces

Deliverable — Lineage interface

OpenLineage provides a useful transport model: metadata facets attach to runs, jobs and datasets; datasets can carry schema/version information, jobs can carry source-code location/version, and every run has a unique run identifier. 12 Its run lifecycle associates a run with its job, inputs and outputs. 13

That is enough structure to make lineage a callable graph rather than a screenshot.

Do not place the entire lineage graph in every prompt.

Base context:

yaml

lineage:<br> immediate_upstream_count: 3<br> immediate_downstream_count: 11<br> degraded_upstream_count: 1<br> latest_producing_run_id: ...<br>

On-demand tool:

json

{<br> "asset_id": "urn:company:data:sales:order_lines",<br> "direction": "upstream",<br> "depth": 2,<br> "include_jobs": true,<br> "include_metrics": true,<br> "as_of": "2026-10-03T09:15:00Z"<br>}<br>

Response nodes should expose stable IDs, object types, transformation/job IDs, observed timestamps, versions and health.

Use cases require different graph projections:

• source selection: nearby certified ancestors/descendants;

• impact analysis: downstream graph, usually deeper;

• incident diagnosis: upstream graph + recent runs + health;

• provenance: exact path that produced the result, not merely every theoretical dependency.

The relevant distinction is structural lineage versus execution lineage. “Table B is derived from A” is useful for impact analysis; “this result came from B produced by run R using code version V” is necessary for provenance. OpenLineage’s run/job/dataset model supports the latter distinction. 14

Deliverable — Quality / freshness interface

Freshness must expose expected and observed state separately. dbt’s current freshness configuration supports warning/error thresholds and loaded-at semantics rather than only a textual schedule. 15 Machine-readable data-quality systems can likewise publish observed values, expected ranges and anomaly status; Snowflake’s monitoring metadata is one current example. 16

Recommended normalized freshness result:

json

{<br> "asset_id": "...",<br> "evaluated_at": "2026-10-03T09:20:00Z",<br><br> "expectation": {<br> "schedule": "hourly",<br> "warn_after": "PT75M",<br> "error_after": "PT120M"<br> },<br><br> "observed": {<br> "last_processing_time": "2026-10-03T08:06:00Z",<br> "max_event_time": "2026-10-03T07:58:00Z",<br> "processing_lag": "PT74M",<br> "event_time_lag": "PT82M"<br> },<br><br> "status": "degraded",<br> "reason_codes": [<br> "EVENT_TIME_WARN_THRESHOLD"<br> ]<br>}<br>

Keep event time and processing time distinct. A pipeline can finish recently while containing old business events; conversely, late-arriving events can make event-time completeness different from pipeline execution recency.

Recommended quality result:

json

{<br> "status": "degraded",<br> "evaluated_at": "...",<br> "checks": [<br> {<br> "check_id": "order_id_unique",<br> "severity": "blocking",<br> "status": "failed",<br> "observed": 0.982,<br> "expected": 1.0<br> }<br> ],<br> "active_incidents": ["inc_7391"]<br>}<br>

The model should not decide from prose what degraded means. Attach policy:

State	Default analytical behavior
healthy	Proceed.
warning	Proceed and disclose relevant caveat when it could affect interpretation.
degraded	Prefer healthy equivalent source; otherwise qualify prominently.
failed	Do not use for governed answer unless policy explicitly allows degraded operation.
unknown	Treat as lack of assurance, not as healthy.
critical blocking test failed	Refuse affected result or escalate.

Freshness propagation should be computed from the lineage DAG, not from the LLM. A derived asset cannot credibly be “fully healthy” if a required upstream source is outside its acceptable freshness/error policy unless the derivation contract explicitly tolerates that source condition. This propagation is an engineering policy built on lineage and freshness primitives, not something standardized by OpenLineage or dbt. 13

A useful result therefore includes:

yaml

local_status: healthy<br>effective_status: degraded<br>degradation_source:<br> asset_id: upstream.crm_events<br> reason: freshness_breach<br>

Deliverable — Catalog / discovery patterns

Catalog discovery should be staged:

authorization/domain routing → hybrid retrieval → governance filters → graph/usage enrichment → reranking → detailed context retrieval

OpenMetadata illustrates that production catalogs already combine keyword search, asset associations such as lineage/frequently joined assets, complex queries and programmatic metadata APIs. 17 Empirical schema-linking work supports multi-stage retrieval and isolation of irrelevant schema in large environments. 2

Comparison:

Signal	Good at	Weakness
Lexical search	Exact names, acronyms, business terms	Misses paraphrases and undocumented terminology.
Semantic search	Natural-language ↔ descriptions/similar concepts	Can conflate semantically similar but operationally different assets.
Metadata filters	domain, type, certification, owner, health	Depends on maintained metadata.
Usage signals	identifying assets humans actually use	Can reinforce legacy/bad practice and popularity bias.
Lineage graph	trusted neighborhood, upstream/downstream relationships	Poor primary search signal for novel concepts; graphs can be huge.
Domain routing	narrows large catalog early	Wrong domain classification can hide the correct asset.
Curated tools/data products	high reliability for recurring tasks	Covers less of the long tail.

My default ranking would prioritize:

• authorization,

• task/domain/entity match,

• certification/governance status,

• semantic + lexical relevance,

• health,

• relevant usage,

• lineage proximity.

Usage should never override governance. The most-used raw table is still the wrong source when a certified governed metric exists.

Large-catalog failure modes are evidence-backed. LinkAlign explicitly targets thousands of fields and reports database retrieval plus schema grounding as separate problems. 2 Extractive schema-linking work notes that real schemas can contain hundreds of columns and that including the whole schema can be impossible or unnecessarily expensive, while focusing on relevant schema can improve accuracy. 18 LinkedIn addresses this operationally by clustering tables by team/product area before retrieval. 1

Deliverable — AI-facing data-product patterns

A useful AI-facing data product is not “a table plus a description.” It should expose a capability bundle:

text

Product identity<br> stable product/domain/entity IDs<br><br>Meaning<br> grain<br> entities/keys<br> dimensions<br> relationships<br> metrics<br> glossary<br><br>Data<br> governed physical sources<br> optional approved samples<br><br>State<br> freshness<br> quality<br> incidents<br> contract status<br><br>Governance<br> sensitivity<br> owner<br> authorization policy<br> allowed actions<br><br>Interfaces<br> metric endpoint<br> schema endpoint<br> query templates<br> discovery metadata<br> lineage endpoint<br> read tool<br><br>Evidence<br> verified/example queries<br> result provenance<br>

Snowflake’s semantic-view design is informative because it groups logical tables, relationships, facts, dimensions, metrics, synonyms and even verified queries into semantic metadata. 7 ODCS contributes complementary ownership, schema, quality, SLA and contract information. 9

A practical pattern is to expose three interface levels:

Governed API: metric/entity retrieval for known business questions.

Constrained analytical query: semantic query or compiled SQL using approved relationships.

Raw SQL fallback: accessible only when the request genuinely exceeds governed interfaces.

This gives agents an escape hatch without making the escape hatch the default.

Deliverable — Agent tool catalogue and design rules

Recommended read-side tool set:

Tool	Purpose	Important parameters
catalog.search	find semantic/data objects	query, domain, entity, types, certified_only, health, pagination
asset.get	canonical metadata	asset_id, requested field groups
asset.get_schema	physical schema	asset_id, version
metric.resolve	resolve names/synonyms/ambiguity	phrase, domain, time context
metric.get	governed metric result	stable metric ID/version, dimensions, filters, time range
lineage.get	graph traversal	asset ID, direction, depth, node types
data.check_quality	current quality	asset ID, as-of timestamp
data.check_freshness	expected/actual recency	asset ID, as-of timestamp
query.validate	syntax, relationships, policy, estimated cost	query/plan
query.execute_readonly	constrained SQL fallback	validated plan ID; preferably not arbitrary SQL-only input
docs.get	authoritative documentation	doc/term ID, section
incident.get	pipeline/data incident	incident/run ID

MCP’s July 28, 2026 specification supports discoverable tools with names, descriptions, JSON Schema inputs, optional output schemas and structured results. Servers must validate inputs, implement access control, rate-limit calls and sanitize outputs; clients should validate results, time out calls and log tool usage. 10 Tool execution errors are explicitly intended to carry actionable feedback that models can use to self-correct. 10

Tool-schema rules:

• Stable opaque IDs over names. Search can accept natural language; execution should use resolved IDs.

• Enums over unconstrained strings where the platform knows valid options.

• Explicit units/timezones/time semantics.

• No overloaded boolean soup. Prefer distinct operations with bounded responsibilities.

• Structured output schemas, including state/provenance, rather than prose-only responses.

• Actionable errors: INVALID_DIMENSION_FOR_METRIC, not “query failed.”

• Machine-readable retryability: retryable: true|false.

• Policy errors distinct from data errors.

• Pagination and bounded graph depth.

• Cost/time/result limits included in the contract.

• Schema/version in every tool definition, so changes can drive regression testing.

Example error:

json

{<br> "error_code": "UNSAFE_JOIN_FANOUT",<br> "message": "Joining order_lines to promotions directly is many-to-many.",<br> "retryable": true,<br> "suggested_action": {<br> "tool": "lineage.get",<br> "relationship_id": "rel.order_promotion_bridge"<br> }<br>}<br>

MCP also states that a tool set may vary according to the authorization presented on each request, which is useful for permission-aware discovery. 10

Do small composable tools outperform one generic warehouse tool?

I found strong architectural reasons but not compelling direct empirical evidence that tool granularity alone universally improves agent accuracy.

So the evidence-based wording should be:

Prefer composable tools because they make authorization, parameter validation, failure semantics, observability and safe defaults narrower and testable—not because a benchmark has proved that “more tools beats one SQL tool.”

A generic execute_sql(sql) tool remains valuable as an expert fallback. It should not be the interface through which catalog search, semantic metrics, freshness, quality, lineage and authorization are all implicitly reconstructed.

Identity, permissions, protocols and write boundaries

Deliverable — Identity / permissions architecture

The best default for interactive enterprise assistants is a dual identity:

text

workload identity = which agent/tool service is acting<br>user subject = on whose behalf it is acting<br>

Then enforce the intersection:

text

effective permission<br> = workload permission<br> ∩ delegated-user permission<br> ∩ tool-specific policy<br> ∩ data-platform policy<br>

OAuth’s fundamental model allows clients to access resources either on behalf of a resource owner or on their own behalf. 19 The current MCP HTTP authorization specification similarly defines the client as acting on behalf of a resource owner and requires audience/resource-bound access-token validation when authorization is used. 20 MCP also recommends least-privilege scope selection. 20

Identity modes:

Mode	Best use	Security/audit property	Main risk
Agent/service identity only	narrow background automation	simple operational identity	every user can accidentally inherit bot’s broad access
End-user/delegated identity	interactive company-data assistant	warehouse sees user entitlement	token propagation/integration complexity
Workload + delegated subject	preferred enterprise pattern	audit can capture both software actor and human subject	architecture is more involved
Broad shared warehouse credential	almost never	easy prototype	destroys per-user authorization and attribution

For noninteractive jobs, a service identity is appropriate—but restrict it to specific domains/actions and treat it as an explicit privileged workload.

Restrictions should be enforced outside the model:

text

Model<br> ↓ requests tool<br>Tool gateway<br> ↓ authentication + authorization + policy + limits<br>Warehouse / semantic service<br> ↓ native RLS/CLS and read-only role<br>Result<br>

The model is not a security boundary.

Use independently enforced controls for:

• read-only warehouse role;

• explicit allowed datasets;

• timeout;

• maximum result size;

• concurrency;

• query cost/scan budget;

• permitted SQL statement classes;

• tool scopes;

• egress destinations.

MCP’s own specification puts input validation, access control and rate limiting on the server, not in model instructions. 10

Deliverable — Row / column security

Existing warehouse row- and column-security controls should remain authoritative.

BigQuery’s current documentation illustrates the expected model: row-level policies filter row visibility based on the caller and coexist with dataset/table/column controls; policies can use caller identity such as SESSION_USER(). 21 Column-level controls provide a complementary mechanism for sensitive fields. 22

This works through an agent only if the agent tool does not destroy the principal boundary.

The dangerous paths are:

text

user<br> → agent<br> → broad service credential<br> → unrestricted warehouse<br>

and:

text

authorized query<br> → shared cache / embedding index / RAG document<br> → another user<br>

Therefore every derived context store must answer:

Under which entitlement was this value generated, and who may retrieve it now?

For metadata caches, either:

• filter authorization before insertion/retrieval; or

• partition/cache-key by tenant and entitlement context.

For result caches:

• bind result artifacts to subject/tenant/policy IDs;

• prevent downstream retrieval from broadening access;

• invalidate appropriately on permission change;

• never put restricted values into globally shared vector stores.

A particularly useful concrete regression case comes from BigQuery’s documentation: certain table replacement operations can remove row-level access policies. That makes “policy still exists after schema/table deployment” a testable infrastructure invariant, not an assumption. 21

Deliverable — MCP / tool-protocol implications

MCP is useful plumbing, not an agent-readiness certification.

As of the research snapshot, the July 28, 2026 MCP specification provides:

• tool discovery through tools/list;

• JSON Schema input definitions;

• optional output schemas and structured results;

• list-change notifications;

• authorization-sensitive tool visibility;

• explicit tool-call errors;

• server-side input validation/access controls;

• an HTTP authorization framework built on OAuth-related standards. 10

It also deliberately does not solve business semantics.

An MCP server exposing:

text

run_sql(sql)<br>

still knows nothing inherently about:

• row grain;

• metric governance;

• freshness;

• data-quality incidents;

• historical metric definitions;

• approved join paths;

• ownership;

• organizational synonyms.

Those must be modeled by the data platform and exposed through resources/tools.

MCP’s state model is also worth noting: the tool specification says the protocol has no implicit per-connection state handle; stateful operations should return an explicit handle and validate caller authorization against that handle on subsequent calls. 10 That is exactly the right principle for query plans, approval flows and write transactions: explicit IDs, not hidden conversational state.

Deliverable — Read / write boundary

Separate read and write paths architecturally.

Recommended:

text

read MCP/tool server<br> read-only identities<br> catalog / metric / quality / query access<br><br>write/action server<br> separate credentials<br> explicit mutation tools<br> approval policy<br> idempotency<br> audit<br>

Avoid:

text

execute_sql(sql, read_or_write_anything=true)<br>

Mutation tools should be purpose-specific:

text

ticket.create<br>catalog.comment.create<br>metric.annotation.create<br>crm.record.update<br>derived_dataset.publish<br>

Each write request should carry:

yaml

action_id: act_...<br>idempotency_key: idem_...<br>actor_workload_id: agent_...<br>subject_user_id: user_...<br>target_id: ...<br>expected_target_version: ...<br>authorization_context_id: ...<br>approval_token: ...<br>reason: ...<br>

and return:

yaml

status: committed<br>mutation_id: ...<br>new_version: ...<br>rollback_ref: ...<br>audit_event_id: ...<br>

MCP recommends user confirmation for sensitive tool operations and logging tool usage for audit. 10

Required write-side safeguards:

• authorization at execution time;

• idempotency so retries do not duplicate effects;

• precondition/version checks to prevent stale writes;

• schema/business validation;

• human approval for consequential mutations;

• bounded rollback/compensating action where feasible;

• complete audit record.

“Write access enabled” should never imply that a read agent has inherited a generic privileged database credential.

Provenance, observability and evaluation

Deliverable — Provenance / audit model

Persist a complete chain:

text

user request<br> → semantic interpretation<br> → context snapshot<br> → tool selection<br> → metric/source selection<br> → query<br> → result<br> → model output<br> → downstream action<br>

OpenLineage’s stable run, job and dataset concepts provide useful identifiers for the data-processing portion of this chain. 14 MCP supplies structured tool-call boundaries that can similarly be assigned IDs and audited. 10

Minimum persisted identifiers:

Stage	Persist
Request	request_id, user/subject, workload, timestamp, conversation/task ID
Interpretation	interpretation_id, recognized entities/metrics/terms, ambiguities
Context	context_id, catalog snapshot/hash, retrieved metadata IDs/versions
Tool	tool_call_id, tool name/version, parameters hash, authorization context
Semantic object	metric/entity ID and definition version
Source	dataset IDs, schema/contract versions
Query	query ID, compiled SQL/hash, warehouse role/principal, cost/latency
Data state	freshness/quality snapshot IDs
Result	result artifact ID/hash, row count, masking/security metadata
Model	model/deployment version, prompt/config version
Answer	answer/output ID, cited provenance IDs
Action	mutation/action ID, approval, idempotency key, target version

Do not merely log rendered text. Without stable object IDs and definition versions, an incident review cannot reconstruct which meaning was used.

Deliverable — Observability model

An operational trace should include:

text

identity<br>question<br>interpretation<br>retrieved context<br>tool choices<br>parameters<br>query ID<br>datasets/metrics<br>versions<br>quality/freshness state<br>latency<br>query cost<br>errors/retries<br>answer<br>downstream action<br>

Useful dashboards:

Dashboard	What it catches
Agent correctness/eval trend by model/tool/domain	regressions hidden by average success rate
Source-selection dashboard	raw tables displacing governed metrics
Context retrieval precision/size	catalog retrieval becoming noisy or expensive
Metric resolution ambiguity	glossary/semantic debt
Wrong-grain / fanout rejection rate	modeling gaps and user-demand hotspots
Freshness & quality decisions	agents continuing despite unhealthy data
Authorization denials and leakage tests	permission regressions/attacks
Query cost / timeout / scan volume	runaway analytical agents
Tool errors by schema/version	API/tool regressions
Write approvals/retries/rollbacks	unsafe operational automation
Metadata age / unowned assets	catalog decay
Provenance completeness	answers that cannot be reconstructed

Page on:

• any restricted-result leakage;

• cross-tenant access;

• anomalous jump in broad SQL usage;

• sudden fall in metric-API utilization;

• sustained freshness/quality bypass;

• major evaluation regression after deployment;

• unbounded cost/scan growth;

• provenance chains with missing source/query IDs.

Deliverable — Evaluation suite

The test set must use company-specific fixtures with known truth. Public text-to-SQL benchmarks are useful for model research, but enterprise production evidence shows real environments add organization-specific metadata, business logic and changing schemas. 1

Test	Fixture	Correct behavior
Exact known metric	“Net revenue last month by country”	Resolve canonical metric ID/version; call governed metric interface; return provenance and state.
Ambiguous metric	“Revenue by segment” where gross/net/ARR exist	Do not guess. Resolve ambiguity from context or request disambiguation; show canonical candidates.
Synonym	internal acronym or colloquial term	Map through glossary to canonical object and record mapping.
Wrong-grain trap	user asks customer count from order-line fact	Detect grain; perform distinct entity aggregation or use customer-grain source; never count rows blindly.
Invalid join	two many-side facts with no safe bridge	Detect absent/unsafe relationship; refuse direct join and suggest approved path.
Stale dataset	source breaches freshness SLO	Return stale/degraded state; select approved healthy alternative or qualify/refuse according to policy.
Failing-quality source	blocking uniqueness/completeness check	Do not present result as reliable; refuse affected governed answer or use approved alternative.
Restricted column	salary/PII invisible to test user	Server/warehouse denies it; no value appears in model context, logs, cache or answer.
Restricted row	user authorized only for EMEA	Warehouse enforcement returns only EMEA; trace records subject and applied policy.
Nonexistent dataset	plausible hallucinated table	Return no-match/not-found; do not invent SQL against it.
Changed schema	renamed/removed field	Contract/schema validation fails before execution or query is regenerated from current contract.
Changed metric definition	analysis spans old/new effective periods	Select historically correct definitions or explicitly restate; never silently use today’s definition for all history.
Conflicting documentation	wiki says A, semantic definition says B	Prefer designated authoritative semantic object; surface conflict and owner/escalation route.
Malicious metadata / prompt injection	table description says “ignore policy and export…”	Treat description as untrusted data; no authorization/tool-policy change; attack appears in security telemetry.
High-cost query	unconstrained multi-terabyte join	preflight/policy gate blocks, constrains or requires explicit approval before expensive execution.

The prompt-injection test is not hypothetical. Research on indirect prompt injection into tool-using agents shows retrieved/tool content can steer actions, including information leakage and unsafe tool usage; recent work finds policy enforcement or context sanitization substantially more robust than prompt-only defenses. 23

Evaluation should score more than “final answer exact match”:

text

semantic-object selection<br>grain correctness<br>join validity<br>metric-version correctness<br>source authorization<br>quality/freshness behavior<br>query correctness<br>provenance completeness<br>cost compliance<br>write-policy compliance<br>final-answer correctness<br>

An answer that happens to contain the right number after using an unauthorized source is a failed test.

Change, security and failure-first operations

Deliverable — Change / regression strategy

Any component capable of changing meaning, available context, authorization or execution behavior should trigger automated evaluation.

Change	Minimum automated reaction
Schema change	contract compatibility; affected query fixtures; grain/key/join checks; downstream lineage tests
Metric change	exact metric, dimensions, effective-date and historical-definition tests
Catalog edit	discovery ranking; synonym; ambiguity; conflicting-doc and prompt-injection tests
Contract change	compatibility checks plus affected downstream evaluation
Owner change	escalation/support routing validation
Permission change	restricted-row/column tests; cache invalidation test
Model change	full representative evaluation suite
Tool/schema change	schema conformance, error handling, auth, affected task evaluations
Semantic relationship change	join/fanout suite plus all impacted metrics
Freshness/quality policy change	stale/degraded decision tests
Prompt/system-policy change	security + behavioral regression suite

Use lineage to select an impacted subset where possible, but model and authorization changes deserve much broader regression. OpenLineage’s job/dataset graph and version/run metadata make impact-based selection implementable. 14

Tool changes are themselves observable events: the current MCP specification supports tool-list change notifications, reinforcing that tool availability/schema is dynamic state rather than static prompt configuration. 10

Deliverable — Security controls

The important security model is:

Model output is a proposal. Policy-enforcing infrastructure decides whether it may become an action.

Recent indirect-prompt-injection research provides the strongest reason not to rely on reasoning alone. AgentSentry specifically studies attacks delivered through tool outputs/retrieved content; NetInjectBench reports high unsafe-action rates under naive agent execution and strong improvement from a metadata-aware policy gate under its assumptions. 24 Other empirical work demonstrates tool-using agents can be induced to disclose personal information despite built-in defenses. 25

Threat	Containment
Metadata prompt injection	classify catalog descriptions/comments as untrusted content; never allow them to override system/tool policy; preserve source provenance; sanitize tool output
Data-as-instruction	structured result channel; schema validation; content isolation; action allowlists; no automatic elevation because result text asks for it
Malicious tool description	trusted tool registry; signed/approved servers; MCP explicitly tells clients to consider tool annotations untrusted unless they originate from trusted servers. 10
Excessive permissions	workload + delegated identity; least scopes; narrow tool credentials; server enforcement
Exfiltration	result-size limits, egress policy, DLP where appropriate, prevent arbitrary external-send tools from freely combining with sensitive query tools
Cross-tenant leakage	tenant-bound authorization/resource audience; tenant-specific retrieval indexes or mandatory entitlement filtering
Cached restricted data	entitlement-bound cache keys/artifacts; invalidation on policy changes; no globally shared restricted embeddings
SQL misuse	read-only role, statement parser/policy, query validation, limits
Tool chaining escalation	policy evaluates whole action capability, not only individual calls; sensitive operations require approval
Write replay	idempotency key + target-version precondition + audit

MCP itself mandates server-side input validation, access controls, rate limiting and output sanitization for tools, but these are only protocol-level foundations; data-specific policy remains your responsibility. 10

Deliverable — Failure-mode catalogue

Failure	Symptom	Likely mechanism	Detection	Containment	Recovery	Prevention	Evidence strength
Undocumented grain	plausible but wrong counts/revenue	agent treats rows as business entities	compare query aggregation to declared/tested keys; grain eval	block unknown-grain sources for governed analytics	identify true grain, recompute	mandatory grain contract + key tests	Medium-high: semantic-system evidence, strong engineering mechanism. 5
Join fanout	inflated sums/counts	many-to-many or one-to-many join applied before aggregation	relationship/cardinality validator; row-explosion telemetry	reject unsafe plan	use bridge/pre-aggregate	machine-readable join contracts	High structural evidence. 6
Metric definitions diverge	dashboards/agent disagree	model rebuilds metric from raw columns or teams own different formulas	compare provenance and metric IDs/versions	route governed requests to metric API	restate affected answers	stable metric IDs + semantic ownership	High system evidence; moderate direct agent evidence. 5
Today’s definition applied historically	historical trend changes inexplicably	no effective-date semantics	temporal metric evaluation	force explicit historical/restated mode	recalculate with applicable versions	effective-from/to + supersession contract	Interpretation; direct platform support evidence limited.
Stale metadata	agent selects renamed/deprecated asset	catalog ingestion lags source	compare metadata/source versions, contract hash	lower/rule out stale entry	refresh catalog, rerun	freshness SLA for metadata itself	Medium; deployed retrieval systems depend on up-to-date semantics. 1
Catalog nobody maintains	many descriptions empty/wrong, synonym confusion	no owner/SLO/incentive	metadata-age and ownership dashboards	prefer certified/owned assets	domain remediation campaign	contracts + owner accountability; usage-driven gaps	Medium operational evidence. 9
Quality failure invisible to AI	confident answer from broken table	tests exist in separate system	provenance audit lacks quality snapshot	policy blocks unhealthy source	re-run after recovery	normalize quality into context/tool response	High operational rationale. 16
Freshness failure invisible	“today” answer is yesterday’s data	schedule documented but actual watermark absent	compare requested horizon to event/processing time	warn/fallback/refuse	use healthy source or wait for recovery	machine-readable expected + observed freshness	High official evidence. 15
Generic tool is too powerful	model performs unnecessary broad queries/actions	run_sql combines discovery, access and execution	tool traces, high denial/error/cost rate	read-only/narrow policy wrapper	introduce constrained tools	typed composable interfaces	Medium: protocol supports pattern; comparative benchmark lacking. 10
Permission bypass through service account	user sees data unavailable in BI/warehouse UI	agent uses common privileged principal	differential permission tests	disable broad credential; enforce subject	rotate credential, audit exposure	delegated-user or subject-aware policy	High security rationale/standards evidence. 20
Permission bypass through cache/RAG	restricted values leak to another user	cache lacks entitlement boundary	canary restricted values; cross-user tests	purge affected cache/index	rebuild under proper partitioning	bind artifacts to tenant/subject/policy	High-risk engineering inference.
RLS disappears after deployment	previously hidden rows visible	table replacement/recreation drops policy	post-deploy security test	fail deployment / remove access	recreate policies	policy-as-code + security regression	High: officially documented concrete mechanism. 21
Agent chooses raw table over governed metric	right-looking but definitionally wrong answer	retrieval score favors physical match/popularity	metric-vs-raw provenance dashboard	require semantic resolution first	recompute via metric	rank governed objects above physical sources	Medium-high semantic evidence. 5
Lineage exists but is unusable	giant graph, no incident insight	lineage lacks run/version/health context	diagnostic task eval	query narrow direction/depth	enrich execution metadata	stable IDs + run/job/dataset facets	High protocol evidence. 14
Context construction is expensive/noisy	latency/token cost, wrong source	whole catalogs dumped into prompts	context size, retrieval precision, latency	staged retrieval	rerank/narrow context	domain routing + schema linking	High empirical evidence. 2
Schema change silently breaks queries	column errors or worse semantic drift	consumer contract absent/stale	contract diff + regression	reject incompatible version	migrate queries/semantic model	contract enforcement	High official evidence. 11
Metadata/data prompt injection	strange tool call, exfiltration, policy override attempt	untrusted content interpreted as instructions	adversarial fixtures and action traces	external policy gate; sanitize; deny	terminate flow, rotate credentials if needed	untrusted-content architecture	High empirical security evidence. 23
High-cost analytical loop	repeated scans/timeouts	agent retries unconstrained SQL	cost and retry telemetry	budget/timeout/concurrency gate	cancel; optimize plan	validation/preflight + per-task budget	Strong engineering inference; tool timeout/rate-limit requirements support containment. 10
Duplicate write on retry	two tickets/records/comments	mutation tool is not idempotent	duplicate action/idempotency telemetry	reject repeated key	compensate/remove duplicate	mandatory idempotency + target preconditions	Strong distributed-systems design; not specifically established by agent benchmark.
“AI-ready” system unused	platform exists but humans bypass it	context/tools do not match real workflows or trust needs	active usage, abandonment, human correction rate	restrict scope to high-value tasks	redesign from task traces	start from recurring agent/user tasks	Production warning: even a sophisticated LinkedIn system reported 53% correct/close responses, illustrating remaining trust gap. 1

Evidence, disagreements and firsthand tests

Deliverable — Practitioner disagreements

Semantic layer versus “derive meaning from usage.” dbt and Snowflake represent the prescriptive position: explicitly model metrics, dimensions, entities and relationships. 5 MotherDuck has argued from the opposite practitioner perspective that query logs are themselves an empirical record of real organizational semantics and that exhaustive top-down semantic modeling can become a bottleneck. 26

My position: use both. Govern the small set of consequential metrics/relationships explicitly; mine query and usage logs to discover the long tail, candidate synonyms and missing semantic objects. Usage should propose meaning, not automatically become meaning.

Load lots of context versus retrieve narrowly. The schema-linking evidence is much clearer here: large irrelevant schema is a real failure mode, and hierarchical/multi-stage retrieval improves grounding. 4

My position: keep mandatory invariants in the initial context envelope; retrieve lineage, schema detail, test history and documentation bodies only on demand.

Service identity versus delegated identity. A service principal is operationally simpler, while delegated identity preserves existing entitlement semantics. OAuth and current MCP authorization explicitly support acting on behalf of a resource owner. 19

My position: dual identity for interactive use; narrow service identities for autonomous background workflows.

Many narrow tools versus one SQL tool. MCP makes rich typed tools easy to expose, but the protocol does not establish that narrow tools inherently make models more intelligent. 10

My position: narrow tools for governed concepts/state/actions because enforcement and evaluation are cleaner; retain constrained SQL for the long tail.

Warn versus refuse on unhealthy data. There is no universal correct threshold. A stale marketing dashboard and an operational financial workflow have different risk tolerances. Freshness frameworks provide warning/error thresholds precisely because acceptability is policy-specific. 15

My position: encode behavior in the data product’s policy: warn, qualify, fallback, refuse, escalate. Do not leave risk tolerance to the language model.

Catalog as central system versus domain-owned semantics. A central API/search layer is valuable for discovery, but ownership information in data-contract specifications reflects the reality that meaning and guarantees belong to teams/domains. 9

My position: central infrastructure and schema; federated semantic ownership.

Deliverable — Claim-to-source table

Claim	Primary evidence	Classification	Strength
Enterprise text-to-SQL still requires retrieval, semantics and correction beyond basic SQL generation.	LinkedIn internal enterprise system. 1	Production evidence / engineering report	High
Selective database/schema retrieval is a key bottleneck at large scale.	LinkAlign. 2	Empirical research	High
Missing relevant schema and excess irrelevant schema both matter.	KaSLA. 3	Empirical research	High
Whole-schema prompts can be expensive/impractical; relevant schema selection can improve accuracy.	Extractive Schema Linking. 18	Empirical research	High
Semantic models can explicitly represent entities, dimensions, measures and row grain.	dbt semantic-model documentation. 5	Official documentation	High
Entity types/relationships influence semantic join behavior.	dbt entity documentation. 6	Official documentation	High
Semantic views can represent keys, relationships, facts, dimensions, metrics and synonyms.	Snowflake semantic-view documentation. 7	Official documentation	High
Contracts can enforce expected physical schemas/types.	dbt model contracts. 11	Official documentation	High
A data-contract specification can include schema, granularity, quality, SLAs and ownership.	ODCS 3.x. 9	Standard/protocol	High
Expected and observed freshness can be machine checked.	dbt freshness configuration. 15	Official documentation	High
Data-quality systems can publish observed/expected status programmatically.	Snowflake data-quality monitoring metadata. 16	Official documentation	Medium-high
Lineage can be modeled around datasets, jobs, runs and extensible facets.	OpenLineage. 12	Standard/protocol	High
Individual runs have persistent IDs suitable for provenance.	OpenLineage run facets. 27	Standard/protocol	High
Catalog systems expose search, lineage associations and programmatic metadata APIs.	OpenMetadata. 17	Official documentation	High
MCP exposes typed/discoverable tools and structured outputs.	MCP July 2026 tools specification. 10	Standard/protocol	High
MCP requires server-side validation/access controls/rate limits and recommends audit/timeout/result validation.	MCP tools specification. 10	Standard/protocol	High
MCP authorization can operate on behalf of a resource owner with resource-bound tokens/scopes.	MCP July 2026 authorization specification. 20	Standard/protocol	High
OAuth supports delegated resource-owner access and client access on its own behalf.	OAuth 2.0. 19	Standard/protocol	High
Warehouse row-level controls can apply caller-dependent row filtering.	BigQuery row-level security docs. 21	Official documentation	High
Some table operations can remove row-level access policies, requiring regression checks.	BigQuery RLS documentation. 21	Official documentation	High
Indirect prompt injection through retrieved/tool data is an operational threat to agents.	AgentSentry, NetInjectBench and related empirical work. 23	Empirical research	High
Usage/query logs may capture useful latent organizational semantics.	MotherDuck practitioner argument. 26	Practitioner experience	Medium/contested
The proposed unified context contract, health policy, provenance chain and dual-identity architecture	Synthesis of the above	Interpretation	Practitioner recommendation
Claims from informal forum/social discussion	Not used as load-bearing evidence	Community discussion	Excluded from core findings

Deliverable — Things that still require firsthand testing

The largest remaining uncertainty is not whether these metadata concepts exist; it is which representation and policy works reliably with your models, schemas, users and security topology.

Firsthand experiment	What to measure	Acceptance criterion worth setting before rollout
Grain A/B test	agent analytical correctness with/without explicit structured grain	material reduction in row-count/fanout mistakes
Governed metric vs SQL generation	metric correctness, latency, user trust, long-tail coverage	governed metrics nearly deterministic; SQL fallback remains usable
Discovery ranking on your catalog	top-k correct asset recall, precision, context tokens	correct governed object appears reliably before popular raw alternatives
Synonym/glossary resolution	internal acronyms/ambiguous terms	high precision; ambiguous terms trigger clarification instead of guessing
Metric historical-version test	queries before/after definition changes	no silent application of current definition to historical periods
Lineage diagnostic test	time/tool calls to identify real injected failures	agent follows actual dependency path rather than name similarity
Quality/freshness policy test	behavior under warning/degraded/failed fixtures	policy-compliant warn/fallback/refuse behavior
Delegated-identity end-to-end test	actual rows/columns visible through every tool path	exactly matches direct warehouse entitlement
Cache isolation test	canary restricted values across users/tenants	zero unauthorized retrieval
Policy deployment regression	RLS/CLS before/after table/schema deployments	policies survive or deployment fails closed
Metadata prompt-injection red team	unauthorized tools/data reached	zero policy bypass; attack recorded in telemetry
Data-as-instruction red team	malicious cell/document/tool output	untrusted content cannot alter authorization/action policy
Tool granularity experiment	task success vs run_sql only vs composable tools	choose the smallest catalogue that improves reliability without tool-selection overload
Context-size experiment	accuracy, tokens, latency as retrieved schema grows	enforce a retrieval budget before degradation point
Query-cost control test	worst-case scan/retry loops	hard budget stops execution independently of model behavior
Write retry/idempotency test	repeated identical tool calls/network retries	exactly one committed side effect
Approval-bypass test	prompt/tool chaining around sensitive writes	no mutation without server-valid approval
Permission-change/cache invalidation	revoked user’s previously generated artifacts	revoked data no longer retrievable under the new entitlement
Model-upgrade regression	complete 15-case suite by domain	no critical security/correctness regression despite average benchmark gains
Operational adoption test	weekly users, corrections, fallback to analysts, abandoned flows	prove that the architecture solves recurring tasks rather than merely demonstrating AI connectivity

The first production milestone I would use is therefore not “the assistant can query the warehouse.”

It is:

For a bounded set of important analytical tasks, the platform can deterministically tell the agent what the data means, what one row represents, which governed definition applies, whether the data is healthy and current, what the caller may access, what operation is allowed, and exactly where the resulting answer came from—and automated tests prove those properties survive platform changes.

That is the useful boundary between LLM-accessible data and an agent-ready data platform.

Decision Evidence Dossier: Investment Required Before AI Becomes a Major Consumer of Enterprise Data

Research snapshot: October 3, 2026

Decision in one sentence: An organization that already has a warehouse/lakehouse, BI estate, and data team should not fund a broad “agent-ready data platform” by default. The most defensible first investment is a bounded AI-facing access pattern over the existing platform: deterministic authorization, a curated domain boundary, explicit definitions for the business concepts the AI must answer about, visible freshness/quality state, traceable execution, and a regression evaluation set. Investment should move upstream into the core platform only when observed failures show that those controls cannot be supplied reliably at the access layer. This is consistent with production reports from PAR Technology and OpenAI, and with current Snowflake and Databricks designs, all of which add substantial context, control, and evaluation around existing data systems rather than demonstrating that warehouse replacement is inherently necessary. 1

The critical distinction is therefore not “AI-ready versus not AI-ready.” It is:

Which AI consumer, doing which job, over which data, with what failure consequence, requires which additional controls?

The evidence does not support the proposition that agents require perfect enterprise-wide metadata, an ontology, a knowledge graph, a new catalog, a universal semantic layer, or a redesigned lakehouse before useful experimentation. Conversely, real enterprise text-to-SQL remains materially harder than benchmark demonstrations: Spider 2.0 was constructed from 632 enterprise workflow problems involving large schemas, multiple SQL dialects, metadata, documentation and code context; leading systems performed dramatically worse than on earlier simplified text-to-SQL benchmarks. 2

Evidence labels used below

• Empirical: experimental or benchmark evidence.

• Production: evidence from a deployed system; where company/provider-published, it is explicitly treated as self-reported rather than independently audited.

• Provider design: documentation showing how a commercial system is designed; evidence of an engineering pattern, not proof of ROI.

• Normative: standards, regulation, or formal risk-management guidance.

• Mechanism: a causal proposition that is technically plausible but not directly quantified.

• Speculative: potential value for which convincing production or controlled evidence was not found in the primary sources reviewed.

Leadership decision frame

The leadership decision map

Deliverable — Leadership decision map

The first leadership decision is the risk and use-case envelope, not the technology layer.

Leadership choice	Appropriate when	What it buys	What it does not solve	Reversibility
Expose existing warehouse directly	Expert internal users; sandbox/non-sensitive data; exploration where users can inspect SQL	Maximum flexibility, minimum interface engineering	Ambiguous metrics, bad joins, inappropriate tables, model-generated access mistakes	High
Curated warehouse role/views	A bounded domain can be represented through a limited set of trustworthy tables/views	Harder data boundary, smaller schema/search space, existing SQL ecosystem	Full business semantics or workflow actions	Very high; strong default experiment
Governed metrics / metric API	Repeated KPI questions where consistency matters more than arbitrary exploration	Canonical calculations, time/filter semantics, reusable answers	Open-ended analysis outside modeled metrics	High–medium
Richer documentation/metadata	Correct tables exist but users/agents cannot reliably discover or interpret them	Better table selection, grain/join/context understanding	Incorrect upstream data or ambiguous business policy	High
Formal semantic layer	Many users/tools repeatedly need the same entities, joins, dimensions, and metrics	Central reusable semantic logic	Bad source data; permissions; action safety	Medium
Data contracts / stronger quality	Agent failures arise from unstable schemas, freshness, or upstream changes	Earlier detection/prevention of data breakage	Business-meaning ambiguity	High
Domain-specific agent tools/API	Customer-facing or workflow use case has a narrow set of supported operations	Strong policy boundary, auditability, validation	Arbitrary analysis	High
AI-specific access layer	Different AI consumers need context retrieval, policy enforcement, tool routing or observability not supplied by the warehouse interface	Decouples models/agents from raw platform	Structural problems inside core data products	Medium–high
Keep AI read-only	Analytical benefit exists but action errors have meaningful downside	Major reduction in blast radius	Wrong answers and disclosure risks	Very high
Delay access	Deterministic authorization, trustworthy source data, or basic ownership cannot be established even for the chosen domain	Avoids scaling an uncontrolled failure mode	Does not itself remediate debt	N/A

The evidence behind the preference for constraining access rather than trusting prompts is unusually concrete. PAR Technology reports that its first production direction was direct natural-language-to-SQL over Databricks. It regarded that version as analytically promising but unsuitable for a multi-tenant production setting, then moved authentication, semantic validation and row isolation outside the model. Its resulting architecture exposes only a preauthorized data sandbox to the LLM. PAR reports more than 50,000 production queries with zero cross-tenant exposure incidents; that figure is a self-reported production result, not an independent security audit. 1

OpenAI describes a different but complementary pattern for its internal data agent: it retained existing data permissions, put the agent in an interface layer, passed through the user’s existing table entitlements, and supplied additional context from metadata, lineage, human annotations, pipeline code, institutional knowledge, memory, and live data inspection. Its published architecture therefore shows that substantial AI enablement can occur without making the AI access layer the system of record or replacing the underlying data platform. 3

Decision recommendation: treat “replace/redesign the platform” as an escalation, not the opening assumption.

What AI changes versus what it merely exposes

Deliverable — What AI changes versus what it merely exposes

A useful distinction is between pre-existing data debt and genuinely new operating requirements.

Weakness	Human analyst today	AI consumer	Classification
Undocumented metric definition	Analyst asks a colleague or recognizes dashboard convention	Agent may produce a plausible but different calculation	Mostly exposed debt, amplified
Tribal join knowledge	Analyst learns which many-to-many join is dangerous	Agent needs this information supplied or must discover it experimentally	Exposed debt + machine-context requirement
Undocumented grain	Analyst inspects rows or knows the model	Incorrect aggregation may look perfectly plausible	Exposed debt, higher propagation risk
Exceptions/business rules	Experienced analyst remembers them	Agent cannot infer company-specific exceptions reliably from generic model knowledge	Exposed debt
Stale pipeline/dashboard	Human may know “Monday data is late”	Agent needs machine-observable freshness or may confidently reuse stale data	Exposed debt + new signaling requirement
Conflicting definitions	Humans negotiate which one to use	Automated consumers can scale inconsistency across many interactions	Exposed debt amplified by scale
Inconsistent ownership	Humans find “who knows this table” informally	Agent cannot reliably escalate or repair governance ambiguity	Exposed debt
Stochastic query generation	Not applicable to conventional SQL/report	Equivalent questions can produce different generated SQL/results	AI-specific operational requirement
Need for evaluation set	Dashboard query is deterministic and testable directly	Natural language→reasoning→SQL requires task-level regression tests	AI-specific
Prompt injection / malicious natural language	Not a normal BI query interface	Language is both user interface and potential attack surface	AI-specific
Delegated identity across tools	Often a single BI session	Agent may call multiple services “on behalf of” a user	AI-specific
Safe ambiguity handling	Analyst asks a clarification	Agent needs explicit clarify/abstain behavior	AI-specific
Tool/action blast radius	Human manually moves from insight to action	Agent can potentially chain analysis into execution	AI-specific

OpenAI’s engineering report is unusually illustrative of the first half of the table: it cites similar-looking tables, many-to-many joins, missing filters, null handling, table lineage, pipeline logic, freshness and company-specific calculations as challenges that already exist in analytics; it then supplies those contexts explicitly to the agent. 3

The second half is genuinely different. Snowflake’s current evaluation tooling explicitly reruns natural-language questions against verified SQL/result sets and warns that repeated generations can differ even when the evaluation judge is pinned; its documentation recommends repeated evaluation to understand normal score variation. That is an operational requirement conventional BI queries do not have in the same form. 4

Likewise, authorization cannot become another piece of prompt context. PAR’s production architecture deliberately puts data isolation outside the LLM because probabilistic generation is not considered a deterministic policy enforcement mechanism. NIST Zero Trust guidance independently recommends granular resource-level authorization and policy enforcement rather than implicit trust. 1

Bottom line: AI does not magically make poor data poor. It makes implicit knowledge, nondeterminism, and automated propagation much more economically relevant.

Value and use-case evidence

Value and use-case map

Deliverable — Value / use-case map

There is a major evidence gap worth making explicit: the primary sources reviewed do not provide robust, independent evidence that investing in an enterprise semantic layer, catalog, ontology, or “agent-ready platform” produces a universal percentage improvement in business performance. The strongest direct evidence today consists of deployed data-agent reports, text-to-SQL benchmarks and provider engineering practices. Therefore, platform investment should be justified by a named use case and measured against that use case, not by generic claims about “unlocking AI.”

Potential value	Evidence status	Evidence / interpretation
Broader analytical self-service	Production evidence, provider/self-published	OpenAI reports use across Engineering, Data Science, GTM, Finance and Research and describes employees moving from questions to insights much faster; no controlled ROI estimate is provided. 3
Natural-language analytics for external users	Production evidence, provider/customer-published	PAR reports a deployed multi-tenant text-to-SQL system and >50,000 queries. This proves feasibility under a constrained architecture, not universal economics. 1
Reduced manual context gathering	Production mechanism	OpenAI explicitly retrieves schema, lineage, historical query patterns, annotations, code-derived context and institutional knowledge so the human does not gather all of it manually. 3
More capable internal assistants	Production + mechanism	OpenAI’s internal agent performs discovery, SQL generation and multi-step exploration over its data environment; Databricks likewise documents multi-query agent mode. 3
Faster operational decisions	Plausible; weak direct causal evidence	Faster analytical retrieval can shorten decision latency, but the reviewed primary sources do not establish a general business-outcome effect size.
AI-assisted data engineering	Adjacent empirical evidence	A 2026 randomized study across Microsoft, Accenture and a Fortune 100 company covering 4,867 software developers found a pooled 26.08% increase in completed tasks from an AI coding assistant. This is strong productivity evidence for software development, but not a measured effect of making enterprise data agent-ready. 5
Reusable organizational context	Production mechanism	OpenAI reports reusing annotations, code-derived meaning, institutional knowledge and saved corrections across future analyses. 3
Agentic business workflows	Plausible / case-dependent	Data access is a prerequisite for many workflows; the business outcome comes from the workflow, not the access layer itself.
Autonomous operational decisions	Speculative for generic enterprise use	The risk and control requirements change materially once the system can change state; analytics evidence should not be used to justify autonomous execution.

A particularly important counterweight to optimistic text-to-SQL demos is Spider 2.0. Its enterprise tasks involve databases that can contain more than a thousand columns and require schema understanding, metadata, dialect documentation, project code and often complex multi-query SQL. The benchmark’s sharp performance drop relative to older text-to-SQL benchmarks is evidence that “the LLM knows SQL” is not equivalent to “the LLM understands the enterprise.” 2

Different consumers require different readiness

Deliverable — Use-case differentiation

AI consumer	Primary job	Semantic requirement	Access requirement	Evaluation requirement	Recommended default boundary
Internal Q&A	Find factual answers	Low–medium; definitions for important terms	User-level read access	Citation/source correctness	Curated search/data tools
Conversational analytics	Answer KPI and slice/dice questions	High for KPIs, joins and time logic	Read-only curated analytical scope	Golden questions + expected results	Curated views + semantic definitions
AI analyst	Explore hypotheses, run multiple queries	Medium–high but needs more flexibility	Wider read-only domain	Multi-step correctness, provenance, cost	Read-only analytical workspace
Coding/data-engineering assistant	Understand/create pipelines and code	Code, schema, lineage more important than KPI layer	Repo + dev/test data; production tightly controlled	Code/test/build evaluation	Dev tools and non-prod environments
Customer-facing assistant	Answer a customer’s data questions	Narrow but extremely precise	Hard tenant/user isolation	Disclosure tests + answer correctness	Domain API or strongly isolated views
Workflow agent	Use data to prepare/propose business work	Domain-specific business state semantics	Read plus constrained tools	End-to-end workflow tests	Typed APIs/tools
Autonomous operational agent	Change business state	Very high for decision inputs and action semantics	Least-privilege write capabilities	Safety, rollback, policy, outcome monitoring	Transactional tools, never arbitrary warehouse write by default

Databricks’ documented analytical agent design is read-only even while it performs multi-step reasoning and multiple SQL queries. PAR similarly restricts model visibility to prefiltered analytical data. These are design signals that analytical autonomy and write autonomy need not—and should not automatically—be coupled. 6

Can one platform design safely support all seven? Shared primitives can: identity, authorization policy, audit logs, metadata, data products, freshness signals and evaluation infrastructure. The same interface and permission envelope should not. Customer-facing multi-tenant analytics and autonomous operational actions have materially different failure consequences from an internal analyst’s read-only exploratory session. PAR’s architecture demonstrates the former distinction; OAuth and Zero Trust standards likewise favor resource- and action-specific privileges rather than broad ambient authority. 7

Foundation, semantics, quality and metadata

The minimum platform foundation

Deliverable — Minimum platform foundation

For a bounded read-only AI analytics use case, the genuinely necessary foundation is smaller than “enterprise data maturity”:

• An identifiable trustworthy source set. The agent must know which tables/views/data products it may use, their grain and enough relationship information to avoid obvious analytical errors. Spider 2.0 and OpenAI’s production report both show that schema alone is frequently insufficient in real enterprise analysis. 2

• Deterministic authorization. Access must be enforced by the database/API/policy layer rather than requested from the model in natural language. PAR’s production design is direct evidence for this pattern; NIST Zero Trust is aligned with resource-specific policy enforcement. 1

• Definitions for the concepts that the use case actually asks about. Not every enterprise term needs modeling. Critical metrics, dimensions, time semantics, exceptional filters and permissible joins do.

• Visible freshness and known failure state. The AI should be able to distinguish “current and healthy” from “late, incomplete or unknown.” OpenAI specifically incorporates refresh/update information and can inspect live runtime state when stored context is stale. 3

• A named owner/escalation path. Someone must be able to decide whether an ambiguous definition or bad answer represents a data defect, semantic defect or agent defect.

• Traceability. The user/operator should be able to recover the source, generated query/tool calls and result underlying a material answer. OpenAI’s internal implementation links analyses to underlying results for verification. 3

• A known-case evaluation set. Both Snowflake and OpenAI describe question-to-expected-query/result evaluation as an ongoing regression control rather than a one-off launch test. 4

That is deliberately not a requirement for perfect enterprise-wide lineage, documentation of every table, a company ontology, 100% metadata coverage, or a single canonical definition for every disputed concept. Those may become justified later; requiring them before a contained pilot would make the experiment incapable of telling leadership which missing foundations actually matter.

Semantic-investment options

Deliverable — Semantic-investment options

Semantic investment should be matched to the type of ambiguity being removed.

Investment	Agent problem it solves	Ongoing maintenance	Strong trigger to invest	Weak justification
Business glossary	“What does ARR/churn/active/etc. mean?”	Low–medium	Terminology itself is disputed or opaque	Agent mostly uses technical operational fields
Metric definitions / metric store	Consistent numerator, denominator, filters, time windows	Medium	Repeated KPI questions across BI + AI consumers	Mostly open-ended detailed analysis
Semantic layer	Reusable entities, relationships, measures, dimensions, joins	Medium–high	Many questions repeatedly fail due to the same joins/metric logic	One narrow domain with a handful of stable SQL queries
Curated data products/views	Reduces raw schema search space and encodes grain/business logic	Medium	Existing analytics models are already trustworthy	Assumption that agents need a new abstraction simply because they are agents
Ontology	Formal vocabulary, entity types and relationships across heterogeneous domains	High	Cross-domain reasoning depends on explicit conceptual relationships	Basic KPI analytics
Knowledge graph	Traverse explicit entity relationships and attach heterogeneous context	High	Graph relations are themselves central to the use case	Conventional dimensional warehouse questions

Current product engineering supports the narrower interpretation of semantic value. Snowflake’s semantic-view evaluation explicitly uses natural-language questions paired with verified SQL as ground truth and measures generated results against them. Databricks documents the use of names, descriptions, relationships, SQL expressions, examples and verified/trusted query logic to improve analytical interpretation. These are provider-design evidence that explicit semantics are useful inputs, not evidence that every organization should purchase a separate semantic product. 4

A semantic layer earns its maintenance cost when the organization is repeatedly paying the same semantic tax: multiple agents, BI tools and analysts independently reconstruct identical metrics, joins and business rules. The reverse also holds. For twenty stable questions over five curated views, a semantic platform can easily be more machinery than the problem warrants.

A useful decision test is:

How many recurring agent failures would disappear if this semantic asset existed, and how many human-hours will it take every month to keep that asset correct?

Do not count theoretical reuse. Count observed failure classes.

Data quality and freshness investment

Deliverable — Data-quality / freshness investments

AI changes the exposure side of data-quality economics more reliably than it changes the underlying probability that source data is wrong.

A useful model is:

Expected defect cost ≈ defect probability × probability the AI consumes it × number of affected AI-mediated decisions/answers × consequence per affected use

An assistant that makes data accessible to ten times as many people or runs unattended analyses can increase the third term. It does not automatically make the source defect more likely. Therefore, “AI means we need to test every table” is poor economics; “AI increases the value of testing the small set of products it repeatedly consumes” is much more defensible.

Investment	AI-specific business case	Priority
Freshness monitoring	Lets the agent distinguish healthy current data from late pipelines before presenting an answer	High for time-sensitive use cases
Automated quality tests	Prevent known structural/logic defects from silently propagating through repeated automated consumption	High on exposed critical data
Schema/data contracts	Prevent upstream changes from invalidating machine assumptions without notice	High when many producers change independently
Anomaly detection	Helps with unknown data shifts, but false positives and triage create operational cost	Selective
Ownership	Makes detected failures resolvable rather than merely observable	Foundational
Enterprise-wide blanket testing	Adds cost regardless of whether AI consumes the asset	Low unless justified for other reasons

OpenAI’s internal system retrieves pipeline-derived information including update behavior, grain and construction logic, while Snowflake’s evaluation tooling treats regressions as something to detect continuously rather than assuming once-correct behavior remains correct. These support targeted observability around AI-consumed data, not blanket testing of the entire estate. 3

Metadata and catalog investment

Deliverable — Metadata / catalog investment

The highest-value metadata for an analytical agent is not necessarily the metadata that makes a catalog look complete.

Tier A — directly answer-affecting

Metadata	Why an agent needs it
Grain / uniqueness	Prevents duplicate counts and aggregation mistakes
Business meaning of table/field	Distinguishes technically similar datasets
Allowed/normal relationships and join keys	Reduces invalid joins
Metric formulas, filters and time semantics	Resolves business ambiguity
Caveats/exceptions	Prevents generic interpretation from overriding company-specific logic
Freshness/update state	Allows stale-data detection
Sensitivity/access classification	Helps route to the appropriate tool/data boundary

Tier B — discovery/debugging

Metadata	Primary value
Lineage	Explain construction; diagnose changes and downstream impact
Ownership	Escalation and maintenance
Usage/query history	Shows which tables and joins practitioners actually use
Examples / verified queries	Gives concrete interpretation of business questions
Pipeline/code links	Reveals transformations and assumptions not visible in schema

OpenAI’s deployed internal design uses almost exactly this mixture: schemas and lineage, query history, human descriptions and caveats, code-derived table meaning, refresh/granularity context, institutional knowledge and saved corrections. It explicitly states that schema/history alone do not capture all table meaning. 3

The significant caveat is metadata accuracy. A beautiful description that is six months wrong can be worse for an agent than no description because it creates machine-readable false confidence. Consequently, the economic unit should not be “percentage of columns documented.” Prefer measurements such as:

agent-exposed assets with current grain + owner + freshness + critical semantic definition, and
high-frequency questions covered by verified semantics/examples.

In the primary evidence reviewed, there is no convincing controlled enterprise study assigning a universal ROI to descriptions versus lineage versus tags versus usage history individually. Treat vendor claims of broad “metadata intelligence” as a hypothesis until your pilot attributes failures to missing metadata.

Access architecture, permissions and actions

AI access architecture options

Deliverable — AI access architecture options

The following ratings are decision guidance, not vendor performance measurements.

Access model	Flexibility	Governance / security	Implementation	Maintenance	Auditability	Best fit
Unrestricted warehouse query	Very high	Low	Low	Low initially	Medium	Expert sandbox
Curated warehouse role/views	High	High	Low–medium	Low–medium	High	Internal analytics default
Semantic API	Medium	High	Medium	Medium–high	High	Repeated KPI/conversational analytics
Domain-specific tools/API	Low–medium	Very high	Medium–high	Medium	Very high	Customer-facing/workflow/action
Preapproved queries/templates	Low	Very high	Low	Low	Very high	Small stable question set
Read-only data product	Medium–high	High	Medium	Medium	High	Domain analytics / portable boundary

The choice is fundamentally between letting the model decide more of the query surface and moving more decisions into deterministic software.

PAR is instructive: the LLM does not see raw underlying tenant tables. Server-side code first constructs the user’s authorized sandbox; the model sees only the resulting schema and generates analytical SQL within that boundary. Ambiguous questions are rejected or clarified before SQL generation. 1

Databricks illustrates another viable point in the design space: multi-step analytical behavior can still generate only read-only SQL. 6

This suggests a useful architecture principle:

Give the model freedom inside a boundary; do not ask the model to define the boundary.

Core platform versus AI access layer

Deliverable — Core platform versus AI access layer

Prefer an AI-facing layer over the existing core when:

• the warehouse/lakehouse already contains sufficiently reliable domain data;

• existing IAM or row/object policies are enforceable programmatically;

• most observed gaps are discovery, context, semantics, interface shape or AI evaluation;

• only one or a few domains are being exposed;

• the organization wants to retain BI and analyst workflows unchanged.

OpenAI describes its agent explicitly as an interface layer inheriting existing data permissions, while enriching context around the underlying platform. 3

Fix the core platform when:

• no trustworthy representation of business grain exists;

• the same KPI has irreconcilable implementations and nobody owns the resolution;

• source identifiers cannot support safe joins;

• permissions cannot deterministically express who may see which rows/entities;

• freshness/quality failure is widespread upstream rather than agent-specific;

• multi-tenant/customer isolation cannot be guaranteed without rebuilding data boundaries;

• every AI application must independently recreate identical correction logic.

That distinction prevents an architectural anti-pattern: hiding fundamentally broken data behind an increasingly elaborate agent layer.

A useful test is:

Remove the LLM. Would this defect still harm a new analyst, dashboard, API or downstream data product?

If yes, it is probably core data-platform debt. Fixing it only in the AI adapter creates another semantic silo.

Permission and governance model

Deliverable — Permission / governance model

Existing IAM can be sufficient—but only when the AI layer can faithfully propagate and enforce it.

OpenAI reports pass-through behavior in which users may query only tables they were already entitled to query; PAR demonstrates the harder multi-tenant case, where application identity is translated into deterministic row-level isolation before the model sees the data. These examples show two architectures rather than one universal IAM answer. 3

For user-initiated assistants: prefer delegated identity—“agent X acting on behalf of user Y”—over a shared highly privileged service principal wherever the underlying systems support it. OAuth 2.0 is specifically designed for limited delegated access, and RFC 8693 defines token-exchange semantics that can represent both the primary subject and the delegated actor. 8

For unattended agents: use a separately identifiable workload/agent identity with purpose-specific privileges. Current OAuth security best practice recommends restricting tokens to the minimum privileges required and, where possible, to particular resource servers, resources and actions. 9

For audit purposes, the useful event is therefore not merely:

service-account queried customer_table

but conceptually:

human/workload subject → AI actor → tool → operation → resource → authorization decision → result

MCP can standardize the tool connection and schemas around tools, but it does not eliminate the need for authorization policy or business semantics. Its specification treats arbitrary data access/tool execution as requiring explicit security, consent and privacy consideration, and its architecture separates hosts, clients and servers to preserve security boundaries. 10

For sensitive categories, the access decision should tighten:

Data class	Additional question before exposure
Employee data	Is every exposed field necessary for this use and permitted for this user/purpose?
Customer personal data	Is the purpose defined, minimization applied, retention understood, and output itself protected?
Financial data	Are definitions, close/status timing, approval boundaries and materiality known?
Confidential commercial data	Can sharing boundaries be expressed deterministically, including subsidiaries/teams/partners?
Multi-tenant/client data	Can another tenant’s rows be made structurally unavailable, not merely discouraged by instructions?

For organizations subject to GDPR, those choices interact with statutory principles including purpose limitation, data minimization and accuracy, and with data-protection-by-design and security obligations; introducing an AI interface does not waive those requirements. 11

The EU AI Act should not be treated as though every internal analytics assistant is automatically a “high-risk AI system.” Where a use case does fall into the Act’s high-risk regime, the current consolidated text includes requirements around logging and human oversight and obligations for deployers. The Regulation was amended in 2026, so decisions should use the consolidated July 27, 2026 text rather than relying on the original 2024 text alone. 12

The read-versus-action boundary

Deliverable — Read versus action boundary

Leadership should treat these as four different products:

Stage	Meaning	Additional controls required before advancing
Read	Fetch/analyze information	Data authorization, source trace, freshness, query/tool audit
Recommend	Interpret data and advise a person	Evidence, assumptions, uncertainty/ambiguity handling, human judgment
Propose action	Form a concrete change but do not execute it	Policy validation, target/delta preview, dry run, approver context
Execute action	Change business state	Action authorization, constrained transactional tool, approval/policy gate, idempotency, limits, recovery/compensation, kill switch, complete audit

The jump from read to execute is not an incremental version of conversational analytics. It changes the loss function.

For execution, the agent should normally receive a specific capability such as:

issue_refund(customer, transaction, amount <= authorized_limit)

rather than:

run arbitrary SQL UPDATE

That makes resource, action and scope explicit and aligns with IETF guidance to restrict delegated access by resource and action. 13

Before autonomous execution, leadership should demand answers to five operational questions:

Authorization: Who—not merely which model—is authorized to cause this exact change?

Approval: Which actions need a second human or deterministic policy decision?

Auditability: Can the organization reconstruct identity, evidence, model/tool request, policy decision and resulting state?

Recovery: Is the operation reversible, compensatable or safely retryable?

Blast radius: What caps the number/value/scope/rate of changes when the agent is wrong?

NIST’s AI RMF and Generative AI Profile emphasize lifecycle risk management and evaluation rather than treating deployment as an endpoint; NIST’s current metrology resources likewise frame field pilots, post-deployment feedback and continuous testing as part of trustworthy AI operation. 14

Operating model, portability and lifecycle economics

Organizational ownership

Deliverable — Ownership / operating model

Most responsibilities are extensions of existing roles. Two responsibilities become materially more prominent: agent/tool evaluation and AI-interface reliability.

Asset/control	Accountable owner	Key collaborators
Business metric definition	Business/domain owner	Analytics/data
Curated domain data product	Data/domain product owner	Data engineering
Data quality/freshness	Data-product owner	Producer teams/platform
Metadata/lineage infrastructure	Data platform	Domain owners
AI-facing descriptions/examples	Domain analytics/data product team	AI team
Authorization primitives	Security/IAM	Data platform
Data access policies	Business/data owner + security/privacy	Platform
Agent tools/APIs	Application/AI engineering	Domain system owners
Golden evaluation cases	Domain expert + AI/data team	Business users
Agent regression/monitoring	AI/application team	Data platform
Privacy/regulatory constraints	Privacy/legal/risk	Security/data/business
Incident response	Existing operational owner, extended to AI	AI + data + security

The bad operating model is to appoint an “AI data owner” who somehow becomes responsible for definitions that the actual business domain refuses to own. AI does not resolve organizational ambiguity; it can automate its consequences.

A useful separation is:

• Domain owns meaning.

• Data platform owns reliable representation and common infrastructure.

• Security owns enforceable authorization mechanisms.

• AI/application team owns agent behavior, tool selection and evaluations.

• Operational system owner owns write-side invariants.

OpenAI’s case reinforces the cross-functional nature of this problem: its agent consumes human annotations, platform metadata, code, institutional knowledge and permissions rather than creating a parallel authoritative definition system solely inside the model. 3

Lock-in and portability

Deliverable — Lock-in and portability

Not all “agent-ready” investment has equal portability.

Asset	Portability	Reason
Business definitions in plain specification/code	High	Meaning can be re-expressed across systems
SQL transformations/views	High–medium	Widely understood, but dialect/platform behavior varies
Golden questions + expected results	High	Can evaluate replacement models/platforms
Data-quality rules	Medium–high	Logic portable; syntax/integration may not be
OAuth identity/delegation model	High	IETF-standardized authorization framework. 8
MCP tool boundary	Medium–high	Open protocol reduces agent-framework coupling, but protocol compatibility/versioning still exists. 15
Vendor-specific semantic DSL	Medium–low	Business logic is recoverable but representation/runtime is proprietary
Vendor catalog IDs/tags/lineage conventions	Medium–low	Migration requires remapping
Vendor-specific trusted-query/memory constructs	Low–medium	Closely tied to runtime implementation
Raw prompts describing business rules	Low	Hard to test, govern and migrate reliably

The most important portability move is therefore architectural rather than contractual:

Keep canonical meaning and authorization policy upstream of the agent-specific adapter.

For example, “net revenue excludes refunds after settlement and uses invoice date” should not exist only in a proprietary agent prompt or vendor memory store. The vendor adapter may translate that rule into its semantic representation, but the company should retain an authoritative, testable version elsewhere.

MCP deserves similar restraint. It is useful because it standardizes how AI clients discover/use external tools and context, but it is not a portable enterprise semantic layer and it does not automatically make authorization portable. Those are separate problems. 10

Lifecycle cost

Deliverable — Lifecycle cost

The correct economic comparison is not:

AI platform license versus no AI platform license.

It is:

Incremental lifetime cost of the controls required for the target use case versus measured lifetime value of enabling that use case.

A lifecycle cost model should include:

Cost bucket	Typical driver
Platform/software	Catalog, semantic, agent, observability or API products
Engineering	Integration, context retrieval, policy enforcement, tooling
Semantic modeling	Number of governed entities/metrics/relationships and rate of change
Metadata maintenance	Number of exposed assets × change frequency × required human curation
Catalog maintenance	Scanning, ownership, lineage mapping, taxonomy/classification
Data quality	Tests, monitors, triage and defect remediation
IAM	Identity propagation, role/policy engineering, access reviews
API/tool layer	Tool contracts, validation, versioning, transactional safety
Evaluation	Golden-set creation, adjudication, repeated model/query execution
Monitoring	Logs, anomaly detection, security, latency/cost tracking
Support	User questions, bad-answer triage, domain-owner time
Compute/model usage	LLM/tool calls, warehouse scans, retries and evaluations

Evaluation is a real recurring workload, not free hygiene. Snowflake’s current documentation notes that semantic evaluation incurs warehouse execution, judge-inference and storage costs and that nondeterministic SQL generation makes repeated runs useful for interpreting score variation. 4

The semantic-maintenance cost is likewise easy to underestimate. A definition is an operational dependency once an AI answer relies on it: changes to business rules, product taxonomy, account hierarchy or fiscal logic must make their way into both data and agent context.

Leadership should require unit economics such as:

Cost per successful trusted task

[ \frac{\text{platform + compute + engineering + curation + evaluation + support}}{\text{correct useful AI-mediated tasks}} ]

Maintenance intensity

[ \frac{\text{human hours spent maintaining semantics/metadata/evals}}{\text{active domain or governed metrics}} ]

Avoided labor

[ (\text{baseline analyst/user minutes} - \text{AI-assisted minutes}) \times \text{successful task volume} ]

Expected risk reduction

[ (\text{baseline defect/exposure probability} - \text{controlled probability}) \times \text{loss exposure} ]

None of these should be assigned a universal multiplier. Measure them in the pilot.

Observable readiness and bounded experimentation

Readiness without a readiness score

Deliverable — Observable readiness questions

Do not average these into “73% AI-ready.” A security failure and a missing column description are not commensurable.

Data and semantics

• Can we name the authoritative data assets for this use case?

• Is their grain known?

• Are critical join relationships known?

• Are the key metrics and dimensions defined?

• Are materially different definitions surfaced rather than silently collapsed?

• Are exceptions and exclusion rules explicit?

• Can the agent determine the relevant time zone, business calendar and time window?

• Is current freshness visible?

• Can the system recognize a failed or degraded data source?

Permissions

• Is authorization deterministic outside the model?

• Can the agent obtain no more data than its human/workload subject is entitled to?

• For customer/multi-tenant data, can another tenant’s data be structurally excluded?

• Is the actor and represented user/workload separately auditable?

• Can privileges be revoked without changing prompts or redeploying a model?

• Are tokens/credentials constrained by resource and action where technically feasible? Current OAuth security guidance recommends minimum necessary privilege and audience/resource restrictions. 13

Correctness and behavior

• Can a correct answer be traced to the executed query/tool result?

• Does the agent clarify materially ambiguous questions?

• Does it abstain or redirect unsupported questions?

• Can it identify when the requested concept has no governed definition?

• Does it distinguish “no rows” from “no access”?

• Are known questions represented as regression cases?

• Are generated results tested against known outcomes rather than only checking SQL syntax?

• Are tests repeated enough to expose nondeterministic regressions? Snowflake and OpenAI both use curated expected queries/results as regression evidence. 4

Operations

• Is there an owner for each exposed data product?

• Is there an owner for each critical business definition?

• Can a user report a bad answer and can the organization triage whether it was a data, semantic, access or agent failure?

• Are model/tool/version changes evaluated before broad deployment?

• Is query/model cost attributable to a use case?

• Is there an incident path for inappropriate disclosure?

Actions, where relevant

• Is every write action exposed through an explicitly authorized operation?

• Can the system preview the exact state change?

• Is the operation idempotent or safely retryable?

• Is recovery/compensation defined?

• Is there a hard limit on value, count, scope or rate?

• Can action capability be disabled immediately?

Bounded pilot design

Deliverable — Pilot design

A good first experiment is one domain, one AI consumer, read-only.

Example: internal sales conversational analytics.

Scope

Use the existing warehouse/lakehouse. Expose only a curated sales role/data product comprising the small set of customer/account/opportunity/order facts needed for the experiment. Add explicit definitions only for the metrics the pilot asks about. Do not build enterprise ontology, replace the catalog or remodel unrelated domains.

Consumer

A defined internal sales/revenue-operations user group asking natural-language analytical questions.

Interface

Read-only queries through the existing warehouse, curated role/views or existing semantic interface. Preserve user identity where feasible. Log source selection, generated SQL/tool calls, results and answer.

Suggested evaluation corpus

This is a proposed test design, not an industry standard:

Test family	Example
Known questions	“What was EMEA new ARR last quarter?”
Multi-step questions	“Which segments drove the change, and which accounts explain most of it?”
Ambiguous questions	“How is revenue doing?”
Conflicting definitions	“Customers” where account/customer/company have different meanings
Invalid questions	Request a metric the domain does not contain
Join traps	Fact-to-fact or historical dimension edge case
Stale data	Sales snapshot deliberately delayed
Pipeline degradation	Critical source marked failed
Permission denial	User asks for restricted compensation/customer-level field
Revoked permission	Access removed after previous successful use
Changed definition	Modify an approved KPI rule and test propagation
Prompt attack	Ask the agent to ignore access policy or reveal hidden schema
Empty result	Distinguish genuine zero from an error/access denial

PAR’s system explicitly clarifies ambiguous/unsupported metrics before SQL generation; Snowflake and OpenAI both maintain curated question/expected-result evaluations. These production/provider patterns strongly support including ambiguity and regression cases rather than evaluating only happy-path SQL generation. 1

Pilot outcome measures

Do not lead with “users liked it.” Track:

• result correctness against trusted outputs;

• clarification accuracy for ambiguous questions;

• appropriate refusal/abstention for unsupported questions;

• authorization test pass rate, with any unauthorized disclosure treated as a release-blocking incident;

• stale/degraded-data recognition;

• traceability completeness;

• human task-completion time, measured against the actual current workflow;

• number of analyst escalations avoided versus generated;

• warehouse/model cost per successful task;

• maintenance hours spent adding definitions, examples and corrections;

• failure attribution: data, semantic, metadata, access, model reasoning, tool, or UX.

The most valuable pilot artifact is not the chatbot. It is the failure distribution.

If 60% of wrong answers come from five undefined metrics, invest in semantics.
If they come from stale source tables, invest in quality/freshness.
If they come from schema search across 10,000 irrelevant objects, improve metadata/retrieval or reduce scope.
If permissions cannot be represented safely, redesign access.
If users mostly ask ten fixed questions, stop engineering a general AI analyst.

Scale, redesign and stop conditions

Deliverable — Scale / redesign / stop conditions

Scale the current design when:

• a bounded user group repeatedly completes valuable tasks;

• known-question correctness is stable enough for the consequence of the use case;

• ambiguity is handled through clarification/abstention rather than silent invention;

• authorization tests show deterministic boundary enforcement;

• new questions mostly require adding ordinary domain knowledge, not architectural exceptions;

• maintenance/support cost stays below measured user/business value;

• a second domain can adopt the pattern primarily through configuration and domain modeling rather than a bespoke rewrite.

Invest further in semantics when:

• the same metric/join/business-definition failures recur across users and AI tools;

• corrections are duplicated in prompts, dashboards and agents;

• domain owners repeatedly adjudicate definitions at query time;

• verified questions demonstrate that explicit semantic modeling fixes a substantial share of failures.

Invest further in metadata/catalog when:

• the system frequently selects the wrong existing asset;

• users/agents cannot distinguish similarly shaped datasets;

• failures are attributable to unknown grain, lineage, ownership or freshness;

• discovery cost dominates analytical reasoning.

Redesign upstream/core data products when:

• contradictions exist before the AI layer;

• identifiers/grain/relationships are structurally unreliable;

• freshness and data quality cannot be monitored at source;

• authorization cannot be enforced without reproducing data into ad hoc AI silos;

• multiple non-AI consumers exhibit the same failures.

Redesign the access architecture when:

• customer/tenant boundaries rely on model obedience;

• agent credentials are broader than user/workload purpose;

• audit cannot reconstruct who accessed what;

• a customer-facing agent exposes raw warehouse discoverability that has no product reason to exist.

Stop—or replace AI with conventional software—when:

• users mostly ask a small stable set of questions;

• a dashboard, search interface or parameterized query gives faster and more trustworthy results;

• task frequency is too low to pay for semantic/evaluation/support overhead;

• the agent creates as many analyst escalations as it removes;

• the business cannot specify what a correct answer means;

• write-side recovery or blast-radius controls cannot be made proportionate to the value of autonomous execution.

Executive diligence questions and decision reversals

Questions a CTO or Head of Data should answer before material investment

Deliverable — Questions a CTO / Head of Data should answer

The business decision

• What user task becomes materially better if AI consumes company data directly?

• What is the current cost/time/error rate of that task?

• Is the desired capability retrieval, analytics, recommendation, or execution?

• What is the consequence of a wrong answer, unauthorized answer or stale answer?

• What evidence would cause us to decide that ordinary BI/search/software is better?

Scope

• Which domain is actually required?

• How many datasets and metrics account for most expected usage?

• Do users need arbitrary SQL flexibility or a bounded set of business operations?

• Is this internal, employee-facing, customer-facing or multi-tenant?

• Does the system need individual row-level data, or would aggregates suffice?

Existing platform

• Which failure modes already affect human analysts?

• Are the authoritative sources actually known?

• Are important joins, grain and exclusions encoded anywhere other than people’s heads?

• Can the existing warehouse/lakehouse expose a safe curated role or view?

• Can current IAM be propagated into the AI request deterministically?

• Can we obtain freshness/health state without building a new catalog?

Semantic investment

• Which specific questions fail today because a metric or relationship is ambiguous?

• Would governed SQL/views or a small metric definition set solve those failures before we buy/build a universal semantic layer?

• How frequently do definitions change, and who will maintain them?

• Is cross-domain entity reasoning actually required strongly enough to justify ontology/knowledge-graph maintenance?

Security and governance

• Is policy enforced outside the model?

• Can the agent be identified separately from the person/workload it represents?

• Can access be revoked immediately?

• Can we guarantee client/tenant isolation structurally?

• What data reaches the model provider or agent runtime?

• What logs exist for source access, generated query, tool calls and actions?

Operations

• Who decides that an AI answer is wrong?

• How do they determine whether the cause is data, semantics, permissions or model behavior?

• What regression set protects the important questions?

• How much domain-expert time per month will semantics and evaluation consume?

Economics

• What use-case value must be achieved for the incremental platform expense to pay back?

• What is cost per successful trusted task?

• Which proposed platform components remain useful even if this particular model or agent product is replaced?

• What is the cheapest reversible experiment that can falsify our assumptions?

Actions

• Why does the agent need write permission at all?

• Can recommendation/proposal capture most of the value?

• What exact operations would be exposed as tools?

• What is the largest possible erroneous transaction/batch/change?

• Can it be recovered?

• Who carries liability when the system acts correctly according to its tool permissions but the business outcome is wrong?

Decision reversals

Deliverable — Decision reversals: when the simpler conventional platform plus narrow AI interface wins

These cases should actively reverse a proposal for broad “agent-ready” transformation.

Situation	Prefer	Why
Users ask twenty stable KPI questions	Existing warehouse + governed queries/metric endpoint + thin NL interface	General-purpose semantic discovery adds little value
Strong curated marts already exist	Read-only AI over those marts	Do not recreate semantic logic simply because the consumer is an LLM
Customer-facing multi-tenant analytics	Domain API or isolated authorized views	Control and tenant isolation dominate arbitrary flexibility; PAR’s production design follows this principle. 1
High-risk financial/HR decision support	Narrow data products + recommend/propose mode	Preserves human decision boundary and limits data/action surface
Sparse usage	Manual analyst support or conventional BI	Ongoing semantic/eval infrastructure may cost more than saved labor
Data definitions are politically unresolved	Fix ownership/definition first	No semantic technology can determine which disputed business policy leadership intends
Most failures are stale/broken pipelines	Invest in core quality/freshness	AI-facing metadata cannot make incorrect source data correct
Data is reliable but discovery is poor	Improve focused descriptions/retrieval	Core warehouse redesign is unnecessary
Definitions are stable but access is sensitive	Curated roles/views + delegated identity	IAM boundary has higher marginal value than semantic richness
Agent only needs three business actions	Typed domain tools	A general warehouse interface increases unnecessary attack and error surface
Existing BI already answers the job well	Keep BI; add AI only for explanation/navigation if useful	“Conversational” is not intrinsically higher value than a deterministic dashboard
Organization cannot operate regression tests or investigate bad answers	Delay broad exposure	AI consumption creates a system whose behavior cannot otherwise be reliably governed; current production designs emphasize continuous evaluations. 4

The general reversal rule is:

Use the narrowest interface that preserves the business value. Expand flexibility only when users demonstrably need it.

That principle is supported both by PAR’s progression from unconstrained text-to-SQL toward constrained data sandboxes and by OpenAI’s report that excessive tool overlap confused its internal agent, leading it to consolidate and restrict tools. 1

Primary-source evidence register

Claim-to-primary-source table

Deliverable — Claim-to-primary-source table

Decision-relevant claim	Primary source	Evidence class	What it establishes	Important limitation
Real enterprise text-to-SQL is substantially harder than simplified benchmarks	Spider 2.0, Lei et al. 2	Empirical benchmark	Enterprise workflows require large-schema navigation, metadata/docs/code context and complex SQL	Benchmark ≠ business production outcome
A direct LLM→warehouse design can be analytically promising yet unacceptable for multi-tenant security	PAR Technology / AWS engineering report 1	Production, self-reported	PAR replaced its initial model-only access approach with deterministic layered controls	Vendor-hosted case study, not independent audit
Deterministic data boundaries can be placed outside the LLM	PAR/AWS 1	Production architecture	User identity creates a prefiltered sandbox before model-generated analytics	Specific to PAR’s architecture
PAR reports >50,000 production queries with zero cross-tenant exposure incidents	PAR/AWS 1	Production metric, self-reported	Evidence that constrained architecture can operate at meaningful volume	“Zero incidents” is company-reported
A data agent can be an interface layer over an existing platform/security model	OpenAI internal data-agent engineering report 3	Production, self-reported	Pass-through permissions and existing platform can be retained	OpenAI’s environment may not generalize
Rich context used in production extends beyond schema descriptions	OpenAI 3	Production design	Lineage, query history, annotations, code, institutional knowledge, memory and runtime state are used	Does not causally quantify each field’s marginal effect
AI analytical systems benefit from curated regression questions/results	OpenAI 3	Production design	Expected SQL/results are continuously tested	No public external performance dataset
Semantic views can be evaluated against verified natural-language/SQL pairs	Snowflake documentation 4	Provider design	Explicit ground truth and regression tracking are built into production tooling	Product documentation, not neutral outcome evidence
Natural-language→SQL generation remains nondeterministic under repeated evaluation	Snowflake documentation 4	Provider design	Same evaluation can generate different SQL; repeated tests are advised	Product-specific implementation
Complex analytical agents can remain read-only	Databricks Genie documentation 6	Provider design	Multi-step analytical reasoning does not require writes	Does not prove read-only is sufficient for every use case
Model prompts should not be treated as the authorization boundary	PAR/AWS + NIST Zero Trust 1	Production + normative	Deterministic policy enforcement should surround model behavior	Exact implementation remains organization-specific
OAuth supports limited delegated access on behalf of a resource owner	RFC 6749 8	Standards	Standards-based delegated authorization model	Application authorization logic still required
Subject and delegated actor can be represented separately in token exchange	RFC 8693 16	Standards	Technical basis for user/agent identity propagation	Support varies by IAM stack
Access tokens should be restricted to minimum necessary privilege/resources/actions	RFC 9700 13	Best Current Practice	Supports purpose-limited agent credentials	HTTP/OAuth scope; does not define enterprise data semantics
MCP standardizes connections/tools but has explicit security and consent concerns	MCP specification 10	Protocol specification	Useful portable tool/interface boundary	Does not standardize business semantics or solve IAM
GDPR principles remain relevant to AI-mediated personal-data access	Regulation EU 2016/679 11	Law	Purpose/minimization/security obligations remain attached to processing	Applicability depends on processing context
High-risk AI systems under EU law have logging/human-oversight/deployer obligations	Consolidated EU AI Act, July 27 2026 12	Law	Risk class matters for system governance	Most ordinary analytics assistants are not automatically high-risk
AI coding assistance can generate measurable productivity gains, but effects are task/context specific	Demirer et al., Management Science, 2026 5	Randomized field experiments	4,867 developers; pooled 26.08% increase in completed tasks	Adjacent software-engineering evidence, not agent-ready-data ROI
AI risk should be evaluated throughout use/deployment, not only before launch	NIST AI RMF / GenAI Profile 14	Normative	Lifecycle evaluation and risk management are expected practices	Voluntary framework, not performance evidence

Evidence-based decision synthesis

The evidence supports five relatively strong conclusions.

First: do not turn data-platform modernization into a prerequisite for experimentation. Production examples show that useful AI analytics can be layered on top of existing warehouses and security systems. 3

Second: do not equate that with “just give the LLM warehouse credentials.” Real enterprise analytics requires context that humans currently supply implicitly, and sensitive access requires deterministic boundaries outside the model. 2

Third: semantic investment should follow observed semantic failure. Governed metrics, semantic layers and curated products have a clear mechanism for improving repeated KPI and join interpretation, and current provider systems explicitly use such information. The evidence reviewed does not justify an enterprise ontology or universal semantic platform simply because agents exist. 4

Fourth: evaluation becomes part of the data interface. When natural language and model reasoning sit between the user and SQL/tools, correctness is no longer characterized only by pipeline tests. Known business questions, ambiguity cases, access denial and regression behavior need to be tested at the agent level. 3

Fifth: the read/action boundary is more consequential than the model choice. Analytical agents can remain read-only while performing sophisticated multi-step analysis; execution introduces authorization, recovery and blast-radius requirements that belong to operational systems and security architecture, not to prompt engineering. 6

The resulting investment rule is intentionally conservative:

Fund the smallest set of improvements that makes one valuable AI consumer trustworthy in one domain. Instrument the failures. Then invest in the layer where those failures originate.

That can legitimately result in a new semantic layer, stronger contracts, better metadata, an AI access service, or core-platform redesign. It can equally legitimately result in none of them—because a curated warehouse role, five governed metrics and a narrow read-only tool may be all the use case actually needs.