← AUTOMATER NEWSROOM

Google Cloud Puts Agent Traces, Transcripts and Token Caps in BigQuery: What Changed on Nov. 13

Google's Nov. 13 Data Cloud update lands agent traces, transcripts, cost caps and eval runs in BigQuery tables you own, and leaves goal correctness open.

Flat diagram of four boxes in a row: data agents in BigQuery, Looker, ADK and LangGraph feed telemetry through Cloud Monitoring and Cloud Trace into a customer-owned agent_events table in BigQuery, which then feeds dashboards, scan caps, token quotas and Prism evaluations. Three cards below explain the fail-closed privacy check, fail-open execution on logging errors, and the byte scan cap plus daily token quotas.Flat diagram of four boxes in a row: data agents in BigQuery, Looker, ADK and LangGraph feed telemetry through Cloud Monitoring and Cloud Trace into a customer-owned agent_events table in BigQuery, which then feeds dashboards, scan caps, token quotas and Prism evaluations. Three cards below explain the fail-closed privacy check, fail-open execution on logging errors, and the byte scan cap plus daily token quotas.
Original diagram of the Google Cloud agent observability pipeline announced on November 13, 2026: first-party and custom agents stream telemetry into a customer-owned agent_events table in BigQuery, and the same table drives dashboards, byte scan caps, token quotas and Prism evaluation runs. The three cards reproduce the announcement's fail-closed privacy check, fail-open execution behaviour and cost controls.

Google Cloud announced expanded AI agent observability and evaluation across Google Data Cloud on November 13, 2026, in a post titled New AI agent observability and governance across BigQuery and Looker. What matters is where the evidence lands: managed conversation logs, custom-agent telemetry, token counters and evaluation runs now land in BigQuery tables you own, beside the governed data those agents query. The week’s other launches, including Claude Fable 5.2 in Model Garden, sit in What’s new with Google Cloud.

Google Cloud Blog post headed "New AI agent observability and governance across BigQuery and Looker", dated November 13, 2026, by product managers Kate Grinevskaja and Snigdha Jha.
Source: Google Cloud Blog, November 13, 2026. The capture shows the announcement page for expanded AI agent observability and evaluation capabilities across Google Data Cloud, including its title, publication date and byline. · Original source

What shipped

Google frames the announcement around three operational problems: tracing reasoning while protecting sensitive data, controlling token spend, and evaluating accuracy before changes reach users.

Capability State Lands in
Conversation logging in BigQuery GA Tables you own
Conversational Analytics API audit logs GA Cloud Audit Logs
BigQuery agent monitoring dashboards GA BigQuery Studio
Looker System Activity dashboards GA Looker
Daily token quotas Preview Console and gcloud CLI

First-party agents in BigQuery and Looker emit telemetry with no setup, while custom agents built with the Agent Development Kit or LangGraph stream the same structured telemetry through single-line SDK instrumentation. Queries routed to BigQuery data agents through agent-to-agent workflows, now GA, send Cloud Monitoring metrics, Cloud Trace spans and conversation logs into the agent’s project.

The privacy rule worth reading twice

Google splits operational telemetry from conversation content and governs the two separately. Cloud Monitoring metrics and Cloud Trace spans can be enabled per project, and those sanitized spans deliberately exclude user prompts, model responses, internal thoughts and generated SQL. Deeper transcript auditing is opt-in per agent: a Google-managed service agent writes prompts, responses and turn-level telemetry into a customer-owned agent_events table through the BigQuery Storage Write API, inheriting IAM permissions, CMEK and VPC Service Controls.

The guardrail is the part worth reading twice. Before each turn, a fail-closed check skips logging whenever a knowledge source uses row-level security, column-level policy tags or dynamic data masking; execution then fails open, so a logging error never interrupts a chat session. Where your data is most protected, your transcript has holes by design: a missing turn in agent_events may be a policy outcome rather than a bug, so confirm which before you call it a failure.

The cost controls

