9 Signs You Need an Agent-First Data Platform

Your team gave an AI agent access to write SQL or review dbt pull requests, and the pilot looked promising. The agent still is not running unsupervised, because a human checks every output before it ships. The model is rarely the reason. The reason is usually the platform under the agent, which was built for people to read and which software cannot query.

Cleanlab surveyed 1,837 engineering and AI leaders in 2025 and found that 95 of them had agents live with real users. That is one in nineteen, and fewer than a third of those were happy with their observability and guardrails. A stronger model does not move that figure, because observability and guardrails come from the platform around the model. An agent-first data platform supplies both, along with the context an agent needs to decide correctly.

The three things an agent-first data platform exposes to software rather than only to people.

What an Agent-First Data Platform Means

An agent-first data platform makes three things available to software. A conventional platform makes the same three things available only to people.

• The context an agent needs for a correct decision is queryable at the moment the agent decides.
• The guardrails decide whether a decision may execute, and they run before it executes.
• The record of what happened is written by the platform, so nobody has to write it up afterwards.

A conventional stack gives people all three and agents none. Column meanings live in a wiki, which an agent cannot query. Approval lives in a reviewer's head, so it applies only to the changes that reviewer sees. The audit trail is a Slack thread, which software cannot read.

A person works around those three gaps by asking a colleague. An agent cannot ask, so it guesses. A guess that compiles returns a number and raises no error, so the mistake ships without anyone seeing it.

An agent-first overhaul is narrower than a replatform. You modernize the three parts an agent has to read and leave the rest of the stack alone.

Sign 1. Your Agents Invent Columns That Do Not Exist

An agent writes SQL against a table it has never seen and fills the gaps with plausible names. You get customer_id where the column is cust_key, or a join on a field that has since been renamed.

Your query history settles this. Pull the last twenty statements an agent wrote against production. Run each one through EXPLAIN, which validates every identifier and executes nothing.

-- Snowflake. The columns an agent is allowed to believe in.
select column_name, data_type, comment
from analytics.information_schema.columns
where table_name = 'ORDERS';

-- And the cheap validity check on what the agent wrote.
explain using text select cust_key, order_total from analytics.orders;

More than one failure in twenty means the agent is guessing at your schema.

A wrong column that compiles costs more than one that fails. Read the column choices that did compile and check them against the definition your finance team uses. An agent reads order_total when the reported figure comes from order_total_usd, and the query returns a number that is wrong.

Snowflake and Atlan measured what governed metadata in the prompt does to text-to-SQL accuracy. It moved from a range of 10% to 31% up to a range of 94% to 99%, and the models did not change.

Give the agent a path to live schema, column types and definitions at call time. Model Context Protocol servers turn the catalog into something an agent queries mid-task rather than something a human reads first.

Prompt engineering does not substitute for that path. A warehouse with 1,200 tables averaging 18 columns is 21,600 column names to carry in every prompt. Every one of them has to stay current, and a schema change lands while you paste it.

Sign 2. Your Warehouse Bill Grew Faster Than Your Data

When compute spend grows faster than storage, growth is not what is driving the bill.

Compare storage volume against compute spend over the last eighteen months. Two queries settle it, and both series sit in SNOWFLAKE.ACCOUNT_USAGE.

-- Compute, by month, for the last eighteen months.
select date_trunc('month', start_time) as month, sum(credits_used) as credits
from snowflake.account_usage.warehouse_metering_history
where start_time >= dateadd('month', -18, current_timestamp())
group by 1 order by 1;

-- Storage, by month, over the same window.
select date_trunc('month', usage_date) as month, avg(storage_bytes) as bytes
from snowflake.account_usage.storage_usage
where usage_date >= dateadd('month', -18, current_date())
group by 1 order by 1;

Divide the last month by the first month, once for credits and once for bytes. This sign applies if the compute multiple is more than twice the storage multiple.

Three things drive that gap, and the invoice breaks out none of them.

• AI workloads were free to try and are not free to run.
• Warehouses sit sized for a peak that happens twice a week.
• Queries scan everything, because narrowing them was nobody's job.

Idle time is the easiest of those three drivers to price. Snowflake's docs put a Large warehouse at 8 credits an hour with auto-suspend at 600 seconds. Suppose forty query bursts a day, each followed by ten idle minutes. They leave 400 idle minutes running, which is 53 credits a day, or roughly 1,600 a month.

