Google Cloud Puts Agent Telemetry in Customer-Owned BigQuery Tables
Google Cloud's November 13, 2026 release routes agent telemetry into customer-owned BigQuery tables, with opt-in conversation logging, privacy guardrails and token quotas in preview.

Why it matters
- Google Cloud expanded agent monitoring and evaluation tools on November 13, 2026, landing telemetry in customer-owned BigQuery tables.
- Operational traces deliberately exclude prompts, responses, internal thoughts and generated SQL; conversation logging is opt-in per agent.
- Per-query BigQuery bytes-scanned caps are available, while daily token quotas per project, user or agent remain in preview.
- Looker System Activity dashboards and managed conversation logging are GA; token quotas, native evaluations and some feedback features are in preview.
- The open-source Prism tool writes evaluation runs to day-partitioned BigQuery tables alongside production agent_events records.
On November 13, 2026, Google Cloud expanded its AI agent monitoring and evaluation stack, landing operational traces, conversation logs and evaluation results in BigQuery tables that customers own and govern themselves. The release covers managed data agents and custom agents built with the Agent Development Kit (ADK) or LangGraph, and it arrives as enterprises push agents into production and demand the same auditability they expect from any other data workload.
The stakes are straightforward. Agent deployments fail quietly when nobody can see token spend, latency drift or bad SQL. Google Cloud's answer is a single telemetry layer routed through the customer's own warehouse, so oversight rides on permissions, encryption keys and network controls the customer already operates.
What shipped, and in what state?
Several core pieces are generally available (GA). BigQuery Studio's prebuilt dashboards track usage, active sessions, top knowledge sources and latency. Looker System Activity dashboards for Conversational Analytics are GA in both Looker (Google Cloud core) and Looker (original), covering engagement and token usage. User ratings and query review in the Responses & feedback tab remain in preview.
The system uses one telemetry path for first-party and custom agents. Managed Conversational Analytics agents emit telemetry automatically. Custom ADK or LangGraph agents send structured telemetry with single-line SDK instrumentation. Everything lands in customer-owned BigQuery tables, analyzable in Google Cloud's developer and administrator tools.
Google Cloud says custom agents can retain more diagnostic detail through the open-source ADK plugin, which can stream full tool-invocation trees, time-series telemetry and multimodal payloads into BigQuery. First-party conversation logging deliberately strips low-level tool arguments and internal SQL — a deliberate trade between diagnostic depth and exposure.
Why do operational traces exclude prompts and responses?
Privacy architecture is the centerpiece of the announcement. Google Cloud separates operational telemetry from conversation content so administrators and agent owners can govern the two layers independently.
Cloud Monitoring supplies aggregate metrics for request volume, latency and token usage. Cloud Trace provides step-by-step spans for each request, and Cloud Trace observability scopes can consolidate telemetry across multiple agent projects.
Critically, those operational metrics and sanitized first-party trace spans exclude customer core content, including:
- user prompts
- model responses
- internal thoughts
- generated SQL
The design matters because it lets platform teams monitor activity without automatically granting operational tools access to the substance of each interaction. Monitoring dashboards and full conversation transcripts sit behind different switches, owned by different people.
How does opt-in conversation logging work?
For deeper auditing, agent owners and editors can enable conversation logging for individual agents. A Google-managed service agent then streams prompts, responses and turn-level telemetry through the BigQuery Storage Write API into a customer-owned agent_events table.
The table inherits the dataset's identity and access management permissions, customer-managed encryption keys and VPC Service Controls — meaning the log inherits the customer's existing security perimeter rather than creating a new one.
Privacy guardrails run per turn, not per session. Before logging any turn, the system checks the knowledge source involved and skips logging for that turn when the source uses:
- row-level security
- column-level policy tags
- dynamic data masking
If a logging error occurs, the user's chat session continues uninterrupted. The overall design therefore distinguishes broad operational visibility from narrower, explicitly enabled access to full interactions — a boundary production teams will need to document when they plan deployments.
What about cost controls?
The logs also give teams a basis for managing spend. Each logged BigQuery conversation turn records input, output, thought, cached and total token counts alongside total turn latency. Looker System Activity separately reports estimated input and output tokens across business-intelligence workloads.
Two enforcement mechanisms pair that reporting with actual limits:
- Per-query caps on BigQuery bytes scanned, which use dry-run estimates to block oversized queries before they incur on-demand scan charges.
- Daily input and output token quotas for BigQuery and the Conversational Analytics API, now in preview. These can be applied per project, user or agent through the Google Cloud console or gcloud CLI.
The split is deliberate. Byte-scan caps stop query spending before execution. The preview token quotas extend enforcement to agent consumption itself, across projects, users and individual agents — the granularity teams need once agents, not analysts, drive warehouse traffic.
Where do evaluation results live?
Google Cloud's open-source Prism tool tests Conversational Analytics agents grounded in BigQuery tables or Looker Explores. It supports:
- reusable test suites
- regular-expression assertions
- multi-region agent discovery
Prism's evaluations focus on SQL accuracy and answer quality, run before prompt, model or schema changes reach users. Completed evaluation runs can be written to BigQuery tables partitioned by day, placing benchmark results alongside production agent_events records for combined analysis in BigQuery and Looker.
Native first-party BigQuery agent evaluations are separately available in preview through an API and a guided Colab notebook.
The placement is the point. When benchmark runs and production logs share one warehouse, teams can compare how an agent scored in testing against how it actually behaved in the field — the feedback loop most agent programs still lack.
Why does this matter beyond Google Cloud?
The announcement makes customer-owned BigQuery telemetry the common layer for monitoring, cost controls and evaluation. Agent oversight now ties directly into existing warehouse permissions and security controls rather than a separate, vendor-governed observability silo — a meaningful differentiator for regulated enterprises weighing agent platforms.
The rollout is staggered, and deployment plans should reflect that. Managed conversation logging and the main dashboards are GA. Token quotas, native evaluations and some Looker feedback features remain in preview. For production teams, Google Cloud notes, deployment design must account for both the boundary between operational traces and full conversations and the differing availability of each control — the gaps between preview and GA are part of the architecture, not an afterthought.
Source: unite.ai
More from Elena Vasquez
Show full bio
Market editor covering technology and product news in artificial intelligence and machine learning at AI In Context.
584 articles