BigQuery Agent Catalog’s real control plane is narrower than its chat surface

Google Cloud is running a 45-minute BigQuery Agent Catalog lab on September 10, and its agenda is unusually concrete: participants create a curated data agent, add business context and verified queries, then publish it for colleagues rather than stopping at raw text-to-SQL. The session is scheduled for 03:30–04:15 UTC. (Google Cloud Labs: OnAir)

The authoring contract

The companion codelab exposes the configuration objects practitioners actually have to own. An agent can be grounded with tables, views or UDFs; Gemini can propose table and column descriptions; free-form instructions define synonyms, key fields, exclusions, filters, groupings and joins; verified queries encode tested SQL; and glossary terms can be imported from Dataplex Universal Catalog. The lab also demonstrates previewing an agent with unsaved metadata before publishing it. (Google Codelab)

That sequence matters. It makes the deployment unit a reviewed configuration—not merely a prompt—and separates drafting, testing, publishing and sharing. Once published, the codelab says the same agent is available in BigQuery Studio, the Conversational Analytics API and Looker Studio Pro, subject to licensing. (Google Codelab)

Sharing is not the execution boundary

Google defines five predefined roles spanning owner, creator, editor, user and viewer, and permits grants at either project or individual-agent scope. Those roles govern who may create, edit, share, chat with or view an agent. (Google Codelab)

The current product overview adds the more important runtime boundary: conversational analytics can access only explicitly selected knowledge sources and only data the caller is authorized to access. It respects VPC Service Controls, cannot perform writes or DML, and cannot execute remote functions. Conversations are private to their creator rather than shareable artifacts. (BigQuery documentation)

For a deployment review, test both layers separately: Who can modify or invoke this agent? and What can a permitted invocation actually read or execute? A clean IAM matrix does not replace source scoping, and source scoping does not replace caller-level warehouse permissions.

Watch the version skew

The July codelab says an agent can use up to 50 knowledge sources, while the current overview says the maximum is 100. The same overview recommends splitting agents when they require more than 20 sources, span teams with different metric definitions or contain competing result priorities. (Google Codelab; BigQuery documentation)

Treat that mismatch as documentation version skew, not a capacity promise. Validate the console and API limits in the target project, then design for the lower operational threshold: ambiguity and conflicting instructions can arrive long before the hard maximum.

Cost deserves the same treatment. The lab demonstrates a per-query maximum-bytes-billed setting of 10,000,000,000 bytes, approximately 9.3 GB, while Google’s overview recommends project-, user- and query-level spending limits. Queries are billed under BigQuery compute pricing. (Google Codelab; BigQuery documentation)

The practical launch checklist is therefore short: validate verified SQL, preview before publishing, grant the narrowest agent role, verify caller-level data access, enforce query spending limits, and keep each agent’s business domain smaller than the platform maximum.