Google’s analytics-agent observability separates model cost from warehouse cost

Google Cloud has launched managed observability for its Conversational Analytics agents, adding a missing production control for natural-language-to-SQL: the ability to trace one answer across metadata retrieval, model work, generated SQL and warehouse execution. The Sept. 1 staff announcement says the feature emits OpenTelemetry spans, Cloud Monitoring metrics and built-in BigQuery and Looker dashboards without custom instrumentation. Google Cloud staff announcement

One question, two cost systems

An analytics-agent answer can consume both model tokens and database compute. Google’s launch explicitly exposes token consumption alongside execution latency and trace status, while the linked BigQuery documentation lists model calls, tool usage, health, latency and token usage among the available metrics. That makes it possible to distinguish an expensive prompt from an expensive generated query instead of treating the entire conversation as one opaque bill. Google Cloud staff announcement BigQuery data-agent documentation

The staff post goes further with a recursive SQL example that walks parent-child spans from the root chat turn to execute_tool spans, then groups BigQuery slot time and bytes processed by agent and user. It also shows a cross-project query for input, cached-input, output and reasoning tokens. Those examples turn agent traces into a FinOps dataset rather than a debugging screen alone. Google Cloud staff announcement

What platform teams should test

First, enable observability in a non-production project and confirm that one known question produces the expected model-call, tool-call and SQL-execution spans. The feature is disabled by default; Google documents separate permissions for creating and binding observability settings, plus viewer roles for Monitoring, Trace, logs and BigQuery data. BigQuery data-agent documentation

Second, run paired questions: one with a deliberately long prompt and another that scans a large table. The first should make token usage visible; the second should surface warehouse consumption and latency. Google’s announcement identifies schema resolution, model reasoning, SQL generation and query execution as distinct trace stages, while its example attributes BigQuery slot milliseconds and processed bytes to individual agents. Google Cloud staff announcement

Third, decide retention before rollout. Google says metrics begin only after observability is enabled and are not backfilled. Cloud Trace data is retained in an observability dataset for 30 days; longer retention requires moving trace data to BigQuery. BigQuery data-agent documentation

The practical shift is straightforward: an NL2SQL answer can now be reviewed as a chain of measurable operations, not just a final chart. Teams should use that record to set separate alerts for model usage, warehouse spend, latency and execution errors—and to prove which stage caused a bad or costly answer. Google Cloud staff announcement