AI data readiness is usually discussed as if the whole company has to become perfectly clean before agents can ship. That framing stalls useful work.
The more practical question is narrower: can the data behind this workflow support an agent that reads, reasons, recommends, and maybe writes back?
That standard is still demanding. An agent needs current records, clear ownership, reliable identifiers, permission boundaries, and enough context to explain its work. But the review can be scoped to one operational path instead of every table in the company.
Readiness is workflow-specific
A company can be unready for broad AI and ready for one well-scoped agent workflow. Judge the data behind the work, not the whole enterprise by reputation.
The five readiness questions
Start with a workflow that someone wants an agent to support. Then ask five questions.
Can the agent find the right record? If customers, accounts, tickets, contracts, invoices, and projects do not share stable identifiers, the agent will join the wrong context or require manual lookup.
Can the agent trust the field? If the close date, tier, renewal amount, owner, status, or policy flag is often stale, the agent needs freshness rules and human review.
Can the agent see only what it should see? If permission logic lives in the UI but not the API, an agent may retrieve data a user should not access.
Can the agent explain the source? If the system cannot show where a fact came from, reviewers will not trust high-impact recommendations.
Can the agent complete the loop? If the outcome has to be written back to CRM, ERP, ticketing, billing, or a project system, the workflow needs controlled write access, state checks, and audit logs.
Readiness lives at the record level
Dashboards hide data readiness problems because aggregated numbers can look fine while individual records are unusable.
An AI agent works on individual cases. It needs to know that this account is the right account, this contract is the current contract, this policy applies to this segment, this ticket is still open, and this user has authority to take this action.
IBM’s data governance guidance puts the right nouns on the table: quality, security, and availability, plus clear sources, destinations, transformations, dependencies, ownership, access rights, and responsibilities. For agents, those become record-level questions rather than data-program slogans. Is this fact usable in this decision right now? Who owns it? Who can see it? What downstream action will rely on it?
NIST’s AI Risk Management Framework pushes teams to map, measure, manage, and govern AI risk across the lifecycle. A data readiness review is the mapping step for the facts an agent will depend on: identifiers, freshness, permissions, provenance, and write-back readiness.
McKinsey’s 2025 State of AI shows why this has to be scoped to operating change, not enterprise hygiene theater. AI use is widespread, but only 39 percent of respondents report enterprise-level EBIT impact. Data readiness is one of the foundations that lets a specific workflow move from AI activity to measurable value.
A simple readiness path
flowchart LR
A["Workflow decision"]
B["Required facts"]
C["Source systems"]
D["Identity and permissions"]
E["Freshness checks"]
F["Agent action"]
G["Audit trail"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G The key move is to start from the decision, not the database. A renewal-risk agent and a procurement-intake agent may both touch CRM, contracts, and email, but they need different facts, owners, and write-back rules.
The readiness review
AI data readiness review
Run this review against one workflow's required facts before evaluating model quality.
Readiness area: Identifiers
- Evidence to inspect
- Do records share stable IDs across CRM, support, billing, contracts, and project systems?
- Risk if weak
- The agent joins the wrong customer, deal, ticket, or invoice
Readiness area: Freshness
- Evidence to inspect
- Which fields have last-updated timestamps, source owners, and stale-data thresholds?
- Risk if weak
- The agent makes a current recommendation using old facts
Readiness area: Permissions
- Evidence to inspect
- Can API access enforce the same role and tenant boundaries as the user interface?
- Risk if weak
- The agent retrieves or exposes data the user should not see
Readiness area: Provenance
- Evidence to inspect
- Can the workflow show where each important fact came from?
- Risk if weak
- Reviewers cannot verify recommendations or investigate errors
Readiness area: Write-back readiness
- Evidence to inspect
- Are target systems able to accept controlled updates with audit events and rollback expectations?
- Risk if weak
- The workflow creates manual cleanup or silent record changes
Permission readiness is often the blocker
Many mid-market systems have workable user permissions and weak programmatic permissions. The application UI knows what a manager can see, but the integration token can see everything. That is not agent-ready.
Before exposing data to an agent, define access in terms of the initiating user:
- Which tenant, region, or business unit does the user belong to?
- Which customer or record scopes are allowed?
- Which fields are hidden, summarized, or redacted?
- Which tool actions require elevated approval?
- Which retrieval sources are off-limits even if technically accessible?
OWASP’s Top 10 for LLM Applications is the practical reason to inspect permission readiness before model quality. Sensitive information disclosure, excessive agency, system prompt leakage, vector and embedding weaknesses, and unbounded consumption often arise from broad retrieval or broad tool access. A model prompt cannot compensate for an integration token with too much authority.
Data readiness is not just cleaning
Cleaning fields helps. But an agent workflow also needs operating rules.
If a field is missing, should the agent ask a human, search another source, infer from related records, or refuse? If two sources disagree, which wins? If a value is older than the freshness threshold, should the agent still cite it? If a required source is unavailable, should the workflow pause or continue with a lower-confidence recommendation?
These are product decisions and operating decisions, not just data-quality tasks.
What “ready enough” looks like
A workflow is ready enough for a first agent release when the team can answer these questions without a long debate:
- What decision will the agent support?
- Which facts are required?
- Which system owns each fact?
- Which fields are reliable enough to use automatically?
- Which facts require a citation or reviewer check?
- Which user roles can retrieve which sources?
- Which action, if any, can the agent write back?
- Which metric will prove the workflow improved?
The first release can still be conservative. It can draft, assemble evidence, and recommend without writing back. But if the evidence package is trusted and reviewers consistently accept the recommendation, the team has a credible path toward more automation.
This is the operating logic behind Metacto’s Context Engineering: prepare the exact context a workflow needs, with source, authority, permission, and freshness intact. The goal is not a universal knowledge layer on day one. It is a workflow-ready context package that can support controlled agent action.