A retention agent at a B2B software vendor was asked to find at-risk accounts and launch a save campaign. It queried the warehouse, computed “active customers,” ranked the decliners, and sent 1,400 discount offers.
The agent used the product team’s definition of active, any login in 30 days, rather than finance’s definition, any billable event. The definitions differed by roughly 11%. About 160 healthy, full-price accounts received an unsolicited discount. No dashboard was involved. No human reviewed the decision. The query was technically correct.
An AI ISV is an independent software vendor that embeds artificial intelligence in its products. For established ISVs, the hardest part of agentic AI is often not the model. It is making the underlying data safe for machines that can act without a person correcting the context.
The same warehouse table, consumed by a person and by an autonomous agent
Definition: Agentic data readiness is the degree to which an organization’s data, including its semantics, contracts, permissions, freshness, and observability, can be safely consumed and acted on by autonomous AI agents without a human in the loop to catch errors.
Key takeaways:
- Agentic data readiness extends beyond data quality to semantics, access, resilience, observability, and safe write-back.
- Every readiness pillar needs a verifiable artifact, not a policy statement.
- For an AI ISV, tenant isolation, semantic drift, and per-tenant economics make readiness a product obligation, not an internal IT exercise.
The market gap: Agent adoption is moving faster than readiness
Four independent forecasters size the agentic AI market between $9.1B and $11.6B for 2026, with compound growth clustered tightly between 40% and 50%. The spread in absolute size reflects disagreement about what counts as “agentic.” The agreement on growth rate is the more meaningful signal.
2026 agentic AI market estimate, USD billions
Sources: Fortune Business Insights, Precedence Research, Grand View Research, Mordor Intelligence
Gartner projected that 40% of enterprise applications would include task-specific AI agents by the end of 2026, up from under 5% in 2025. Gartner also predicted that more than 40% of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.
A Futurum Group survey of 818 enterprise data decision-makers adds architectural detail. In the source draft, 59% of respondents report investing in semantic layers as critical AI infrastructure. The two leading bottlenecks are integration complexity at 29.3% and write-back limitations at 24.6%.
The core point: many agentic AI failures are data-readiness failures wearing a different label.
Why BI-ready does not mean agent-ready
Business intelligence systems assume a person will interpret a result before anything changes. Agentic systems compress interpretation and execution into one machine-speed path. That changes the standard for the data platform.
| Shift | BI-era assumption | What agents require |
|---|---|---|
| Interpretation to action | A person supplies context before deciding. | One canonical, machine-readable definition for every decision-critical metric. |
| Read to write | Analytics does not mutate operational state. | Idempotency, correlation IDs, rollback paths, and a dedicated action log. |
| Batch to near-real time | Users understand that data is delayed. | Freshness exposed as metadata so an agent can decline to act on stale data. |
| User-scoped to agent-scoped access | Permissions live in the BI layer. | Delegated machine identity with row- and column-level controls below the API. |
| Tribal to declared semantics | Definitions live in queries and analysts’ heads. | A semantic layer treated as a runtime dependency. |
| Visible to silent failure | Someone notices a wrong chart. | End-to-end traces for retrievals, tool calls, and writes. |
Data quality remains necessary, but it is only one part of this transition. Four of the six shifts above are primarily architectural, access-control, or operational concerns.
The eight pillars of agentic data readiness
Each pillar should end in an artifact that proves the capability exists. “We have governance” is not evidence. “Show me the contract, trace, or rollback procedure” is.
Eight readiness pillars and the evidence that proves each one exists
1. Discoverability and interfaces
Agents need machine-readable catalogs, schemas, and query interfaces. If an LLM cannot infer what a table or endpoint means without tribal knowledge, the data surface is not ready.
Evidence: a schema an LLM can interpret unaided.
2. Data quality
Stale, duplicated, contradictory, or inconsistently structured records corrupt downstream reasoning. Freshness must be visible to the agent, not inferred from an overnight schedule.
Evidence: freshness published as metadata.
3. Contracts and stability
Versioned schemas, data contracts, and a breaking-change policy matter more here than in traditional BI. Without them, an upstream rename silently changes agent behavior in production.
Evidence: schema tests that fail the build.
4. Identity and access control
Every agent needs a distinct, revocable machine identity. Read access for context should be separate from write access for action.
Evidence: one independently revocable identity per agent.
5. Classification and boundaries
PII, PHI, financial and other sensitive fields need to be classified and enforced at the data layer itself and not left to the agent to self-censor after it has already received the data. If an agent queries customer records for context, the boundary on what comes back must exist before the response leaves the system.
Evidence: masking enforced below the agent.
6. Operational resilience
Agents poll and retry at machine speed. Your data services need rate limiting and the ability to absorb sustained, high-frequency query patterns without falling over. This is a fundamentally different load profile from a dashboard refreshing every few minutes.
Evidence: a load test at realistic agent polling rates.
7. Observability and audit trail
Teams must reconstruct what an agent accessed, when, under whose authority, and what it did next.
Evidence: a replayable trace for each agent-data interaction.
8. Action safety
Write-back needs idempotency, approval gates, rollback, and blast-radius limits. A bad inference must not become thousands of repeated actions.
Evidence: a compensating action for every write operation.
The pillars do three jobs. Pillars 1 to 3 determine whether an agent can find and trust data. Pillars 4 and 5 determine whether it is allowed to see the data. Pillars 6 to 8 determine whether it can be allowed to act.
The eight pillars do three different jobs
- Pillars 1, 2 and 3 determine whether an agent can find and trust your data.
- Pillars 4 and 5 determine whether it should be allowed to see it.
- Pillars 6, 7 and 8 determine whether it can be allowed to act.
Most readiness programmes over-invest in the first group, because catalogs and quality look like familiar data work, and under-invest in the third, which is where autonomy is actually won or lost.
Four maturity levels
Use the eight pillars to distinguish four readiness levels:
- Reporting-grade: built for people reading charts.
- Retrieval-grade: agents can find data and the data is not known to be wrong.
- Agent-readable: agents can read data safely and consistently because contracts, identity, and classification are in place.
- Agent-actionable: all eight pillars are operating, so agents can change state within controlled boundaries.
Do not treat the levels as a generic enterprise score. Assess one concrete agent use case, then identify the pillars that gate that use case. The original draft includes a 29-item diagnostic.
Checklist A: core agentic data readiness
Every item is verifiable, yes or no, not an aspiration. 29 checks across the eight pillars — check what is true today, not what is planned. Under 35% is reporting-grade; under 60% retrieval-grade; under 85% agent-readable; 85% and above, agent-actionable.
Pillar 1 · Discoverability and interfaces
☐ An LLM can infer what every agent-facing table or endpoint means from its schema alone
☐ A catalog covering business glossary, lineage, and schema registry includes every agent-facing dataset
☐ Agents query machine-readable interfaces, never dashboards, exports, or raw ingest tables
☐ A single machine-readable definition exists for every top-20 business metric, versioned in git
Pillar 2 · Data quality
☐ Freshness is published as metadata, not inferred from a job schedule
☐ Duplicates and contradictory records are detected before agents can retrieve them
☐ Every table an agent can reach has a named owner reachable within 24 hours
☐ Column-level lineage exists for every field used in a customer-facing agent response
Pillar 3 · Contracts and stability
☐ Every agent-facing dataset has an explicit schema contract with a named producer
☐ Contract violations fail CI before they reach production
☐ A breaking-change policy exists with a deprecation window, and it has been enforced at least once
Pillar 4 · Identity and access control
☐ Every agent has its own machine identity — no shared service accounts, no borrowed human credentials
☐ Read access for context-building is separated from write access for action-taking
☐ Row- and column-level security is enforced below the API, not in the calling application
☐ Any single agent’s access can be revoked without affecting the others
Pillar 5 · Data classification and boundaries
☐ PII, PHI, and financial fields are classified in the catalog, not just known informally
☐ Masking and filtering are enforced in the query path, before the response leaves the system
☐ No agent depends on its own prompt or reasoning to avoid using sensitive data it already received
Pillar 6 · Operational resilience
☐ Data services have been load-tested at agent polling and retry rates, not human rates
☐ Per-agent rate limits and query timeouts are enforced
☐ One misbehaving agent cannot degrade latency for other consumers
Pillar 7 · Observability and audit trail
☐ Every retrieval, tool call, and write is traced end to end
☐ Any agent decision from the last 30 days can be replayed with its original inputs
☐ Each query is attributable in an audit log to both the agent and its delegating principal
☐ Output quality is evaluated against a maintained golden dataset, not by spot-checking
Pillar 8 · Action safety
☐ Every agent write is idempotent and carries a correlation ID
☐ A documented compensating action exists for each write operation
☐ Blast-radius limits are enforced in code — row counts, monetary thresholds — not in policy documents
☐ Approval gates are defined by action risk tier rather than per agent
A 30/60/90 path to one agent-actionable use case
Sequence the work around one use case instead of rebuilding the entire platform.
A 30/60/90 remediation path with testable exit criteria
Days 0 to 30: scope and expose
Choose one agent use case, inventory its data surface, publish ownership and freshness, and block access to raw tables. Exit criterion: the agent reads only curated, owned views.
Days 31 to 60: declare semantics
Define the decision-critical metrics in code, add schema contracts to CI, and flag unusable fields. Exit criterion: two phrasings of the same business question return the same number.
Days 61 to 90: gate actions
Introduce delegated identity, row-level controls, tracing, idempotent writes, and blast-radius caps. Exit criterion: the lowest-risk tier can run without manual approval.
What agentic data readiness means for AI ISVs
An ISV’s readiness problem is structurally harder than an enterprise’s internal deployment. The vendor must protect multiple tenants, support customer-specific semantics, satisfy the strictest applicable control posture, and absorb failures that can affect churn, service-level commitments, and future deals. Gartner’s 40%-of-enterprise-apps figure has a specific consequence for software vendors: the ask is arriving in 2026 procurement cycles, not 2028.
| Dimension | Enterprise doing this internally | ISV doing this for customers |
|---|---|---|
| Risk ownership | One tenant, own risk appetite, own board. | N tenants, the customer’s risk. A leak is a breach of notification, not an incident review. |
| Semantics | One set of definitions; decided once. | Customers customize the schema. Semantics vary per tenant and drift continuously. |
| Compliance | Own posture, own jurisdictions. | Inherit the strictest posture across the entire customer base. |
| Failure cost | Internal embarrassment, a retro. | Churn, SLA credits, and a security questionnaire that stalls every other deal. |
Three ISV-specific control problems
Tenant isolation under agent access
Application-tier filtering is not enough when an agent interface can reach the data layer through a separate path. Enforce isolation below the API and make it provable in an audit log customers can export.
Per-tenant semantic drift
Custom fields, renamed objects, and tenant-specific workflows make a single global semantic model brittle. A practical pattern is a base semantic model with tenant overlays resolved at runtime, plus drift detection for custom fields.
Cost attribution and blast radius
Agent traffic is bursty and non-deterministic. Per-tenant query and token metering should feed both operations and billing. Noisy-neighbor controls should prevent one customer’s agent from degrading latency for every other tenant.
Reference architecture for customer-agent access to an ISV platform
Checklist B: ISV agentic readiness
Isolation and identity
☐ Tenant isolation is enforced below the API layer and provable in an audit log
☐ An agent interface exists with per-tenant scoped credentials, not a shared service account
☐ Agent actions are attributable to a customer principal and exportable for their audit
☐ A tenant-level kill switch disables agent access without a deployment
Semantics and drift
☐ A base semantic model plus tenant overlay is resolved at runtime
☐ Custom-field and renamed-object drift is detected before it changes agent output
☐ Tenant-specific terminology maps to canonical metrics without per-tenant prompt hacks
Economics and trust
☐ Per-tenant query and token metering feeds billing, not only monitoring
☐ Noisy-neighbour limits protect latency for other tenants under agent load
☐ Sub-processor and data-residency posture is documented for every model provider
☐ You have a written, reviewed answer to “does our data train your models” — it is question one in every security review
☐ Agent capability is documented per plan tier, so sales does not promise autonomy you gate
The commercial reframe
For an AI ISV, agent readiness can become a product surface rather than only an internal cost. Agent-accessible data may support premium packaging, per-action pricing, or agent-seat pricing because usage is measurable. Documented isolation and audit posture can also strengthen enterprise security reviews. Treat these as commercial hypotheses to validate with customers, not as automatic outcomes.
The stronger strategic choice is not always to build. If the underlying data is not differentiating, buying a vertical agent from a vendor that has already solved the readiness problem may be faster and lower risk. Readiness investment is most defensible when proprietary operational history, unique customer graphs, or regulated records create a data moat.
Gartner’s longer-range projection puts agentic AI at roughly 30% of enterprise application software revenue by 2035 — over $450 billion, up from 2% in 2025. Whatever the precision of that number, the direction sets out the stakes: the ISVs that are agent-ready will sell into the ISVs that are not.
Readiness is a capability, not a project
Three things to do this week. Pick one agent use case with a real owner. Run both checklists against it honestly, including the items you would rather not score. Then fix the pillars that gate autonomy — access, resilience, audit, and action safety — rather than the ones that feel familiar with data work. The strongest argument against all of this: some organizations should not do readiness work at all. If your data is not genuinely differentiating, buying a vertical agent from a vendor who already solved readiness is faster, cheaper, and lower risk than fixing your own stack. Readiness investment is justified where the data itself is the moat — proprietary operational history, unique customer graphs, regulated records nobody else holds.
Move from agent experiments to controlled execution
Request your AI-ready data capability assessment. Contact Intellias to map a priority agent use case to the data, governance, and action-safety capabilities it requires.
