Enterprise Data Estate Readiness for Agentic AI: Five Questions + Three Diagnostics

See also (wiki): wiki/data-readiness.md · wiki/agentic-ai-governance.md · wiki/local-tiny-models.md · wiki/ai-implementation-cost-structure.md

Source credibility: MEDIUM. TIER 2. Practitioner framework from enterprise AI conference (May 2026). These five questions and three room diagnostics were presented as a 90-day assessment agenda for enterprise data teams. Not independently published as of this writing — conference-derived practitioner consensus. Directionally consistent with Nutanix ECI 2026 (82% of IT leaders say on-prem infrastructure not ready for AI), Gartner data readiness literature, and published vector-store architecture documentation. [Practitioner obs., May 2026]

Executive Summary

The question is no longer whether an organization has data — every enterprise does. The question is whether that data is shaped for agents or shaped for screens. These are structurally different requirements. A data estate optimized for human consumption (dashboards, reports, search interfaces) fails in predictable ways when an agent tries to retrieve from it at inference tempo. Five questions diagnose the gap. Three room diagnostics locate where it hurts most.

The Five Questions: 90-Day Data Estate Assessment

Question 1 — Quality: Do You Have Datasets with Lineage and Provenance?

What it means: An agent that retrieves a data point cannot evaluate its own confidence in that data point without metadata about where it came from, when it was created, how it was transformed, and what validation it has passed. Lineage (the chain of transformations from source to current state) and provenance (the origin and authority of the original source) are the trust signals an agent uses to weight retrieved content.

Why it matters for agents: A human reading a report can apply implicit judgment about source quality. An agent cannot — it will weight a well-formatted but low-quality document equally with a validated primary source unless provenance metadata is attached. Without lineage and provenance, retrieval-augmented agents hallucinate with confidence: they find relevant-seeming data and generate authoritative-sounding output based on stale, unchecked, or internally contradictory sources.

What to assess: Does your data catalog capture where each dataset originated, what transformations it has undergone, when it was last validated, and what authority attests to its accuracy? If the answer is “we have documentation somewhere,” the answer is no. The lineage must be machine-readable and attached to the data object itself, not in a separate wiki that agents cannot access.

The 90-day action: Audit the top 20 data assets that agents will most likely retrieve. For each: does a lineage record exist? Is it attached to the data object? Is it machine-readable? Score 0–3. Any asset scoring below 2 is an agent trust risk.

Question 2 — Structure: Which Datasets Have Machine-Readable Schemas Instead of Just Human-Friendly Tables?

What it means: A human-friendly table is formatted for visual scanning — merged cells, color coding, narrative headers, footnotes, multi-row column spans. An agent cannot reliably parse this without a transformation layer. A machine-readable schema defines field names, data types, allowed values, and relationships in a format an agent can query directly (JSON Schema, Avro, Protobuf, OpenAPI, SQL DDL).

The distinction: Most enterprise data exists in human-friendly formats because it was built for human consumers. Excel workbooks with merged headers. PDFs with embedded tables. PowerPoint slides with data in text boxes. SharePoint lists with informal naming conventions. These formats require an intermediate transformation step before any agent can retrieve structured data from them — and that transformation step introduces error.

Why it is the foundational question: Data shape (see enterprise-ai-data-infrastructure-2026.md) determines retrieval architecture. Machine-readable schemas allow direct structured retrieval. Human-readable formats require OCR → parsing → normalization before any retrieval can occur. The ratio of machine-readable to human-readable data in the agent’s retrieval scope determines how much transformation infrastructure must be built before the agent can be trusted.

What to assess: For each major data asset: is there a machine-readable schema registered in a catalog? Can an agent query it via an API with typed fields? Or does it exist as a formatted artifact designed for human eyes?

The 90-day action: Catalog the schema status of each data asset in the agent’s retrieval scope. Prioritize machine-readable schema creation for the highest-frequency retrieval targets. Do not deploy production agents against human-readable data without a validated transformation pipeline in the critical path.

Question 3 — Metadata: Which Assets Carry Semantic Tags an Agent Can Use Without Translation?

