AI agents weaken this checkpoint.

A data agent can check metadata, select data sources, write SQL, and use the results to recommend next steps. Some systems can also call tools that trigger a workflow or modify a campaign. The data warehouse thus becomes part of a system that can act based on query results.

This is precisely where a problem arises that many older data warehouse architectures are not designed to address. An agent can generate valid SQL and correctly calculate the requested metric. However, it might still recommend the wrong action because, while the warehouse provides the data, it doesn’t provide the business rules that tell the agent how to use that data or metric.

A Queryable Warehouse Is Not Automatically Agent-Ready

At first glance, a sophisticated cloud data warehouse might appear AI-ready. The data is centrally located, pipelines are monitored, permissions are configured, and tables have descriptions. Such measures facilitate access. However, they don’t guarantee that the agent will read the data the way the business intends.

A schema can tell an agent that campaign costs are a numerical value. But it doesn’t explain whether agency fees are included, currencies have been standardized, or refunds have already been deducted. Nor does it show whether the latest conversion data has been fully processed.

Current BigQuery data agents rely on selected knowledge sources and metadata, as well as use-case-specific instructions for query processing. They don’t rely solely on table names. Natural language analytics requires written rules for how the business defines each metric.

In data infrastructure projects, I’ve often seen metric definitions embedded partly in the transformation logic and partly in dashboard formulas. Other rules exist only in documents or in the minds of analysts. That arrangement becomes fragile when software has to decide what the numbers mean without an analyst.

When Correct SQL Produces the Wrong Decision

Consider a composite scenario based on patterns I have encountered in multi-source campaign analytics.

A company aggregates platform data on ad spend, clicks, conversions, and attributed revenue. The reporting layer normalizes currencies, considers attribution windows and exclusion rules, and tracks delayed conversions.

The company asks an analytics agent which campaigns should be paused today to protect ROAS.

The agent selects tables whose names match the query and generates valid SQL. It calculates the metric correctly and then ranks the lowest-performing campaigns. The query is executed and returns a result, but the recommendation remains incorrect.

On one platform, the conversions haven’t fully loaded yet. Another shows revenue before cancellations are accounted for. A third uses a different time zone for reporting. The dashboard the company uses for reporting handles these differences, but the agent chooses raw source tables because their names match the question more closely.

None of this is a hallucination. The warehouse made the tables queryable, but not the underlying rules.

Traditional Governance Solves Only Part of the Problem

Access Control Does Not Govern Interpretation

Traditional governance asks who is allowed to query a table or view a sensitive column. With agents, another question arises: Even if the agent has access to the data, is that data suitable as a basis for decision-making?

Table descriptions rarely define valid relationships or authoritative metrics. They also typically lack the granularity of the dataset, expectations regarding recency, mandatory filters, and known limitations.

A semantic layer can make these rules explicit. Semantic views in Snowflake, for example, define business entities over physical data, including facts, metrics, dimensions, and relationships. The underlying principle is vendor-neutral: An agent should query a governed business model rather than reconstructing it from raw schemas.

An analyst might notice if the granularity doesn’t match. An agent can transform that same error into a plausible explanation.

A Fresh Table Can Still Be Incomplete

Pipeline monitoring often treats recency as a technical status. The job is complete. The table has been updated.

However, a current table can still be unsuitable for decision-making. Campaign costs might be available within minutes, while conversions are only reliable after several hours. A financial table might be sufficient for reporting, even though it’s not yet reliable enough for an automated pricing recommendation.

An agent-enabled data warehouse must demonstrate whether the data required for a decision is complete, not just when the table was last updated.

In a campaign scenario, the agent might need to state that the spend data is current, but two platforms remain incomplete, and therefore any recommendation to pause is provisional.

The Missing Layer Is a Decision Contract

I consider the missing architecture layer to be a decision contract.

A data contract defines what a producer must deliver. A decision contract specifies how an automated system may use this data for a particular class of decisions.

For a campaign budget recommendation, the contract would specify the approved data source, the minimum historical time frame, and the definition of the metric. It would also specify how old the data may be, which completeness checks must pass, which filters are allowed, and whether the agent may recommend a change or execute it.

It could prescribe normalized media costs and the attributed net revenue. It could also exclude platforms where attribution windows are still open and allow the agent to recommend a change but prohibit direct execution.

The accompanying diagram for the decision contract shows a machine-readable format. Versioning allows teams to review changes to these rules along with the data models and policies they depend on.

Why this contract is important

It helps teams narrow down the origin of an erroneous result. If an answer is incorrect, they can examine each layer individually: source data, freshness rule, semantic model, generated query, and action policy. Without those boundaries, teams are left with a vague conclusion: the AI produced a bad answer.

