BigQuery will happily execute whatever SQL your agent invents.
That is the feature and the failure mode, in one sentence.
The engine has no opinion on meaning
BigQuery's job is execution and it is excellent at it — petabyte scans, sub-second aggregates, separated storage and compute. It has no view on whether the query it just ran meant what the asker intended.
Point an agent at it directly and you get fast, expensive, confidently wrong answers.
What the missing layer has to supply
| Need | Why BigQuery alone doesn't cover it |
|---|---|
| Resolved definitions | Column names are not business meaning |
| Proven join paths | Including across datasets and outside BigQuery |
| Compile-time policy | Authorised views are per-view, not per-intent |
| Dialect-perfect GoogleSQL | Generic SQL loses BigQuery-specific semantics |
| Slot cost control | An agent retry loop is a billing event |
The cross-dataset row matters more than it looks. Authorised views and row-level policies work well inside BigQuery — but they stop at the BigQuery boundary, and your estate almost certainly doesn't.
The shape that works
Intent → context resolution → constrained planning → governed execution.
An agent sends intent. The semantic graph resolves which entities and metrics are involved, at which grain. The planner proves a join path exists — and fails compilation if it doesn't, rather than improvising one. RBAC and ABAC predicates are injected for the caller. Only then is GoogleSQL emitted and run.
Get that right and BigQuery becomes a very strong execution engine for agent workloads. Skip it and you have built a high-throughput way to be wrong at scale, with a slot bill to match.
The full breakdown — the reference architecture, GoogleSQL generation specifics, and how policy composes with authorised views — is here:
👉 Semantic Layer for BigQuery: Governed, Deterministic SQL for Your AI Agents
Originally published at colrows.com/blogs/semantic-layer-for-bigquery
Top comments (0)