BLOG  /  GOOGLE CLOUD

AI Maestro on Google Cloud: a reference deployment and what we tested

AI Maestro · October 28, 2026

We ran AI Maestro on Google Cloud as a test deployment: four agents on one virtual machine, answering support questions about business data, reachable from Google Chat. This post is the reference setup that came out of it. It is written for someone who has to do the same and wants to know what to build, in which order, and where the surprises are.

How sure we are. Everything described was built and run on a real project. Two parts are not fully proven, and we say which: the Google Chat gateway was tested with Chat events published to its Pub/Sub topic, not yet with a person typing in the Chat app of a live Workspace; and we only tested a single VM.

The shape of it

• One Compute Engine VM (Ubuntu 24.04, e2-standard-4, 100 GB disk) in a private subnet of an existing VPC. It has no public IP. Outbound traffic goes through the project’s Cloud NAT.
• The dashboard through Identity-Aware Proxy. AI Maestro has no login of its own, on purpose: the network is the boundary. So we did not expose it. People who need the dashboard open an IAP tunnel (gcloud compute start-iap-tunnel), which checks their Google identity first.
• Models from Vertex AI, with no API keys. The VM’s service account has the aiplatform.user role and nothing else for models. Claude Code reaches Claude Haiku 5.5 through Vertex AI; Pi reaches Gemini. In our project, Claude on Vertex needed an administrator to enable it in Model Garden and answered only on the global endpoint (regional endpoints returned quota errors); your project may differ.
• Google Chat through Pub/Sub, with no public URL. A Chat app publishes events to a Pub/Sub topic; a gateway on the VM pulls them and replies through the Chat API. The VM has no public listener in our test.
• Business data through a small read-only service, not through the agents. The agents have no database credentials and no general shell (only the messaging commands). They call a Cloud Run service (internal ingress, its own service account) that accepts only one SELECT against an allowed dataset, or a fixed lookup of one record. A connector on the VM exposes it to the agent as two or four tools.

The pieces that were not obvious

1. Keyless Chat tokens on a VM. A VM token carries only the broad cloud-platform scope, and the Chat API refuses it (“insufficient authentication scopes”). The gateway now supports GCHAT_IMPERSONATE_SA: the VM account asks the IAM Credentials API for short-lived chat.bot tokens for a service account. No key file exists anywhere.
2. A domain policy that blocks Google’s own publisher account. The organization’s “domain restricted sharing” policy refused to let chat-api-push@system.gserviceaccount.com publish to our topic. The Workspace add-on format of the Chat app avoids it: its service agent belongs to the project, and it exists only after the app is saved.
3. Agents created before the organization is set get no usable messaging identity. Initialize them with amp-init --tenant <org> after setting the organization, or create them afterwards.
4. Cloud Run reserves /healthz. Our health endpoint answered 404 until we noticed.
5. Internal ingress works from a VM in the same VPC when the subnet has Private Google Access; the same URL from outside returns 404.
6. Permission design for data. The view the agent needs reads five other tables, and none was readable by the service account. We granted read on those tables only, not whole datasets, and kept the columns the agent can see in the service’s fixed query, so the service does not return those columns.
7. Re-authentication. The administrator account we used was forced to sign in again every few hours, which stops automation that runs as a person. A dedicated service identity is the cleaner answer for long jobs.

What it did

We asked the four agents support questions in Spanish, sent as Google Chat events from an untrusted outside user: questions about single business records, summary questions, and safety checks such as asking for personal data, for a shell command, or for a change to a record. The agents answered the business questions and declined the unsafe requests. This was a small functional test, not a benchmark, and we publish no performance or cost figures.

What we did not test

• A person typing in a live Google Chat app. The Chat side was exercised through Pub/Sub; the live-Workspace test is next.
• AI Maestro on GKE or Cloud Run. AI Maestro keeps terminals and agent folders alive between requests, which is why we chose a VM. We did not try to containerize it.
• More than one VM, or agents moving between hosts, on Google Cloud.
• Anything about cost at volume; we publish no cost figures.

Reproduce it

The pieces are in the open: the Chat gateway (aimaestro-gateways, google-chat-gateway), scripts/install-claude-vertex.sh and scripts/install-pi.sh --vertex in AI Maestro, and the plugin’s --permissions messaging profile (plugin 1.18.5) for agents that talk to outside people. The read-only query service is specific to one organization’s data and is not part of the release.

Claude is a trademark of Anthropic. Gemini, Google Cloud, Vertex AI, Google Chat and Pub/Sub are trademarks of Google LLC. Pi is published by earendil-works under the MIT license. AI Maestro is not affiliated with or endorsed by them.