Data Readiness Before Build: The Three-Tier Gate for Agentic Projects

Gartner found that 60% of agentic AI projects stall or get cancelled because the data was not ready when development started.^[1] Not the model. Not the framework. Not the team. The data. Walk into any kickoff and you find one of two things: a 47-line enterprise audit nobody finishes, or nothing at all.

One team we tracked shipped a customer churn agent that passed every offline test on a clean CSV. Production hit them in week six. The CRM's last_active column was being backfilled by a nightly batch — the agent was treating data 23 hours stale as live, recommending retention plays for customers who had already cancelled. A 30-minute review would have caught it in minute eight.

Fivetran's 2026 Agentic AI Readiness Index found that only 15% of organizations are fully prepared to support agentic AI in production, yet 41% are already running it there.^[6] The gap does not close by deploying faster. It closes by gating correctly before the first line of agent code is written.

This checklist closes that gap. Three tiers, each with a binary pass/fail gate. Tier 1 clears you to build. Tier 2 clears you to ship to users. Tier 3 clears you to remove the human from the loop. None of it takes longer than a sprint planning session.

The Gartner data readiness checklist is genuinely thorough. It is also paywalled, dozens of line items long, and requires coordinated input from data governance, legal, and infrastructure. For a product team with a two-week runway to prove a first agent, it is functionally inaccessible.

The result is a binary collapse. Teams either skip the data review entirely, or they do a surface-level "we have the data" check and move on. The first approach fails in week four when the agent returns nonsense. The second fails in production when the agent acts on a stale or malformed record and ships a real consequence to a real customer.

The Fivetran index found the top barriers to agentic AI goals are: data quality and lineage (cited by 42% of respondents), regulatory compliance (39%), and security and privacy risk (39%).^[6] All three are checkable before the first agent tool call — but only if the gate exists.

The 30-minute scoreboard below is not a replacement for a data governance program. It is a go/no-go gate — the minimum signal you need to know whether your data can support the agent you are about to build, and at what autonomy level it is safe to operate.

Foundation gates are binary. The data contract exists and is enforced, or it does not. This tier runs in roughly 10 minutes and blocks everything downstream if it fails.

The two failure modes that show up over and over: schema drift and undefined freshness SLAs. Schema drift happens when an agent is built against a column that gets renamed, split, or silently dropped by an upstream migration nobody told the agent team about. Freshness SLA failures happen because nobody ever wrote down how stale is too stale — which means there is no way to know when the SLA is violated. Drift is the default state of any contract without an owner.

Null rate thresholds deserve more attention than they usually get. A column that is null 0.3% of the time in your dev extract may be null 8% of the time in production at peak load, depending on write patterns. Check null rates on production data, at peak and off-peak, before you design the agent's fallback behavior.

For legacy systems you did not build, you are not checking whether the data is perfect. You are checking whether you can wrap a contract around what exists, and whether the system can honor it.

Governance failures are the most expensive Tier 2 failure mode and almost entirely invisible until an agent takes a bad action in production. The shape is always the same: a data quality policy in Confluence, a data owner assigned in a kickoff meeting, and zero mechanism to surface a violation before the agent reads the data.

This is not hypothetical. An internal analyst agent at a mid-size e-commerce company sent promotional emails to already-churned customers because the suppression list had not been updated since a data migration four months earlier. The owner existed on paper. The policy existed on paper. Neither was wired into the agent's access path.

Access scoping matters more than it looks on a checklist. An agent service account with SELECT * permissions on a customer table is one schema change away from accidentally reading PII fields the agent was never meant to touch. The right model is a read-only service account with explicit column-level grants — not table-level, column-level. If your database does not support column-level grants, the wrapper pattern (see the legacy section) is the fix.

Schema change notifications are chronically under-wired. dbt's --warn-error flag on column removal, database NOTIFY events on DDL, or a simple pre-migration checklist that asks "which agents read this table?" — any of these is sufficient. The team that skips this finds out about the schema change when the agent starts returning parse errors at 2am.

Tier 2 checks that governance is operational, not documentary. A named owner who actually answers. A quality gate that fires before the agent reads. An incident response runbook the agent team can follow when the data degrades at 3am.

Tier 3 is where agents earning full autonomy qualify, or do not. Most teams skip it on first builds. That is exactly why those agents perform well in supervised mode and silently drift the moment oversight is relaxed.