The contract should evolve with the data platform. Changes to the attribution model or the approval threshold can affect which recommendations are valid.

Build a More Secure Query Path for Agents

Put a Semantic Interface in Front of Raw Data

An agent shouldn’t start with thousands of raw tables, but rather with interfaces for specific business areas such as campaign performance or customer health.

Each of these interfaces should define the shared metrics and document the underlying joins or entity relationships. Granularity, the responsible team, the update frequency, and known limitations are equally important. Analyst-reviewed examples of questions and queries can further illustrate how to understand recurring analyst questions.

The shared interface should be the default access point. Access to lower levels may still be necessary, but raw data tables require stricter controls because they expose implementation details and only partially processed data records.

Add a Safety Boundary Before Execution

Generated SQL should first be run through a query execution service that validates and limits the query before it is executed against the database.

In BigQuery, a dry run can validate a query and estimate the number of bytes processed without actually executing it. Limits on the maximum billable bytes can stop a query if the estimated scan exceeds a defined threshold.

A central execution service can enforce read-only access, result size limits, approved datasets, timeouts, and blocked statement types. It can also reject formally valid queries if they use an unapproved source or merge incompatible granularities. Rules regarding required data coverage should also be enforced there.

The service should log why it allowed or rejected a query. It must also record whether the cause was a model error, a policy rule, or a data issue.

Separate Recommendation and Action

The agent that reads data should not automatically be granted permission to update operational systems.

As part of the principle of least privilege for AI agents, Microsoft recommends that each agent should have its own identity, limited permissions, audit logs, controlled tool access, and revocable access.

An Analytics agent can recommend pausing a campaign. However, the actual execution should be handled by a separate approval service that first verifies the identity of the user and agent and then checks whether action boundaries and approval status allow execution.

The model interprets the data and recommends an action. Rule-based checks determine whether this action may be executed.

Query Logs Are No Longer Enough

A response used as the basis for a decision should clearly identify the approved source and the metric definition, including the data freshness and time period covered. It should also disclose which data was excluded and any known limitations so a reviewer can check whether the answer rests on the right data before acting.

Traditional warehouse observability logs the SQL statement, its runtime, the bytes processed, and the execution status. This captures the database operation but not how the response was generated.

Teams also need the original query and the context provided by the user. They need to see which metadata was retrieved, what SQL it generated, which tools were used, and what the result was. The final interpretation and any resulting actions must also be traceable.

BigQuery Agent Analytics captures queries and responses, along with tool calls and error logs, for later analysis.

A query log can demonstrate that the calculation was correct. The interaction trace, on the other hand, can reveal that the agent ignored a completeness warning, selected a table that was not authorized, or interpreted gross revenue as net revenue.

Start with One Decision, Not the Entire Data Warehouse

Do not expose all warehouse data and add controls later. Instead, start with a recurring decision that has a clearly defined owner and whose impact can be measured.

A marketing team might start with the recurring question: Which campaigns are likely to miss their monthly conversion goal? The first version should only answer this question and disclose the basis for the decision. Only add recommendations after testing for missing data, metric conflicts, unclear queries, and assumptions that could lead to incorrect actions. Execution should be the very last step.

Testing Plausible-Sounding but Risky Queries

Good tests are ordinary questions that assume something false.

Pausing every campaign that performs below average ignores campaign size, duration, and attribution lag. Extrapolating the month’s performance solely from yesterday’s conversions might overlook seasonality or incomplete data. Excluding campaigns with missing revenue data can mask a flaw in the system providing that revenue data.

A high-performing agent should clearly identify what makes a question unreliable. If the information is insufficient for a decision, it should ask for clarification or refrain from recommending any action.

The Real Upgrade Is Context

Traditional warehouses have helped informed humans explore approved data. Agent-ready warehouses must support software in interpreting data without implicitly inventing business meaning.

This transition doesn’t require replacing every pipeline. The crucial element is a controlled layer between the user’s request and the query or action. This layer must define each metric and specify how up-to-date the data needs to be for each decision. It must identify the agent, restrict its queries, specify which documents it must cite, and limit which actions it is allowed to perform.

More tables don’t automatically lead to better decisions. A safer approach is a design that provides only the shared tables, definitions, and permissions necessary for precisely one decision.

A warehouse is only truly agent-ready when it can do more than simply answer an agent’s query. It must also inform the agent if the available data does not allow for a reliable answer or if the data is incomplete, outdated, or not authorized. Furthermore, it must prevent recommendations from becoming actions when the evidence is insufficient.