What it means: Semantic tags are metadata fields that describe what a data asset is about in terms an agent can match against a query — not just technical metadata (file size, creation date, owner) but content descriptors: topic, domain, entity types, relationships, temporal scope, confidence level, intended use.

The gap: Most enterprise metadata is human-interpretable but agent-opaque. A document tagged “Q3 Financial Review — EMEA — Internal” is readable by a human who understands organizational context. An agent matching on semantic similarity needs that context translated into embeddings or structured taxonomy fields it can query without understanding the organization’s implicit naming conventions.

Why it matters: Retrieval quality is bounded by metadata quality. A vector store with well-structured semantic tags enables precise, low-latency retrieval. A vector store built on raw documents with no semantic metadata produces broad, high-noise results — the agent retrieves topically related but contextually wrong documents, then generates plausible-sounding but factually mismatched outputs.

What to assess: Do your data assets carry semantic tags beyond technical metadata? Are those tags structured (taxonomy, ontology, controlled vocabulary) or free-text? Can an agent match against them without natural-language interpretation of informal labels?

The 90-day action: For the top retrieval targets, define a semantic tag schema: domain, entity types, temporal scope, confidence tier, access classification. Apply it to the highest priority assets first. Evaluate whether existing metadata can be enriched automatically (LLM-assisted tagging is a viable approach for large archives — with human spot-check validation).

Question 4 — Access Controls: Which Data Assets Support Non-Human Identity and Just-in-Time Access?

What it means: Traditional access controls were designed for human identities — employees log in with credentials, are granted role-based permissions, and access data through application interfaces. Agents are not humans. They have no persistent login session, they operate at machine speed, they may spawn sub-agents that need delegated access, and they may be short-lived (a task agent that exists for 30 seconds, completes a retrieval, and terminates).

The gap: Most enterprise data access control systems (IAM, PAM, RBAC on data lakes, SharePoint permissions, database ACLs) do not have native concepts for:

• Machine identity with scoped, time-limited credentials
• JIT (just-in-time) provisioning of access for a specific task
• Automatic revocation on task completion
• Audit trail tied to an agent identity, not a human proxy

If agents authenticate by inheriting a human user’s credentials, or by using a shared service account with standing access, the audit trail is broken and the permission scope is likely over-provisioned. This is the JPMC Lethal Trifecta Factor 2 (sensitive data access) operationalized at the data layer.

What to assess: For each data asset the agent will access: does the access control system support a machine identity (service principal, OAuth client, SPIFFE/SVID)? Can access be scoped to specific operations (read-only, specific tables, time-bounded)? Is JIT provisioning available? Is there an audit record that traces each retrieval to a specific agent task (not a shared service account)?

The 90-day action: Inventory data assets against non-human identity support. Flag any asset that can only be accessed via shared credentials or human-proxied login. Prioritize integrating those assets with a JIT provisioning system (CyberArk, Okta AI Agents, Microsoft Entra) before routing agents to them in production.

Question 5 — [Awaiting capture — conference cut off]

This framework was presented as a five-question agenda. Question 5 was not captured in the live session. Likely candidates based on the surrounding themes:

• Freshness: Which datasets have defined refresh cadences and staleness signals that an agent can evaluate before deciding whether to retrieve?
• Duplication / conflict resolution: Which datasets have known overlaps with other sources, and what is the resolution rule when an agent retrieves conflicting values?
• Cost: Which data assets carry retrieval cost (API calls, compute) that needs to be accounted for in agent token-budget planning?

To be updated when confirmed from conference notes or follow-up materials.

Three Room Diagnostics

These three questions were posed directly to conference attendees as a live diagnostic. They are designed to locate the specific gap rather than produce a comprehensive assessment.

Diagnostic 1 — Where Is Your Data Still Shaped for Screens Instead of Agents?

What it reveals: The proportion of the data estate that requires human interpretation to be useful — formatted for visual consumption rather than machine retrieval. This is not about file format (PDFs can be machine-readable with the right schema); it is about whether the organizational logic embedded in the data (column names, category labels, relationship structures, naming conventions) is explicit enough for an agent to use without a human translator.