Agents move that number in both directions. An unsupervised agent can run up spend in an afternoon, and nobody sees it until the invoice. An agent pointed at warehouse configuration tunes that configuration continuously instead, because no person adjusts a warehouse a hundred times a day. Altimate's Auto Tune right-sizes warehouses without slowing queries.

Sign 3. Pull Requests Sit for Days Because Nobody Trusts the Diff

AI made writing code cheaper, and reviewing that code still costs what it always did. A reviewer who cannot tell whether a 400-line model change is correct defers it, the queue grows, and the team concludes AI made them slower.

Measure the queue rather than trusting the feeling. Ask an engineer how long reviews take, and they report the time they spend reviewing, a much smaller number than the time a pull request spends waiting.

# Open pull requests touching models/ that have waited more than five days.
gh pr list --state open --limit 100 --json number,createdAt,files --jq \
  '[ .[]
     | select(any(.files[]; .path | startswith("models/")))
     | select(now - (.createdAt | fromdate) > 432000) ] | length'

Divide that count by the number of people who actually review model changes, which is usually smaller than the team. More than one stale review per reviewer means the queue is stuck on verifying rather than writing, so buying more capacity to write makes it worse.

The team may be right about the slowdown. A 2025 study put sixteen experienced developers on real tasks in repositories they knew well, with and without AI tools. They took longer with the tools while believing they had been faster.

Writing got faster and the work moved into verifying, which nobody instrumented or staffed. A team that measures only the writing half records a gain while the total time per change goes up.

Evidence attached to the change clears the queue. Show a reviewer three things:

• Which downstream models the diff touches, as a count rather than a diagram.
• That the rewritten query returns identical rows.
• That no new anti-pattern appeared.

A reviewer checking those three claims is not reading 400 lines of SQL. The platform produces those three claims, so the team does not change how it runs review. Why AI agents break in production makes the longer argument.

Sign 4. Your Cost Tooling Reports and Never Acts

Open your cost tool and export last quarter's recommendations, then count how many became a shipped change. The tool records what it advised and not what you did, so the evidence sits in git history rather than in the tool.

Two hundred recommendations and six applied changes is an applied rate of 3%. Under 10% means you bought a dashboard.

Keebo sells autonomous Snowflake optimization, and its own guide puts it flatly.

Observability without execution is just a dashboard and saves you nothing.

Keebo is naming the failure mode of the category it competes in.

A reporting tool describes a state. An execution tool alters that state, under a policy, with a rollback. A team with more recommendations than bandwidth needs an execution tool.

Four categories compete for this budget, and each one answers a different question, so a team can own several and still fail this sign.

Ask of each tool you own which of the nine signs it closes.

Sign 5. Every Migration Loses Months to Business Logic Parity

Syntax translation is the part that goes well. A Redshift dialect becomes a Snowflake dialect, a stored procedure becomes a dbt model, and the first eighty percent lands in weeks.

Then the project stops. Somebody has to prove the new pipeline produces the same numbers as the old one, and that old pipeline encodes a decade of undocumented decisions. A WHERE clause excludes test accounts by a rule that exists nowhere except in that clause.

Score this as a coverage ratio rather than a schedule. Count the objects in migration scope. Then count the ones with an automated row-level and column-level diff running today, and divide the second count by the first. For an object with no diff, parity rests on somebody's reading of two queries.

Suppose a legacy warehouse holds 340 views and 120 stored procedures. A diff covering the views and skipping the procedures reports 74% coverage. The missing 26% holds the business logic finance will question, so treat that 74% as zero coverage.

Row-level and column-level diffing between two platforms turns an assumption of parity into a report a stakeholder signs. Teams that run the diff in CI from week one do not lose the quarter, and teams that treat parity as final QA usually do.

Sign 6. Nobody Can Say What a Column Means

Pick a table your business runs on and ask two analysts to define its fourth column without looking it up. If the answers differ, the definition lives in people's heads rather than the platform. An agent reading the schema has less to work with than either analyst.

Then measure the whole schema. Description coverage is a single query on any Snowflake account.

-- What share of one database's columns carries a description?
select count(*) as columns_total,
       count(comment) as columns_described
from snowflake.account_usage.columns
where deleted is null
  and table_catalog = 'ANALYTICS';

