BigQuery’s managed agent handoff works only when project and region boundaries line up
Google’s streamlined route removes copied A2A cards and hand-built OAuth credentials in the simplest topology—but cross-project deployments still need manual registration.
Google has documented a streamlined way to publish a BigQuery data agent into Gemini Enterprise, but the convenience depends on two deployment choices that are easy to miss: the products must share a Google Cloud project, and the agent’s storage region must match the Agent Gateway registry binding.
The shortest path has two gates
The recommended path uses Agent Registry. A data analyst creates the agent in BigQuery, chooses a storage region, publishes it, and selects Register this agent. A Gemini Enterprise administrator can then find the registered agent and import it. With default Google-managed credentials, Google handles the OAuth credentials rather than requiring the administrator to enter a client ID and secret.
That path is not topology-neutral. The automatic BigQuery registration option is available when BigQuery and Gemini Enterprise are in the same project. The agent’s storage region must also match both its data sources and the Agent Gateway configuration; Google lists US, EU and Global as the available choices. The region cannot be changed after the agent is saved.
That makes project and region selection part of the agent interface, not just infrastructure housekeeping. A team that creates the agent in the wrong region cannot repair the mismatch by editing the existing agent later.
Cross-project deployment restores manual work
When Gemini Enterprise sits in a different project, the analyst must copy the agent’s Agent2Agent endpoint JSON from BigQuery. The administrator then manually adds an A2A agent to Agent Registry in the Gemini Enterprise project, selects a matching region and pastes the JSON. Google also documents a direct custom-agent route that imports the A2A card JSON without the registry shortcut.
Managed credentials are still an authentication option during provisioning, so “cross-project” does not automatically mean “bring your own OAuth client.” But it does mean the deployment loses the simplest auto-registration flow and introduces a handoff between the BigQuery analyst and Gemini Enterprise administrator.
Publishing does not grant use
Registration and provisioning are separate from user authorization. After publishing, the analyst must share the BigQuery agent with the relevant users or groups and grant the Gemini Data Analytics Data Agent User role. The Gemini Enterprise administrator must also share the imported agent in that application. Users complete a one-time OAuth sign-in before chatting with it.
Once enabled, the agent can be opened from the Agent Gallery, invoked by direct link or @mention, or selected automatically by Gemini Enterprise for a general analytical question. Responses can stream back as text, Markdown, charts or tables, and conversation history is saved.
The practical deployment checklist is therefore four-part: choose a region that all components support, decide whether the products can share a project, register or transfer the A2A card accordingly, and grant access on both sides. Google’s managed path removes credential plumbing; it does not remove architecture or authorization decisions.
sources
- Google Cloud: Create data agents — publish a data agent in Gemini Enterprisedocs.cloud.google.com
comments · 0