Lineage is the hard part. Not technically — implementing it is straightforward. The hard part is buy-in from whoever owns the upstream systems. Every record the agent acts on needs a traceable chain: where it came from, when it last updated, who authorized it for autonomous use. Without that chain, post-incident analysis is guesswork. Regulators do not accept guesswork.

ISO/IEC 42001 — the first international AI management system standard — specifically mandates that organizations maintain records of AI system performance and decision-making, with log retention aligned to regulatory risk tier: 180 days minimum, 365 days for high-risk decisions.^[9] If your agent touches customer data, financial records, or any regulated domain, audit trail retention is not a nice-to-have.

Data drift is the failure mode that creeps in slowly. An agent trained or prompted against a data distribution that shifts over time will degrade silently — no errors, just increasingly wrong outputs. The industry standard threshold is Population Stability Index (PSI): below 0.1 is stable, 0.1–0.2 warrants investigation, above 0.2 requires action — either retraining, re-prompting, or restricting the agent's autonomy until the distribution is understood.^[7] Configure PSI monitoring before you scale, not after the agent starts returning strange results.

Cost tracking is the underrated layer. High-volume agents — RAG pipelines hitting a vector store on every invocation, agents querying a live database per task — generate per-call costs that compound silently until someone checks the billing dashboard. Build cost observability before you scale, not after.

The hardest case: you need to clear Tier 1 and Tier 2 against an Oracle instance from 2009 that has no SLA documentation, undocumented schema, and a listed owner who left two years ago. You cannot re-platform. You have two sprints.

The approach that works is a semantic wrapper layer — a lightweight service between the agent and the legacy system that enforces the schema contract and freshness SLA on every read. The legacy database is unchanged. The wrapper handles the contract the agent expects.

This is the adapter pattern applied to data access, with one specific goal: make legacy data agent-safe without touching the source. The wrapper is read-only — it caches and validates, never writes back. The operational win is the part teams underestimate: the wrapper lets you bolt lineage logging and cost instrumentation onto queries that were previously opaque.

The wrapper also unblocks Tier 2 access scoping. Rather than trying to carve column-level grants on an Oracle schema with years of accumulated permissions, the wrapper exposes only the fields the agent needs. The legacy database credentials never leave the wrapper's environment. The agent authenticates against the wrapper, which authenticates against the database.

The rubric maps each gate to one of three outcomes: pass (proceed), partial (proceed with a documented mitigation), fail (block). Partial means the workaround is real but temporary — the risk is named, the plan is on paper, the owner is real.

You do not need every Tier 3 gate to start building. You do need every Tier 1 gate to pass before any agent code is written, and every Tier 2 gate before real users touch the agent. Tier 3 is the bar for unsupervised production. Most teams reach Tier 2 in the first sprint and Tier 3 over the next two.

The right response to a Tier 1 failure is not to push the agent into production and hope. It is also not necessarily to halt the project. Gate failures define the agent's valid operating scope.

Fail a freshness SLA gate? The agent runs historical analysis tasks but not real-time decisions. That is a scoped deploy, not a dead project. Fail a lineage gate? Run the agent in supervised mode with human review on every batch — autonomy is something the data has to earn. The tier structure maps directly to the autonomy level the data can safely support.

One finding that surprises teams: those who run this gate and fail two or three checks consistently ship faster than teams who skip it. Discovering a freshness SLA problem in sprint planning costs two days. Discovering it in week six, after building decision logic on top of stale data assumptions, costs weeks of rework plus the credibility hit of a failed demo. Failing early is the better outcome. Always.

Tier 3 is not the goal for every agent. It is the bar for agents that need to operate without human oversight on consequential decisions. Most agents — internal analytics, draft generation, data enrichment, recommendation engines — should stay at Tier 2 with a human in the loop on anything that crosses a dollar threshold or touches a customer-facing record.

The clearest signal that Tier 3 is premature: you cannot explain, in one sentence, what the rollback process is if the agent acts on corrupted data. If that sentence takes more than 30 seconds to draft, the autonomy level is ahead of the data infrastructure.

A useful heuristic for the decision: if a human would need to review the output before it triggers an external action, the agent belongs at Tier 2. Tier 3 is for agents where the review cost is higher than the error cost — which is true for a smaller fraction of use cases than most teams assume when they first scope an agentic project.

Eighty-five percent of enterprises are running agentic AI on a data foundation that is not ready for it.^[6] The ones that close the gap are not running longer governance programs. They are running shorter, sharper gates — and running them before the first tool call, not after the first failure.