Each logged turn records input, output, thought, cached and total token counts with turn latency, and Looker’s System Activity reports estimated tokens across BI workloads. Two levers matter more than the dashboards: per-query BigQuery byte scan caps that use dry-run estimates, so an oversized query is blocked before it incurs on-demand scan charges, and daily token quotas enforceable per project, user or agent.

# Cost controls Google names for BigQuery data agents
big_query_max_billed_bytes   # per-query scan cap, evaluated with dry-run estimates
# plus daily input and output token quotas (preview), enforced per project,
# user or agent in the Google Cloud console and the gcloud CLI

With promotional trial pricing available for Conversational Analytics, now is a good moment to set baseline usage and cost guardrails.

Evaluation, in the same table

Prism, Google’s open-source evaluation tool, tests Conversational Analytics agents grounded in BigQuery tables or Looker Explores using reusable test suites and regex assertions. Completed runs stream into day-parted BigQuery tables in your project, placing pre-deployment benchmark scores beside production agent_events logs. The join is the point: which prompt version regressed answer accuracy, and what it cost.

What the release cannot tell you

Everything above measures execution, not whether the agent was solving the right problem.

Three stacked horizontal bands connected by a downward arrow. Band one, Execution measured, lists spans, tool calls, latency and token counts from Cloud Trace, Cloud Monitoring and agent_events. Band two, Outcome benchmarked, lists Prism test suites and the XYBench finding that models focused on the underlying goal in 35 to 41 percent of answers against 55 percent for humans. Band three, Goal designed, lists scoping the agent for fast human review and the XYBench oracle result.Three stacked horizontal bands connected by a downward arrow. Band one, Execution measured, lists spans, tool calls, latency and token counts from Cloud Trace, Cloud Monitoring and agent_events. Band two, Outcome benchmarked, lists Prism test suites and the XYBench finding that models focused on the underlying goal in 35 to 41 percent of answers against 55 percent for humans. Band three, Goal designed, lists scoping the agent for fast human review and the XYBench oracle result.
Original diagram separating three layers an agent program must answer: execution (traces, token counts, spend), outcome (benchmark scores such as Prism and XYBench), and goal (what the user actually wanted). The Google Cloud release of November 13, 2026 populates the first layer; the Ai2 and LangChain pieces of November 13 and 14, 2026 address the other two.

Ai2’s XYBench, published November 13, 2026, puts 8,115 real questions behind that gap. On Stack Overflow responses, models focused primarily on the underlying goal in only 35 to 41 percent of answers, against 55 percent for the top human reference answers, and steered users away from their mistaken approach in 47 to 60 percent of cases versus 79 percent for humans. The oracle experiment is sharpest: handed the intended request alongside the stated one, Claude Sonnet 4.6 raised its underlying-goal solution rate from 59 to 67 percent while its misconception-identification rate fell from 47 to 34 percent. Detect the intent and still fail to act on it.

LangChain’s goal engineering essay, dated November 14, 2026, argues the same gap from the design side: scope an agent so a human can review its work quickly and give good feedback, because the bottleneck for long-horizon agents is learning from feedback. Actively AI’s “motions” are the concrete version, grouping similar tasks so one salesperson can judge many at once and one correction transfers across them.

Google gives you the evidence layer: traces, transcripts, token counts, quotas and benchmark runs, all governed and queryable. Neither release defines done for an open-ended goal, so you still have to write the goal down in a way a human can judge.

What to do first

  1. Enable Cloud Monitoring and Cloud Trace for one agent project, and read the fail-closed rule before enabling conversation logging on a masked or row-secured source.
  2. Set a per-query byte scan cap on the agent with the largest scan surface, then add a daily token quota per project or user. A quota only in a dashboard is a report, not a control.
  3. Instrument one custom ADK or LangGraph agent so custom and first-party telemetry land in one table, and write one Prism suite against a table users query.
  4. Write the goal next to the request, then check whether the agent repeats the request. If it does, the trace will look healthy and the answer will still be wrong.

Read next

Sources

  1. Enterprise AI agent observability with BigQuery and Looker | Google Cloud Blog
  2. Google Cloud latest news and announcements | Google Cloud Blog
  3. Goal Engineering
  4. XYBench: Helping with the problem behind the question | Ai2