omarcevi.dev / workshops / cloud-agents-workshop

Workshop · Google Cloud Day Türkiye, Builder Connect · Tue 27 Oct 2026 · Omar Elcircevi

Deploying your agents on Google Cloud Agent Platform

In about 40 minutes, you move a multi-agent HR and IT assistant from a repo to a production setup. The agent runs on Agent Runtime with its own Agent Identity and uses Memory Bank. Agent Gateway checks each tool call, each turn makes a trace, and an eval gate controls each deploy.

Open in Cloud Shell → Code on GitHub Start with step 1
Workplace Assistant architecture. (1) Employees send requests to the workplace-assistant agent on Agent Runtime through Gemini Enterprise, agents-cli or Cloud Shell. The agent has sessions, Memory Bank and its own Agent Identity. (2) Agent Gateway receives each outbound call. (3) IAP compares the call with the access policy for the agent identity and with Agent Registry. (4) Allowed calls go to the HRIS and ticketing MCP servers on Cloud Run and to Gemini. Optionally, they also go to Google Calendar with the OAuth token of the employee. Agent Gateway refuses calls to the compensation MCP server. (5) Spans, logs and metrics go to Cloud Trace, Cloud Logging and Cloud Monitoring. An Online Monitor gives scores to live traces.
What each participant deploys in their own project. Click or tap the diagram to see it at full size.

What you build

Workplace Assistant is one entry point for HR and IT questions at Kuzey Labs, a fictional company. All the employees, salaries, tickets and handbook pages are fictional.

Agent architecture. The concierge sends each request with transfer_to_agent to one of three specialist agents. hr_policy_agent uses handbook_search and get_salary_band from the compensation MCP server. leave_agent uses the HRIS MCP server and an optional create_calendar_event tool with 3-legged OAuth from Auth Manager. it_desk_agent uses the ticketing MCP server and handbook_search. Each agent loads the memories of the employee before it answers. A MemoryBankPlugin saves each turn.
The agents in the app: which agent answers which request, and the tools that each agent can call.
  • concierge sends each request to the correct specialist agent. It answers greetings and general questions, and it refuses all requests outside HR and IT.
  • hr_policy_agent answers questions with text from the handbook (in-process BM25 search in six Markdown files). It also finds the published salary bands.
  • leave_agent reads leave balances and books leave in the HRIS, which is an MCP server. It can also add the leave to the Google Calendar of the employee.
  • it_desk_agent opens tickets in the ticketing MCP server and gives their status.
  • A third MCP server, compensation, contains individual salaries. The code of the agent can call it. In step 4, a policy stops these calls.

Before you start

  • A Google Cloud project with billing enabled. You must have the Owner role, because the lab grants IAM roles and binds an access policy. A new project is the easiest option.
  • A browser. All the commands run in Cloud Shell, which already has gcloud, uv, git and Python.
  • agents-cli 1.11 or later: uv tool install --force "google-agents-cli>=1.11". Step 1 installs it, because the agents-cli in Cloud Shell is an older version.
  • The europe-west1 region. All the products in the lab are available there. The model runs on the global endpoint, and step 2 tells you why.
  • Cost: about USD 1 for each participant, mostly for Gemini tokens. Run the teardown at the end.
PREVIEW FEATURESSemantic governance policies and Agent Identity on Cloud Run are Preview features. The main path of the lab uses only generally available features. Steps 4 and 6 each have a fallback script. If a feature is not available in your project, use the fallback script.

The six steps

Each step has the same parts. It starts with how it works (one diagram), the commands to paste and the output that you get. It ends with a check (./scripts/check.sh N), if this fails, and a box with the title Take this to a customer.

Agenda (60-minute session)

  1. 0:00Intro: what we build, the architecture, the six steps (slides)
  2. 0:08Steps 1–2: set up and deploydeploy: ~5 min
  3. 0:21Step 3: Memory Bank
  4. 0:27Step 4: Agent Identity and Agent Gatewayredeploy: ~4 min
  5. 0:35Steps 5–6: traces, evals, Online Monitors
  6. 0:47Runtime choice, production checklist, Q&A, teardown

How the lab works

Checkpoint branches. The branches step-0-start … step-6-evaluate contain the repo as it is after each step. If you join late or your copy does not work, change to the branch of the last step that you completed. Then continue. ./scripts/check.sh without an argument checks the step of that branch.

git fetch origin
git checkout step-3-remember   # state after step 3
./scripts/check.sh             # checks step 3

The branches change only files. They do not change your cloud resources. If you did not do an earlier step in your project, run its commands first. You can safely run each script again.

Use one terminal tab for the full lab. Later steps use variables that you set in earlier steps. A deploy takes approximately 5 minutes. Read the guide while it runs.