The AI agent checked the table. Did every result describe the same state?

Why agent data tools need exact table identity, bounded coverage, and honest incomplete results beyond a successful tool call.

An AI agent reports:

Table state: Delta version 1183
Schema check: Pass
Active files: 247 present
Release rule: Pass

The tool calls completed without an error. Can another agent rely on this result?

Suppose the table advanced from version 1182 to 1183 while the checks were running. The timeline call observed version 1183. The schema call used metadata cached from version 1182. The file check resolved the current table but did not return a version at all.

Every line may be accurate on its own. Together, they describe no real table state.

The values in this example are fictional. The failure shape is not. A mutable dataset can change between calls, retries, cache reads, and handoffs between agents. Once several valid observations are combined, the result can become a claim that none of the tools actually proved.

Transport is not evidence semantics

The July 2026 release of the Model Context Protocol
made its core stateless and each request self-describing. MCP gives clients and servers a common way to discover and call tools. The Agent2Agent protocol
defines communication between independent agent systems.

These protocols solve real connection problems. They do not define the domain meaning of every tool result.

An MCP tool can return a valid JSON object called schema_check. An A2A agent can send that object to another agent. Neither fact tells the receiver whether the schema and file checks observed the same table state, whether a read limit stopped the inspection, or whether an unsupported delete feature was ignored.

Protocol success answers, "Did the message arrive and satisfy the wire contract?" Data evidence answers, "What can this result prove?"

Data formats already give us stable states

The data layer has useful identities that an evidence contract can reuse.

The Delta Transaction Log Protocol defines a serial history of atomic table versions. A snapshot at a version contains the table metadata and the set of files that belong to that state.

The Apache Iceberg specification
defines snapshots, manifest lists, manifests, data files, and delete files. A snapshot identifies the table state used to plan a scan.

Those identities are stronger than latest, a wall-clock time, or an object storage prefix. They let an agent say which state it observed even after the table changes again.

Other data sources have equivalent anchors: an object version, a content digest, a database transaction identifier, or a catalog reference resolved to an immutable state. A useful agent contract should preserve the native identity instead of inventing a weaker one.

The surrounding standards cover different parts

OpenLineage models jobs, runs, and datasets. Its dataset facets can carry a dataset version, while its data quality assertions facet records test outcomes and optional expected and observed values.

W3C PROV provides a general model for entities, activities, agents, and derivations. It is a foundation for describing where an artifact came from and which activity produced it.

The OpenTelemetry semantic conventions for GenAI agents are developing shared names for agent invocations, plans, workflows, and tool execution spans. That work helps operators observe how an agent ran.

Newer proposals are also exploring cryptographically verifiable agent
evidence. For example,
Proof of Insight describes a content-addressed, signed graph for observation, deterministic computation, model reasoning, and attestation. Its current specification labels itself a working draft rather than a published standard.

These specifications overlap, but they do not require the same data-evidence boundary.

In the specifications above, I have not found a widely adopted profile that requires a data-check result to bind all of the following:

Part	Question it answers
Subject and state	Which exact dataset state was observed?
Question or rule	What was the check trying to establish?
Scope and coverage	Which metadata, files, partitions, samples, or rows were read?
Capability	Which table features and delete semantics did the reader understand?
Outcome	Did the rule pass, warn, fail, or remain incomplete?
Limitations and provenance	What stopped the check, and how can another system reproduce or challenge it?

OpenLineage can represent several of these facts. PROV can express their provenance. MCP or A2A can carry them. The missing piece is a small semantic profile that says which facts are required for an agent-facing data verification result and how they remain bound to one observation.

A profile is a better starting point than a new transport

Creating another RPC or messaging protocol would duplicate work. The same evidence should be able to travel through MCP, A2A, a command-line process, an event stream, or a saved file.

The standardizable part is the meaning of the result.

An illustrative envelope might express this shape:

subject:
  format: delta
  state: 1183
question: schema_compatibility
coverage:
  metadata: complete
  rows: not_read
outcome: incomplete
limitations:
  - active_file_check_observed_a_different_state

This is not a proposed wire schema. It only shows the separation between table identity, the question, observed coverage, outcome, and limitation.

A practical profile would need stronger rules:

1. A mutable source must resolve to an exact state, or the result remains incomplete.
2. Observations from incompatible states cannot be merged under one verdict.
3. Transport completion and evidence outcome use separate status fields.
4. Successful sections remain available when another section is incomplete.
5. Unsupported table features and exhausted read limits appear in the result.
6. The shareable form excludes credentials, signed URLs, private locations, raw rows, and hidden model reasoning.
7. A policy decision remains separate from the observations it evaluates.

The seventh rule matters when an agent participates in a release workflow. A schema comparison can prove that one field changed. It cannot decide whether the change is allowed until it receives an explicit compatibility or release rule.

Bounded reads need an honest result

Agents make repeated work cheap to request. They do not make remote metadata, object listings, or full scans free.

A data tool needs budgets for time, bytes, objects, metadata entries, rows, and retries. When a budget ends the operation, the result should preserve what was observed and mark the unsupported conclusion as Incomplete.

Retrying silently can make the evidence worse. The next request may observe a new table state and fill the missing section with facts from a different snapshot. A clean-looking report then hides the boundary that mattered most.

An incomplete result can still be useful:

State identity: Verified at Iceberg snapshot 711
Schema check: Pass over snapshot metadata
Delete check: Incomplete after the manifest-read limit
Row impact: Not checked

Another agent can reuse the state and schema evidence, request a larger delete budget with approval, or send the result to a person. It does not need to discard the whole operation or pretend the missing premise passed.

A standard should earn its name

Publishing a JSON Schema is easy. Establishing a useful standard requires independent use.

A credible path would start with one narrow profile for read-only observations of versioned analytical data. It would include mappings to MCP tool results, A2A artifacts, OpenLineage facets, and PROV records. A public conformance set would cover state changes during inspection, unsupported delete semantics, bounded reads, redaction, and incompatible evidence binding.

The profile would become more convincing when two unrelated implementations can exchange the same result and reject the same invalid combinations. Open governance, versioning rules, and a compatibility policy should follow before anyone calls it an industry standard.

That suggests a modest first step: publish a data-evidence profile draft, its mappings, and failure cases. Ask data tool builders, lineage projects, and agent framework authors where it conflicts with their existing models. Change the draft before giving it a brand.

A BigdataSight development note

In our post-1.0 research, we are exploring how local agents can request bounded, read-only checks of Delta and Iceberg tables and receive compact evidence without source locations, credentials, schema bodies, or row values.

The recurring constraint is that observations must stay attached to the state that produced them. Speed matters only when the observations describe the same state. Interoperability matters only when the next agent can see their coverage and limitations.

We are treating MCP and other transports as adapters around stable data semantics. Product truth stays in the data contract. The broader idea of an open data-evidence profile is research. It is not a shipping BigdataSight 1.0 capability, a published specification, or a delivery commitment.

One question for data and agent engineers

If an AI agent returns a data verification result, which missing fact makes the result hardest to trust?

1. The exact table version, snapshot, or object identity
2. The metadata, files, partitions, samples, or rows it covered
3. Unsupported features or delete semantics
4. The expectation or release rule used for the verdict
5. A reproducible provenance or evidence reference
6. Something else

A one-number comment is enough, and important to us.😊

Disclosure: We build BigdataSight, a native Mac data workstation. This article describes a post-1.0 research direction, not a shipping 1.0 capability, public protocol, or release commitment.

AI-assistance disclosure: I used an AI coding assistant to help research and edit this article. I reviewed the final argument and the linked specifications before publishing.