Gartner finds that 60% of agentic AI projects stall or get cancelled specifically because the data wasn't ready when development started.[1] Not the model. Not the framework. Not the team. The data. And yet walk into any team planning an agentic build and you'll find either a 47-point enterprise audit nobody finishes, or nothing at all.
One team we tracked closely built a customer churn prediction agent, tested it thoroughly on a clean CSV export, and hit a production wall in week 6. The issue: their CRM's last_active field was being backfilled by a nightly batch job. The agent was treating data that was 23 hours stale as current — making confident retention decisions on customers who had already cancelled. A 30-minute data review would have surfaced this in minute 8.
This checklist exists to close that gap. Three tiers, each with a clear pass/fail gate, runnable in a single sprint planning session. Tier 1 clears you to build. Tier 2 clears you to ship to users. Tier 3 clears you for full autonomous deployment.
Why the Standard Pre-Build Audit Never Gets Done
Enterprise frameworks exist. Lean ones don't.
The Gartner data readiness checklist for agentic AI is genuinely thorough. It's also behind a paywall, spans dozens of line items, and requires coordinated input from data governance, legal, and infrastructure teams. For a product team with a two-week runway to prove out a first agent, it's practically inaccessible.
The result is a binary collapse: teams either skip the data review entirely, or they do a surface-level "we have the data" sanity check and move on. Both approaches fail — the first usually in week 4 when the agent returns nonsense, the second in production when it takes a bad action on stale or malformed records.
The 30-minute scoreboard below is not a replacement for a full data governance program. It's a go/no-go gate — the minimum signal you need to know whether your data can support the agent you're about to build, and at what autonomy level it's safe to operate.
Tier 1: Foundation — Schema and SLA Validation
Can the agent reliably read what it needs, when it needs it?
Foundation gates are binary. Either the data contract is defined and enforced, or it isn't. This tier takes roughly 10 minutes to run and blocks everything else if it fails.
The two most common Foundation failures are schema drift and missing 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 when nobody has ever formally defined how stale is too stale — which means there's no way to know when the SLA is violated.
For legacy systems you didn't build, you're not checking whether the data is perfect. You're checking whether you can define a contract on top of what exists and whether the system can honor it.
Tier 1 — Foundation Gates
Schema contract documented: expected tables, columns, and types are written down and version-controlled
Freshness SLA defined: maximum acceptable data age per table is specified before build starts
Agent can query without human intervention: no manual export or copy step in the access path
Null rates acceptable: critical columns have null rates below your defined threshold in production data
Type consistency verified: no silent string/int coercion or format inconsistency in the production dataset
data_readiness_tier1.pyimport psycopg2
from datetime import datetime, timedelta
def check_schema_contract(
conn, table: str, required_columns: list[str]
) -> dict:
"""Verify expected schema columns exist before committing to agent build."""
cursor = conn.cursor()
cursor.execute(
"SELECT column_name FROM information_schema.columns WHERE table_name = %s",
(table,)
)
actual = {row[0] for row in cursor.fetchall()}
missing = set(required_columns) - actual
return {"table": table, "missing": list(missing), "pass": len(missing) == 0}
def check_freshness_sla(
conn, table: str, timestamp_col: str, max_age_minutes: int
) -> dict:
"""Measure actual data age against the proposed SLA."""
cursor = conn.cursor()
cursor.execute(f"SELECT MAX({timestamp_col}) FROM {table}")
latest = cursor.fetchone()[0]
age = datetime.utcnow() - latest.replace(tzinfo=None)
return {
"table": table,
"age_minutes": int(age.total_seconds() / 60),
"sla_minutes": max_age_minutes,
"pass": age < timedelta(minutes=max_age_minutes),
}Tier 2: Workflow — Governance Integration
When the data breaks, does anything catch it before the agent acts on 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 typical pattern: a team has a data quality policy in a Confluence page, a data owner assigned in a kickoff meeting, and zero mechanism to surface quality violations before the agent reads the data.
This isn't hypothetical. An internal analyst agent at a mid-size e-commerce company sent promotional emails to already-churned customers because the suppression list hadn't been updated since a data migration four months prior. The data owner existed on paper. The governance policy existed on paper. Neither was wired into the agent's access path.
Tier 2 checks that governance is operational, not just documented. A named owner who actually responds, a quality gate that fires before agent reads, and an incident response runbook the agent team can actually use.
Tier 2 — Workflow Gates
Data owner identified: a named person or team is on call for data incidents in this domain and responds within 4 hours
Quality rules enforced upstream: data quality checks run before records reach agent-accessible tables — not just in reports
Incident response path exists: a runbook covers what the agent should do when data quality drops below threshold
Access permissions audited: the agent's service account has read-only access to exactly what it needs, nothing more
Schema change notifications configured: agent team receives alerts before upstream schema changes go live
Tier 3: Autonomous — Lineage and Cost Tracking
When the agent acts without supervision, can you trace and explain every decision?
Tier 3 is where agents earning full autonomy qualify — or don't. Most teams skip this entirely on first builds, which is why they end up with agents that perform well in supervised mode and then silently drift once oversight is relaxed.
Lineage is the hard part. Not technically — implementing it is straightforward. The hard part is that it requires buy-in from whoever owns the upstream systems. Every record the agent acts on needs a traceable chain: where did this data come from, when was it last updated, and who authorized it for autonomous decision-making? Without that chain, post-incident analysis is guesswork — and regulators won't accept guesswork.
Cost tracking is underrated. Agents that read data at scale — RAG pipelines querying a vector store on every invocation, agents hitting a live database per task — generate real per-call costs that compound in ways teams don't model in advance. Build cost observability in before you scale, not after you get the cloud bill.
Tier 3 — Autonomous Gates
Lineage tracked: the provenance of every record the agent acts on is queryable after the fact
Audit trail enabled: every agent read and write is logged with timestamp, agent identity, and decision context
Cost monitoring live: per-agent data access cost is visible in a dashboard before scaling begins
Data drift detection configured: alerts fire when input distribution shifts beyond a defined threshold
Rollback path defined: a procedure exists to identify and revert agent actions taken on corrupted or stale data
Retrofitting Legacy Systems Without Re-Platforming
How to pass data readiness gates on systems you didn't build and can't rewrite.
The hardest case: you need to pass Tier 1 and Tier 2 gates on an Oracle database from 2009 that has no SLA documentation, an undocumented schema, and a listed owner who left the company two years ago. You cannot re-platform. You have two sprints.
The approach that works consistently 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 governance contract the agent expects.
This is the adapter pattern applied to data access, with the specific goal of making legacy data agent-safe without touching the source. The wrapper must be read-only — it caches and validates, it never writes back. The key operational win: the wrapper lets you add lineage logging and cost instrumentation to queries that would otherwise be completely opaque.
Agent queries Oracle directly via JDBC or raw SQL
No freshness SLA — data could be hours or days stale
Upstream schema changes break agent silently at runtime
No audit trail of what records the agent read or when
DB user permissions often broader than the agent actually needs
Agent queries wrapper API — legacy DB internals are opaque to it
Wrapper enforces freshness SLA and returns an error if violated
Schema contract validated on every request; mismatches surface early
Wrapper logs every read with timestamp, agent ID, and context
Permissions enforced at wrapper layer — DB user credentials unchanged
legacy_wrapper.pyimport time
from functools import wraps
from typing import Any, Callable
_cache: dict[str, tuple[Any, float]] = {}
def with_freshness_sla(max_age_seconds: int = 300):
"""Enforce a freshness SLA on legacy reads without touching the source system."""
def decorator(fetch_fn: Callable) -> Callable:
@wraps(fetch_fn)
def wrapper(*args, **kwargs):
key = f"{fetch_fn.__name__}:{args}:{sorted(kwargs.items())}"
if key in _cache:
data, cached_at = _cache[key]
if time.time() - cached_at < max_age_seconds:
return data
data = fetch_fn(*args, **kwargs)
_cache[key] = (data, time.time())
return data
return wrapper
return decorator
# Decorate any legacy query with an explicit freshness SLA.
# The source system is untouched; the contract lives in the wrapper.
@with_freshness_sla(max_age_seconds=180) # 3-minute SLA
def get_customer_status(customer_id: str) -> dict:
return legacy_oracle_conn.execute(
"SELECT status, last_active FROM customers WHERE id = :id",
id=customer_id
).fetchone()Running the 30-Minute Scoreboard
One sprint planning session. Clear go/no-go signal per tier.
The scoring rubric maps each gate to one of three actions: pass (proceed), partial (proceed with documented mitigation), or fail (block). Partial means you have a workaround in place that isn't permanent — you're aware of the risk and have a plan.
You don't need all Tier 3 gates to start building. But all Tier 1 gates must pass before writing a line of agent code, and all Tier 2 gates must pass before real users touch the agent. Tier 3 is the bar for unsupervised production deployment. Most teams find they can reach Tier 2 in the first sprint and Tier 3 over the following two.
| Tier | Gate | Weight | Pass Condition | Fail Action |
|---|---|---|---|---|
| 1 — Foundation | Schema contract | Critical | All expected columns documented and verified in production | Block build |
| 1 — Foundation | Freshness SLA defined | Critical | Max acceptable data age per table specified before build | Block build |
| 1 — Foundation | Agent-accessible without human | High | No manual export or copy step in access path | Scope down or fix |
| 1 — Foundation | Null rates acceptable | Medium | Critical columns below defined null threshold in production | Document risk |
| 2 — Workflow | Data owner on call | Critical | Named person responds to data incidents within 4 hours | Block autonomous use |
| 2 — Workflow | Quality rules enforced upstream | High | Checks fire before records reach agent-accessible tables | Add quality gate |
| 2 — Workflow | Incident response runbook | High | Runbook covers agent behavior when data quality degrades | Write before shipping |
| 2 — Workflow | Access permissions audited | Critical | Agent service account has read-only on minimal required scope | Fix before deploy |
| 3 — Autonomous | Lineage tracked | Critical | Every acted-on record has queryable provenance | Scoped deploy only |
| 3 — Autonomous | Audit trail enabled | Critical | All agent reads and writes logged with agent context | Block full autonomy |
| 3 — Autonomous | Cost monitoring live | High | Per-agent data cost visible in dashboard before scale | Add before scaling |
| 3 — Autonomous | Data drift alerts | Medium | Alerts configured for input distribution shifts | Monitor manually first |
When You Fail a Gate
A failed gate is information, not a stop sign.
The right response to a Tier 1 failure is not to push the agent into production and hope the data behaves. It's also not necessarily to halt the project. Gate failures define the agent's valid operating scope.
Fail a freshness SLA gate? Your agent can operate on historical analysis tasks but not real-time decisions — that's a scoped deploy, not a dead project. Fail a lineage gate? Run the agent in supervised mode with human review on every batch, rather than fully autonomously. The tier structure maps directly to the autonomy level the data can safely support.
One finding that surprises teams: those who run this assessment and fail two or three gates consistently ship faster than teams who don't run it at all. Discovering a freshness SLA problem in sprint planning costs two days to fix. Discovering it in week 6, after building agent 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.
Do I need to pass all three tiers before starting to build?
No. Tier 1 (Foundation) must pass before writing any agent code — it establishes whether the data is readable at all. Tier 2 (Workflow) must pass before the agent goes in front of real users. Tier 3 (Autonomous) is the bar for unsupervised production deployment. You can build and iterate with Tier 1 gates passing while you work on Tier 2 and 3 in parallel.
How do I run this on data I don't own or control?
Most Foundation gates are readable without write access — run the schema and freshness checks yourself with a read-only connection. If there's no identifiable data owner, that's a Tier 2 failure: escalate before building. For legacy systems with no documentation, the retrofit wrapper pattern adds a contract layer without touching the source — you define the contract you need, the wrapper enforces it, and the legacy system is never modified.
What if nobody knows how fresh our legacy system's data actually is?
Measure it before defining the SLA. Run the checkfreshnesssla query from the Tier 1 code example over 30 days of historical records to get observed maximum data age. Add 20% margin and use that as your baseline SLA. Then decide whether your agent's specific decisions are safe to make at that staleness level — an agent recommending products can tolerate more lag than one processing refunds.
Is this checklist sufficient for regulated industries — HIPAA, SOC 2, PCI?
No, and it's not designed to be. This gets you to a reliable build decision, not a compliance posture. Regulated environments need additional controls: data classification tags, encryption in transit and at rest, access log retention policies, and breach notification paths. Treat this as the engineering foundation you layer compliance controls on top of — not a substitute for them.
- [1]Deepak Seth, Roxane Edjlali — Use This Checklist to Ensure Your Data Is Ready for the Agentic AI Era(gartner.com)↩
- [2]Digital Applied — Why 88% of AI Agents Fail Production: Analysis Guide(digitalapplied.com)↩
- [3]AI Agent Corps — Why Most Agentic AI Projects Fail (And How to Succeed in 2026)(agentcorps.co)↩
- [4]According to Plan — The Anatomy of an Enterprise AI Agent Failure(according-to-plan.com)↩
- [5]Matteo Gazzurelli — Why 40% of Agentic AI Projects Fail (And How to Avoid It)(building.theatlantic.com)↩