The insight: Every organization has both types. The diagnostic locates the boundary. Data shaped for screens is not wrong — it serves its original purpose. The question is whether the retrieval plan for agent deployments accounts for the transformation cost. Organizations that underestimate this consistently overestimate how quickly they can deploy production agents: the agent is ready; the data is not.

Practical test: Pick the three knowledge domains your agents will most frequently retrieve from. For each: can you write an API call that returns a typed, structured result without a human designing the query? If not, the data is shaped for screens.

Diagnostic 2 — Which of the Three Gaps Feels Tightest Right Now: Data Shape, Speed, or Stack?

The three gaps:

Why the question matters: The three gaps require different investments. Shape is a data engineering problem — schema design, tagging, transformation pipelines. Speed is a storage and caching problem — NVMe tiers, warm vector indexes, CDN-style edge caching for high-frequency retrieval. Stack is an infrastructure problem — east-west networking, DPU offload, liquid cooling. Solving the wrong gap first is a common and expensive mistake.

The diagnostic: Organizations in early pilot (1–5 agents, <1M tokens/day) typically hit shape first. Organizations scaling to production (10+ agents, >10M tokens/day) typically hit speed. Organizations building inference floors (100+ agents, dedicated hardware) typically hit stack. Where you feel the tightest constraint is a signal about where you are in the adoption curve, not just what to fix next.

Diagnostic 3 — If Your Current Data Lake Became Your Inference Floor Tomorrow, What Would Break First?

What it surfaces: This is the stress test that converts abstract readiness assessment into concrete failure modes. The inference floor is the data lake operating at agent retrieval cadence rather than human query cadence — continuous, parallel, low-latency, non-human identity, high volume.

Predictable failure sequence for most enterprise data lakes:

1. Access control layer — IAM systems designed for human session-based auth cannot issue and revoke JIT machine credentials at agent request rates. Shared service accounts get used as a workaround. Audit trail collapses.

2. Metadata layer — Search and catalog systems built for human keyword search return too many results with insufficient semantic discrimination. Agents retrieve noisy result sets; re-ranking overhead spikes; latency increases.

3. Storage I/O — Object storage (S3-compatible) with eventual consistency and multi-second read latency for large files cannot serve sub-100ms retrieval requirements. Agents that expected instant results queue up; throughput collapses.

4. East-west networking — Multi-agent pipelines generate agent-to-agent and agent-to-data-store traffic that overwhelms north-south optimized network fabric. Latency spikes; timeouts cascade.

5. Compute — GPU inference nodes saturate before the data infrastructure issues are resolved, making it appear to be a compute problem when the root cause is data access latency creating queuing at the inference layer.

The value of the diagnostic: Most organizations will identify access controls or metadata as the first failure point. Both are fixable in 90 days without infrastructure procurement. Storage I/O and networking require 6–18 months of procurement and deployment. Knowing which breaks first allows prioritization of the quick fixes (access + metadata) while planning the long-cycle investments (storage + networking).

What This Means for Your Organization

The five questions and three diagnostics form a 90-day pre-deployment assessment that any organization can run against its existing data estate without a vendor engagement. The output is a prioritized gap list: which data assets need lineage, which need machine-readable schemas, which need semantic tags, and which cannot support agent access patterns without infrastructure changes.

The “inference floor tomorrow” diagnostic is the most operationally useful of the three because it produces a concrete failure sequence, not an abstract maturity score. Organizations that run this diagnostic before scaling agent deployments consistently identify the access control gap as the first failure point — and it is the easiest to fix. Organizations that skip the diagnostic discover the access control gap in production, under load, during an incident.

The three-gaps diagnostic locates where an organization sits in the adoption curve. Shape gaps are early-stage. Speed gaps are mid-stage. Stack gaps are infrastructure-scale. If all three feel tight simultaneously, the organization has scaled agent deployment without a phased data readiness plan — the correct response is to freeze new agent deployments and clear the shape and speed gaps before adding stack investment.

For a structured version of this assessment applied to a specific data estate, brandon@brandonsneider.com.

Key Data Points

Brandon Sneider | brandon@brandonsneider.com May 2026