Ten thousand columns with 2,100 descriptions is 21% coverage. The threshold is 60% on the schemas your agents query. Below it, the agent infers the meaning of most columns from the column name alone.

Atlan's write-up of a Workday deployment names the same failure. Its revenue analysis agent could not answer a single question. Nothing mapped the word "revenue" to the authoritative tables and columns.

Documentation used to help whichever colleague read it. Now it is the input to every agent that touches the table.

Sign 7. Incidents Are Measured in Days

A dashboard is wrong on Monday, someone notices on Tuesday, and you track down the owner on Wednesday. If that sequence is familiar, the incident itself is the smaller cost. The larger one is the distrust that follows, because every stakeholder starts rechecking numbers they used to accept.

Your last ten incidents settle it. Record the hours between the first report and the named root cause, then take the median. A median above eight working hours means triage is a search rather than a lookup.

Then count the tools somebody opens during one of those triages. The person debugging reconstructs a dependency chain across a warehouse, an orchestrator and a BI tool that share no graph. Atlan's own diagnosis of agentic triage lands on the same constraint.

If lineage stops at the warehouse boundary, the agent finds the broken table and stops there.

Column-level lineage that crosses tool boundaries turns that reconstruction into a lookup. An agent that maps the downstream impact before acting can escalate instead of proceeding. Altimate documents that workflow in root cause analysis for a dbt, Tableau, or Snowflake workload spike.

Sign 8. Your Agent Works in One Warehouse and Nowhere Else

Warehouse-native agents work well inside their own platform. Google's BigQuery Data Engineering Agent reached general availability in April 2026, per the Google Cloud blog. Databricks ships Lakeflow with Agent Bricks, and Snowflake has Cortex.

The check is a coverage fraction. List every platform holding a table that something downstream depends on. List the platforms your agent layer can read, and divide the second count by the first.

Suppose you run Snowflake, a Postgres database behind the product, and a BigQuery project you inherited. An agent confined to one platform covers 33% of the estate, and the surprises come from the two platforms it cannot read.

Atlan states the tradeoff plainly, that warehouse-native agents see only their own platform. A portable agent layer connects to each platform through that platform's own driver rather than through one vendor's runtime. Our warehouse configuration reference describes how.

Sign 9. You Have No Answer for "Who Approved This"

Ask what happens when an agent proposes a schema change to a table holding regulated data. Suppose the answer routes through one person's judgment, with nothing written down. Then you have no governance layer.

Start with permissions. That check is the fastest of the nine checks and the only one where a single bad answer is unrecoverable. The other eight cost time and money. This one can destroy data.

-- Everything the agent's role may touch, regardless of today's task.
show grants to role AGENT_SERVICE_ROLE;

Read that list against what the agent's task needs today. Any grant beyond that is a standing privilege.

In July 2025 a Replit AI coding agent deleted a production database, and the agent had standing privileges to it. Nothing exotic happened. A capable agent held permissions broader than its task and used them.

Then check the record. Pick one agent action from last week and name:

• what changed,
• the policy that allowed it,
• what else it could have touched, and
• who was accountable.

If you cannot answer one of those four questions, the governance layer is missing rather than the paperwork.

A governance layer here covers less ground than the word suggests. It has three parts, and none of them requires a written policy framework.

• Scoped permissions give an agent the minimum access its current task needs.
• A confidence threshold routes a low-certainty action to a human instead of executing it.
• An immutable record names what changed, under which policy, and why.

Our governance configuration reference is one worked example of the three parts written down as configuration.

Regulated teams need the immutable record to deploy at all. Every other team needs it the first time somebody asks what happened. You are the trust layer covers how that responsibility distributes across a team.

How to Score Your Own Platform

You can score your own platform against these nine checks in an afternoon.

Four or more failing rows means the platform blocks your next agent pilot, and a stronger model changes none of those rows. The rows are independent, so each failing one is a project a single person can own.

Once execution and evidence live in one system, you can attribute a saving to the change that produced it rather than estimate it after the fact. Altimate's own platform customers average $840K a year on that basis.

Which Sign to Fix First

Start with the sign that costs most this quarter rather than the one easiest to fix. When the invoice is what you notice first, attribute spend to teams and models before you tune anything. When pull requests sit for days, add lineage and diffing to CI first.

When nothing is urgent, fix Sign 6 first. Column meanings take longest to build because they need the people who know the answers, and once those definitions exist they feed every other sign here.