# 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. fileciteturn0file0

## 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. citeturn19search0turn19search3turn19search4

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. citeturn14view0turn15view0

**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. citeturn16view0turn16view4turn15view3

**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. citeturn19search7turn20view0turn20view1

**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. citeturn18view0turn17view0turn18view1turn18view2turn18view3

**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. citeturn20view0turn20view1turn17view6

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**. citeturn14view0turn0search1

## 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. citeturn13search0turn13search3 |
| **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. citeturn9search4turn10search0 |
| **Metric layer** | Narrower semantic abstraction | No | Centralizes metric definitions, aggregation and dimensional behavior; useful where NL questions must map to governed metrics. citeturn10search0 |
| **Business glossary** | Metadata/governance discipline | No | Gives terms explicit definitions and aliases; conversational products now inject them into model context. citeturn16view0 |
| **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. citeturn20view3turn20view4 |
| **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. citeturn18view5turn19search0 |
| **Data product** | Product/ownership boundary | No | The product concept remains; agent support becomes another consumer requirement. ODPS has similarly added optional agent-facing context. citeturn19search1 |
| **Catalog** | Discovery/metadata infrastructure | No | DCAT formalizes machine-interoperable discovery of datasets and services; being discoverable does not make meaning unambiguous. citeturn20view2 |
| **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. citeturn13search3 |
| **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. citeturn15view5turn17view0 |

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. citeturn15view4

### 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. citeturn14view0turn15view0turn15view1 Current production designs consequently inject metadata, verified examples and instructions and, in some cases, add separate SQL-validation steps. citeturn15view3turn16view0

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. citeturn14view0turn15view3 |
| **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. citeturn16view0turn9search4 |
| **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. citeturn20view3turn19search3 |
| **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. citeturn20view0turn19search7 |
| **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. citeturn18view5turn19search6 |
| **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. citeturn16view0turn11search4turn15view3turn19search0 |
| **Policy / authority** | row/column policy, tenant boundary, allowed operations, purpose constraints | Essential | Determines what may be accessed or changed independently of model preference. citeturn20view6turn20view7turn17view0 |
| **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. citeturn20view1turn20view0 |

**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. citeturn20view3turn20view4

**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. citeturn16view0turn11search4

```mermaid
flowchart LR
    Q[Question or task] --> R[Scoped discovery]
    R --> C[Context assembly]
    C --> P[Deterministic policy and authorization]
    P --> T[Typed tool / semantic query / SQL]
    T --> D[(Data platform)]
    D --> V[Validate semantics, freshness and quality]
    V --> A[Answer or proposed action]
    A --> W{Durable write?}
    W -- No --> E[Evidence / provenance]
    W -- Yes --> G[Write gate: validation, authority, idempotency / approval]
    G --> E
    E --> O[Observability and audit]
```

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. citeturn14view0turn15view3turn16view0

**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. citeturn15view0turn16view2

**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. citeturn18view5turn15view1

**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. citeturn15view4 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. citeturn16view1

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. citeturn19search7 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. citeturn20view0turn18view5

### 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. citeturn20view0

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. citeturn20view0turn20view1 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. citeturn18view5turn19search6 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.” citeturn15view0

### 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. citeturn19search0turn19search3 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. citeturn15view1 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. citeturn15view5

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. citeturn17view0

### 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. citeturn14view0turn0search1

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. citeturn16view2turn15view3 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. citeturn18view2turn18view3

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. citeturn20view6turn20view7

**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. citeturn18view0

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. citeturn20view5turn17view0

**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. citeturn15view3 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. citeturn18view2turn18view3

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. citeturn20view1turn20view0 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. citeturn20view1turn20view0turn17view6

### 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. citeturn20view2

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. citeturn14view0turn8search1turn8search4

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. citeturn16view2

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. citeturn14view0turn16view2

### 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. citeturn19search1turn19search2 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. citeturn17view6turn18view4

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. citeturn18view3turn17view6

### 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. citeturn18view1 |
| **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. citeturn18view2 |
| **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. citeturn17view0 |
| **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. citeturn17view0turn20view5 |
| **Tool-input/code execution abuse** | Old injection/sandbox problem amplified | generated input escapes intended operation | schemas + validation + sandbox + low privilege. citeturn18view3 |
| **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. citeturn17view0 |
| **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. citeturn18view1turn18view3 NIST's February 2026 work likewise identifies agent identification, authorization, auditing, non-repudiation and prompt-injection controls as open standards/practice concerns. citeturn18view0

### 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. citeturn18view5turn17view0turn20view5turn20view6

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. citeturn15view0 | **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. citeturn15view1 | 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. citeturn11search4 | 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. citeturn14view0turn0academia29 | AI-specific scaling issue |
| Conflicting agent instructions | multiple domains encode different defaults | model reconciles instead of failing deterministically | scope agents/context by domain. citeturn16view2 | AI-specific |
| Prompt injection in catalog/data | untrusted string interpreted as command | data becomes part of instruction surface | context isolation, least privilege. citeturn18view1 | **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. citeturn17view0 | 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. citeturn9search4turn10search0 | Text-to-SQL agents can operate directly over databases and metadata; no empirical paper establishes a semantic layer as necessary. citeturn14view0 | **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. citeturn14view0 | Spider 2.0 systems improved rapidly after the original paper; flexible SQL remains useful for novel analysis. citeturn0search1 | 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. citeturn16view0turn15view3 | Large schemas create long-context/schema-linking difficulty; context-compression research specifically treats representation size as a bottleneck. citeturn14view0turn0academia29 | **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. citeturn16view2turn11search4 | Snowflake warns incorrect verified queries can harm performance/accuracy. citeturn11search4 | 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. citeturn15view4 | Representation without enforced constraints is insufficient. |
| **“Enterprise-wide discovery is desirable.”** | DCAT and catalogs are explicitly designed to improve cross-catalog discoverability. citeturn20view2 | Google's agent guidance warns broad scopes can cause ambiguity/conflicting definitions. citeturn16view2 | 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. citeturn15view5 | MCP security guidance still requires authorization controls; the protocol does not define company metrics, quality or authoritative sources. citeturn17view0 | 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. citeturn16view1 | Quality rules, SLAs and contracts long predate agent consumers. citeturn19search7turn18view5 | Mostly an **exposure/timing change**, not new quality dimensions. |
| **“Humans should approve agent actions.”** | Security guidance recommends confirmation for irreversible/high-impact actions. citeturn18view2turn18view1 | 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** citeturn14view0 | 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** citeturn15view0 | 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** citeturn15view1 | 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** citeturn16view0 | 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** citeturn16view2 | 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** citeturn15view4 | 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** citeturn19search0turn19search3 | 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** citeturn19search7 | 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** citeturn20view0 | 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** citeturn20view1 | 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** citeturn20view2 | 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** citeturn15view5 | 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** citeturn17view0 | 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** citeturn18view0 | 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** citeturn18view1 | 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** citeturn18view3 | 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** citeturn20view5turn17view0 | 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** citeturn20view6turn20view7 | 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** citeturn17view6 | 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** citeturn13search0turn13search3turn19search0 | 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. citeturn14view0turn0academia29 |
| **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. citeturn15view0 |
| **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. citeturn18view2 |

### 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. citeturn14view0turn15view1turn15view0

**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.” citeturn19search0turn19search7turn20view0

**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. citeturn20view1

**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. citeturn18view0turn17view0

**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. citeturn18view1

**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. citeturn15view1

**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. citeturn18view2turn18view3

**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.