But a brain isn’t enough. Now we need to give it a personality and a purpose. We need to teach it how to talk, what to do, and when to do it.

Welcome to Building Enterprise Agents, a series where we explore the key features needed to build robust, production-ready AI assistants. In this series, we’re covering the entire stack:

• Part 1: 📚 Knowledge Base Management: How to manage, ingest, and ground your agent in your company’s documents, data warehouse, and more.
• Part 2: 🗣️ Conversational Modeling (This Article): How to integrate agents into Gemini Enterprise, to design and control the conversation flow and blend generative and deterministic responses.
• Part 3: 🎨 UX/UI & Accessibility: How to customize the UI of your Gemini Enterprise with custom branding and embed it across your organization.
• Part 4: 📈 Architecture & Monitoring: How to observe and monitor metrics for your agents on Gemini Enterprise.
• Part 5: 🛡️ Integration & Security: How to securely connect your agents to your business data and tools, with personalized authorization.

This article tackles the core of the agent’s logic: Conversational Modeling, where we design the “playbook” that controls how the agents interact with a user.

LLM, Agents, Agentic AI?

Before we continue, let’s clear up some jargon. The terms in the title are not just synonyms; they describe a specific evolution in capability — from passive text generators to autonomous, collaborative systems.

Evolution of the term “Agent”

• LLM + prompt: It starts with a basic LLM that generates text based on a given prompt.
• LLM + retrieval (RAG): To improve accuracy and access up-to-date or domain-specific information, RAG (Retrieval-Augmented Generation) was added. This allows the LLM to retrieve relevant information from external sources before generating an answer without the need for retraining.
• LLM + retrieval + actions (Tools): The system’s capabilities were further expanded by adding Tools, enabling the LLM to not just retrieve information but also perform actions in the real world (e.g., calling an API, sending an email), moving the system from a passive information processor to an active participant.
• + Many tools and reasoning loop (Agent): This stage represents a significant shift where the system is considered an “Agent” and involves the LLM using multiple tools and a reasoning loop to determine the best sequence of actions to achieve a complex goal, demonstrating a degree of autonomy.
• Multi-agent systems: For even more complex tasks, multiple agents, each potentially specialized, can work together in a coordinated system. This stage may necessitate direct Agent-to-Agent (A2A) interaction if Agents are not hosted in the same environment, allowing agents to hand off tasks or collaborate on sub-problems.
• Remote multi-agent systems: The final stage shows these distributed systems of agents operating remotely, collaborating across different locations or networks. To manage context, coordination, and communication across these distributed environments effectively, robust frameworks — akin to a Model Context Protocol (MCP) and A2A protocol — become essential to ensure scalable and reliable inter-agent operation.

This evolution highlights a shift from a static model to dynamic, autonomous systems capable of reasoning, acting, and collaborating, which is what is now commonly referred to as an “Agent”.

Why This Matters for This Series? Gemini Enterprise and Google Cloud provide the entire stack for this evolution, and you can create and import your agents using: Gemini Enterprise Agent Designer, CX Agent Studio / Conversational Agents (formerly Dialogflow CX), or Agent Development Kit (ADK). In addition, you can also import any Agent that is exposed using an A2A protocol or from the Google Cloud Marketplace.

🔎 Where to find your Agents in Gemini Enterprise?

Now that we have the data, let’s see where you can find the Agents related to your App. Therefore, go to the Agents tab in the left navigation bar (you should already be inside your App).

As you can see, you already have some “Google-made” Agents (such as Deep Research and Idea Generation), and you also have the possibility to click “+ Add agent”.

When you click “+ Add agent”, you can choose from four primary integration paths:

1. Google agents: Best-in-class agents already integrated with Gemini Enterprise.
2. Custom agent via Agent Engine: Agents built by your organization (e.g., using ADK, LangGraph, or CrewAI) deployed on Deployments in Agent Platform and adhering to internal policies.
3. Custom agent via Dialogflow: Deterministic + generative conversational agents built using the Dialogflow CX / Conversational Agents framework.
4. Custom agent via A2A: Custom agents deployed anywhere (even outside Google Cloud) that speak the open Agent-to-Agent (A2A) protocol.
5. Agents via Marketplace: Third-party or pre-procured agents acquired from the marketplace.
6. Agents from Agent Registry: Agents configured inside an internal Agent Gateway registry for the instance, keep in mind that for this you need configure Agent Gateway

Once you have picked the type of agent you want to add, you will get a dedicated configuration page:

• For Custom agent via A2A: You will find a configuration box where you paste your JSON Agent Card and configure authorizations.
• For Custom agent via Dialogflow: You will get a structured form to fill in with your agent’s name, description, Dialogflow agent resource path (projects/<PROJECT>/locations/<LOCATION>/agents/<AGENT>), and tool settings.
• For Custom agent via Agent Engine: You provide the Vertex AI Reasoning Engine resource path (projects/<PROJECT>/locations/<LOCATION>/reasoningEngines/<ID>).

Let’s explore them, checking the UI.

Custom agent via A2A and What Exactly is a “JSON Agent Card”?

Key Takeaway: The JSON Agent Card is NOT the agent itself. It contains no Python code, no LLM weights, and no database logic. It is an Agent Manifest and Contract — a digital “business card” and OpenAPI specification for the autonomous agent era.

Why do we need it? In an enterprise, different engineering teams build agents using different technologies. One team might write an agent in Python using LangChain or ADK; another might write a Go service running on Kubernetes; a partner company might host an agent in another cloud or on-premise.

You do not want to re-write or re-host all those agents inside Gemini Enterprise. Instead, those remote agents expose an HTTP endpoint that speaks the open Agent-to-Agent (A2A) protocol.

To let Gemini Enterprise know that this external agent exists, you give Gemini Enterprise its JSON Agent Card.

What does the Agent Card contain? Think of it like an openapi.json / Swagger specification, but tailored for generative AI reasoning:

{
  "name": "double_click_remote_a2a_agent",
  "description": "Remote supply-chain collaborator speaking the Agent-to-Agent (A2A) protocol. Handles hardware supplier SLA checks.",
  "version": "1.0.0",
  "protocolVersion": "0.2.1",
  "url": "https://a2a-supply-chain-agent.doubleclick.example.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "check_supplier_bottleneck",
      "name": "Check Supplier SLA & Bottleneck Status",
      "description": "Queries remote supply-chain systems for hardware vendor delays impacting Project Alpha or Acme Corp MSAs.",
      "examples": [
        "Why was Project Alpha delayed by 14 days?",
        "Check supplier status for CloudNet Hardware Ltd."
      ]
    }
  ]
}

How does Gemini Enterprise use it at runtime?

1. Registration: You paste this JSON card into Gemini Enterprise →→ + Add agent →→ Custom agent via A2A. Gemini Enterprise stores the manifest in its agent registry.
2. Intent Matching: When an employee asks: “Why was Project Alpha delayed by CloudNet Hardware?”, the Gemini Enterprise Primary Assistant analyzes the query against all registered skills and "examples".
3. Network Dispatch: The router recognizes that its internal knowledge base lacks real-time supply chain telemetry, but the remote agent at "url" has a matching skill (check_supplier_bottleneck).
4. Execution: Gemini Enterprise packages the user prompt into an A2A protocol JSON payload, issues an HTTPS POST request to the remote "url", streams back the answer, and seamlessly renders it to the employee in the chat window.

If needed, the “Agent authorization” tab is designed to establish secure OAuth 2.0 authentication between the platform and the custom or third-party agent being connected.

If the agent is publicly available or if permission for the runtime is already in place, you do not need to configure authentication. You can simply click the Skip & Finish button at the bottom to bypass these authorization settings and complete the setup.

In the top section, administrators enter the core OAuth credentials provided by their identity provider, specifically the Client ID and Client Secret. These credentials serve as the primary identity verification for the agent connection. Authentication can be skipped if the agent is already publicly accessible or if runtime permissions are already established.

The lower section covers specific endpoint configurations and security options. It includes fields for the Authorization URL, Token URL, and specific API Scopes required for the agent to function, such as read or write permissions. Additionally, options for PKCE (Proof Key for Code Exchange) verification and HTTP Basic authentication can be checked to match the security requirements of the underlying OAuth provider. Completing these fields and clicking “Finish” finalizes the setup and integrates the agent into the environment.

Dialogflow & Custom agent via Agent Runtime

Conversely, for Dialogflow, you will simply get a structured form to fill in with your agent’s name, description, Dialogflow agent source resource path (projects/<PROJECT>/locations/<LOCATION>/agents/<AGENT>)

And similarly, if you want to configure a Custom agent via Agent Runtime, you will need to fill in a similar form, but you will need to use a Reasoning Engine Id (projects/<PROJECT>/locations/<LOCATION>/reasoningEngine/<reasoningEngine>), instead of an Dialogflow agent source resource path (projects/<PROJECT>/locations/<LOCATION>/agents/<AGENT>)

Agents via Marketplace & Agent Registry

The last two instead presents a search bar, so that you can search for existing agents in the Marketplace or Agent Registry.

Demystifying the Architecture

When people talk about agents in this series, there is often confusion between the top-level Gemini Enterprise Assistant and the underlying specialized agents. Let’s break down where each one is created and what role it plays:

A. The Top-Level Hub (Gemini Enterprise App):

• Where it is created: Created in Discovery Engine via terraform/discovery_engine.tf (google_discovery_engine_search_engine.gemini_enterprise_app).
• What it does: Acts as the main chat window and intranet assistant. It automatically performs basic RAG search across our Part 1 Knowledge Base (PDFs in GCS and structured rows in BigQuery).

B. The Conversational QA Agent (Dialogflow CX / Conversational Agents):

• Where it is created: Created in the Dialogflow CX / Conversational Agents Console (or automated via terraform/dialogflow_cx.tf as google_dialogflow_cx_agent.double_click_cx_agent in location global).
• Why is it needed if we already have the App? Basic RAG is passive — it just retrieves snippets. Our Conversational QA Agent introduces behavioral steering, conversational guardrails, and compliance workflows. Inside this agent, we create a Generative Task Playbook (google_dialogflow_cx_playbook.double_click_concierge_playbook). The playbook instructs the LLM: 1) “Always identify whether the question is HR, Legal, or Operations.” 2) “Strictly ground answers in the company data stores.” 3) “If the employee asks about Project Phoenix, mandate Security Clearance Level 2 before answering.”
• How it is connected: We copy its resource string (projects/<PROJECT>/locations/global/agents/<ID>) and register it into Gemini Enterprise under + Add agent → Custom agent via Dialogflow.

The Code-First Tool Agent (Vertex AI Agent Engine with ADK):

• Where it is created: Written in Python (agents/adk_double_click_agent/agent.py) using the Google Agent Development Kit (ADK) and deployed to Vertex AI Agent Engine (reasoningEngines) in europe-west1.
• What it does: Handles deterministic calculations that an LLM should not guess (such as calculating the exact 15% discount for Acme Corp renewals or executing live parameterized BigQuery SQL queries).
• How it is connected: We copy its ReasoningEngine resource string (projects/<PROJECT>/locations/<REGION>/reasoningEngines/<ID>) and register it under + Add agent → Custom agent via Agent Engine.

How to interact with your Agents from the UI

Up to now, we haven’t spoken about the end-user interface that your App has. By default, if you go to the Overview page of your Gemini Enterprise App, you can access the web app by clicking on or copying the generated web app link (this is just one of the deployment methods, which we will customize in Part 3):

When you open that URL, you are redirected to an enterprise web interface very similar to the consumer Gemini interface (https://gemini.google.com/), but grounded in your company's data and governed by your organization's security policies.

Now, if you click on the Agents tab in the left sidebar of the web app, you can see the Agent gallery containing all the agents you can interact with within your App. Initially, we see our 2 Google-made options (Deep Research and Gemini Notebook) but you can add more:

If you click on any of these, you get redirected to that specific agent’s workspace (for example, Deep Research):

🔨 Build Agents with the Google Ecosystem

As already mentioned, Google Cloud offers a powerful suite of tools for building advanced AI agents, with ADK, CX Agent Studio / Conversational Agents (formerly Dialogflow CX), and the broader Gemini Enterprise Agent Platform (formerly Vertex AI Agent Builder / Agentspace) being the primary solutions.

These platforms are specifically designed to address the need for a hybrid solution — one that can seamlessly blend deterministic (rule-based, predictable) responses for specific compliance or business topics with generative AI (GenAI) responses for open-ended or less-defined conversations.

• Conversational Agents (formerly Dialogflow CX) is used for building large, complex, and sophisticated virtual agents. It is the state-of-the-art visual platform for deterministic flow management, now powerfully extended with generative AI Playbooks.
• Gemini Enterprise & Agent Engine (formerly Vertex AI Agent Builder) is a comprehensive platform for creating, deploying, and governing enterprise-grade agents, unifying Google AI capabilities for RAG and multi-agent systems. And it supports multiple open agent frameworks including Agent Development Kit (ADK), LangGraph, LangChain, LlamaIndex, CrewAI, and AG2.

Since this article is not a full coding tutorial on how to develop every type of agent from scratch, but rather a guide on how to integrate them into Gemini Enterprise, we will walk through the creation and deployment steps briefly so you understand how to bring your own agents into the platform.

Example 1: CX Agent Studio (formerly Dialogflow CX)

💡 Understanding the Difference: Dialogflow CX vs. CX Agent Studio Google Cloud is currently transitioning between two generations of conversational AI interfaces and backends:

- Dialogflow CX Console (dialogflow.cloud.google.com/cx): Google’s classical, flow-based agent platform built around deterministic state machines (default_start_flow).

- CX Agent Studio / Conversational Agents Studio (ces.cloud.google.com or conversational-agents.cloud.google.com): The next-generation generative AI workspace under Google’s Customer Engagement Suite (CES) where agents are LLM-native and governed by a root Playbook (start_playbook).

To learn how to create a new agent from scratch (using Playbooks or Flows) or import a Pre-built Agent template — making sure to pick the same Location (global, us, or eu) as your Part 1 Data Stores—check the official Google Cloud documentation:

• 📖 CX Agent Studio / Customer Engagement Suite Documentation
• 📖 Dialogflow CX Official Documentation

Find your Agent Resource Name & Add it to Gemini Enterprise

Once your agent is created in CX Agent Studio or Dialogflow CX, you will see it in your Conversational Agents list:

To link it to Gemini Enterprise:

1. Click on the 3 dots (Actions) on the right side of the row and click Copy name.
2. This copies the resource name string in the format: projects/<PROJECT_ID>/locations/<LOCATION>/agents/<AGENT_ID>
3. Paste this resource path into Gemini Enterprise → Agents → + Add agent → Custom agent via Dialogflow (shown earlier). Once added, your users will immediately see it under “From your organization” in their Gemini Enterprise Agent Gallery!

Example 2: Agent Development Kit (ADK) & Deployments in Agent Platform

You can achieve an even more flexible, code-first architecture using the Agent Development Kit (ADK), once your ADK agent is deployed to Agent Platform, integrating it into Gemini Enterprise is just as seamless.

Deployments is the recommended, fully-managed runtime service for scaling ADK agents, abstracting away infrastructure concerns like load balancing, auto-scaling, and persistent session management.

Prerequisites

These instructions assume you have already defined an ADK project (an agent). If you do not have an ADK project yet, see the official ADK Python Quickstart guide, which creates a multi_tool_agent project (used as the example below).

Before starting the deployment procedure, ensure you have the following:

1. Google Cloud Project: A Google Cloud project with the Vertex AI API enabled.
2. Authenticated gcloud CLI: You need to be authenticated with Google Cloud. Run the following command in your terminal: gcloud auth application-default login
3. Google Cloud Storage (GCS) Bucket: Agent Engine requires a GCS bucket to stage your agent’s code and dependencies for deployment.
4. Python Environment: A Python version between 3.9 and 3.13.
5. Install Vertex AI SDK & ADK: Agent Engine is part of the Vertex AI SDK for Python. Install it via: pip install "google-cloud-aiplatform[adk,agent_engines]>=1.111"

Deploying via the ADK CLI (Option 1)

You can often deploy your ADK agent using a single command via the ADK Command Line Interface (CLI):

adk deploy agent_engine \
    --project=my-cloud-project-xxxxx \
    --region=us-central1 \
    --staging_bucket=gs://my-cloud-project-staging \
    --display_name="My Agent Name" \
    ./multi_tool_agent

Deploying via the Python SDK (Option 2)

Alternatively, you can initialize the Vertex AI SDK and deploy programmatically in a deploy.py script:

import vertexai
from vertexai import agent_engines
from agent import root_agent  # modify this if your agent entry point differs

PROJECT_ID = "your-gcp-project-id"
LOCATION = "us-central1"
STAGING_BUCKET = "gs://your-gcs-bucket-name"
# 1. Initialize the Vertex AI SDK
vertexai.init(
    project=PROJECT_ID,
    location=LOCATION,
    staging_bucket=STAGING_BUCKET,
)
# 2. Wrap the agent in an AdkApp object for Agent Engine compatibility
app = agent_engines.AdkApp(
    agent=root_agent,
    enable_tracing=True,
)
# 3. Deploy to Deployments in Agent Platform
remote_app = agent_engines.create(
    agent_engine=app,
    requirements=["google-cloud-aiplatform[adk,agent_engines]"],
    display_name="My ADK Enterprise Agent",
)

Note: When an AdkApp is deployed to Agent Engine, it automatically uses VertexAiSessionService for persistent, managed session state. This provides multi-turn conversational memory out of the box without any additional database configuration.

After several minutes, you will find your deployed agent listed on the Agent Engine page in the Cloud Console. Click the Copy icon under the Resource name column, and link it in Gemini Enterprise under “+ Add agent” →→ “Custom agent via Agent Engine”!

Note: To get an updated version, please consider reading how to build agents and how to deploy them.

Additionally, if you need a step-by-step guide on ADK 2.0 with a companion branch-by-branch implementation, please consider reading my series “ADK 2.0–101” on Medium and check the companion repo on GitHub.

Example 3: Create an Agent from the UI with Agent Designer (No-Code)

What if business users or admins want to create specialized agents without writing code or leaving the Gemini Enterprise Web App?

Once inside the Agent gallery in the Gemini Enterprise Web App, if your administrator has enabled Agent Designer (which we’ll govern in Part 3), you can create and publish an agent directly from the UI simply by clicking “+ Create agent” and then on “Build Manually”:

This opens the visual Agent Designer studio (https://vertexaisearch.cloud.google.com/eu/home/cid/<appID>/r/agent-builder/<agentbuilderID>), where you can describe your agent in natural language or use the visual flow canvas to connect subagents, models, and enterprise Data Stores—and it is automatically added to your Gemini Enterprise Agent Gallery!

📖 To learn more about configuring instructions, subagents, and tools in the no-code studio, refer to the Official Gemini Enterprise Agent Designer Documentation.

💻 Code & Infrastructure Summary: Automating Part 2 (02-conversational-modeling)

Can we automate the creation of our Conversational Agents, Gemini Enterprise App, and ADK Agent Engine runtime using Terraform and Python? Yes!

On branch 02-conversational-modeling of our companion repository, we build incrementally on top of our Part 1 Knowledge Base using our modular, service-split Terraform files and the same root .env configuration:

• Conversational Agents & Playbooks (terraform/dialogflow_cx.tf): Provisions the Dialogflow CX Agent (google_dialogflow_cx_agent), creates a generative task Playbook (google_dialogflow_cx_playbook) with step-by-step instructions for DoubleClick Enterprise, automatically patches startPlaybook so the agent defaults to Playbook mode, and optionally provisions a next-gen CX Agent Studio (google_ces_app) container.
• Gemini Enterprise App Hub (terraform/discovery_engine.tf): Provisions the double-click-enterprise-app (google_discovery_engine_search_engine with APP_TYPE_INTRANET, SEARCH_TIER_ENTERPRISE, and SEARCH_ADD_ON_LLM) connected to our Part 1 Data Stores, where all custom agents are registered.
• Code-First ADK Agent & IAM (terraform/vertex_ai_agent.tf & agents/adk_double_click_agent/): Provisions the dedicated ADK Service Account (google_service_account.adk_agent_engine_sa) with least-privilege IAM roles, plus our complete Python ADK agent (agent.py and deploy_agent_engine.py) and sample A2A JSON Agent Card (agents/a2a_agent_card/double_click_a2a_agent_card.json—note that the A2A AgentCard schema requires "protocolVersion": "0.2.1" and uses "name" rather than "displayName").

Quick Setup & Testing Commands (Branch 02-conversational-modeling):

# 1. Authenticate with Google Cloud (CLI + Terraform ADC)
gcloud auth login
gcloud auth application-default login

# 2. Checkout the Part 2 branch
git checkout 02-conversational-modeling
# 3. Run the automated verification & unit test suite (tests ADK tools, A2A JSON Card & Terraform)
./scripts/test_infra.sh
# 4. Provision the Part 1 + Part 2 infrastructure
./scripts/setup_infra.sh
# 5. (Optional) Deploy the Python ADK Agent to Deployments in Agent Platform
python3 agents/adk_double_click_agent/deploy_agent_engine.py

👉 For a complete line-by-line walkthrough of dialogflow_cx.tf, vertex_ai_agent.tf, the Python ADK agent code, and how to link them into Gemini Enterprise, read our companion article: Part 2 EXTRA — Automating Conversational Agents, Playbooks & ADK with Terraform & Python or check the Repository README

Conclusion

Conversational Modeling is no longer a simple choice between a rigid rule-based bot and an unconstrained creative AI. The best enterprise agents are hybrids.

With Gemini Enterprise, you can choose the exact entry point that matches your team’s skills and use case:

• Start No-Code with the Agent Designer UI in the web app for an instant, multi-subagent assistant grounded in your Knowledge Base.
• Evolve to the Visual Flow & Playbook Builder (CX Agent Studio / Conversational Agents, formerly Dialogflow CX) to create structured “Action Takers” that follow strict compliance workflows while still querying your Knowledge Base to handle unexpected user questions.
• Go Code-First with the ADK & Deployments in Agent Platform (or A2A for remote agents) to build sophisticated, autonomous multi-agent systems in Python.

We’ve built the brain (Part 1) and the personality (Part 2). But what does it look like to your employees, and how do you govern what features they can access?

Coming up in Part 3: We’ll dive into 🎨 UX/UI & Accessibility. Now that we have a smart, conversational agent, how do we customize its branding, manage end-user features, and embed it across our company apps?

« Part 1: Knowledge Base | Gemini Enterprise Hub | Part 3: UX/UI & Accessibility »

Building Enterprise Agents with Gemini: Part 2 — 🗣️ Conversational Modeling was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quite simply, the EXTEND pipe operator adds computed columns to a result set. That statement is a nice summary, but it only scrapes the surface of what EXTEND can do.

• Do you want to create a concatenated output of multiple values within various columns?
• How about creating a sum (or any other mathematical calculation) based on values within a row of data?
• Calculating the length of a command line?
• Classifying results from a column?

EXTEND can do all of those things…and more.

For those familiar with YARA-L, the EXTEND pipe doesn’t have an exact counterpart, but it can fill the role that placeholder variables perform in the filtering statement or in the outcome section in the form of conditional logic, for instance. Because EXTEND fills many different roles, it is a bit harder to provide a single example that summarizes how it compares to YARA-L, so here is a basic example to kick this off. Here we are generating an output of the time, IP pair, sent and received bytes and creating a new column with the total bytes for each event.

metadata.event_type = "NETWORK_CONNECTION"
network.sent_bytes > 0
network.received_bytes > 0
match:
  metadata.id // Group by the unique event ID to guarantee row-by-row results
outcome: // Using a match section, fields must be aggregated
  $time = timestamp.get_timestamp(max(metadata.event_timestamp.seconds))
  $principal_ip = array_distinct(principal.ip)
  $target_ip = array_distinct(target.ip)
  $sent_bytes = max(network.sent_bytes)
  $received_bytes = max(network.received_bytes)
  $total_bytes = max(network.sent_bytes + network.received_bytes)
order:
  $time desc
unselect:
  metadata.id

Here is the equivalent query in SQL pipe syntax:

FROM events
|> WHERE metadata.event_type = "NETWORK_CONNECTION" and
    network.sent_bytes > 0 and
    network.received_bytes > 0
|> SELECT TIMESTAMP_SECONDS(metadata.event_timestamp.seconds) as time,
    principal.ip as principal_ip,
    target.ip as target_ip,
    network.sent_bytes,
    network.received_bytes
|> EXTEND sent_bytes + received_bytes as total_bytes

If you want to use traditional SQL rather than pipe SQL, it’s worth noting that like the AGGREGATE pipe, EXTEND is not a term you will find in traditional SQL. However, this query can be handled by performing the addition of the bytes in the SELECT statement like this.

SELECT
  TIMESTAMP_SECONDS(metadata.event_timestamp.seconds) as time,
  principal.ip as principal_ip,
  target.ip as target_ip,
  network.sent_bytes,
  network.received_bytes,
  network.sent_bytes + network.received_bytes as total_bytes
FROM events
WHERE metadata.event_type = "NETWORK_CONNECTION" and
  network.sent_bytes > 0 and
  network.received_bytes > 0

Either way, the results looks like this:

I’ve mentioned a number of capabilities that EXTEND can handle, so let’s dig into some additional capabilities.

Extracting Values into New Columns

In the previous example, we created a new column by taking the sum of two other columns. Let’s apply EXTEND to string values. SecOps stores the file name and full path in a single field, and perhaps we want to extract that file name to perform some additional analysis. We would apply the regular expression REGEXP_EXTRACT to the target.process.file.full_path, extract it and name the new column file_name using the EXTEND pipe. The result is two columns, the source column and the newly created one that just contains the file name.

FROM events
|> WHERE metadata.event_type = "PROCESS_LAUNCH" and target.process.file.full_path <> ""
|> SELECT target.process.file.full_path
|> EXTEND REGEXP_EXTRACT(full_path, r'\\([^\\]+)$') as file_name

Calculating Numeric Values from Strings

Now let’s take a string and use a SQL function to output a numeric. In this example, we are using the LENGTH function, one of nearly 200 SQL functions supported in Google SecOps, and outputting this numeric to a new column using EXTEND.

FROM events
|> WHERE metadata.event_type = "PROCESS_LAUNCH" and target.process.command_line <> ""
|> SELECT target.process.command_line as cmd_line
|> EXTEND length(cmd_line) as cmd_length

With all three of these examples, the total bytes, file name and command string length, we are probably not at the final step of the query, but it unlocks values that can then be further manipulated in the query. These next steps could be as simple as sorting or they could be used in additional statistical calculations or filtered to arrive at a final actionable result.

Classifying Events

In fact, let’s take this last example and take it a step further. Again a lot of this mini-series is around highlighting the building blocks that exist within SQL pipes that you can take to build your own queries for your use cases as well as ensuring you understand what is occurring in each of these steps. I’m not expecting everyone to be SQL experts but it is important to be able to understand the flow of these queries as we add more pipe operators to them!

With the command line length calculated in the previous query, perhaps we want to add a classification column to the results. The EXTEND pipe does this as well.

FROM events
|> WHERE metadata.event_type = "PROCESS_LAUNCH" and target.process.command_line <> ""
|> SELECT target.process.command_line as cmd_line
|> EXTEND length(cmd_line) as cmd_length
|> EXTEND cmd_length > 200 or cmd_length < 10 as interesting_rows
|> WHERE interesting_rows = TRUE

The first thing I want to call out is that we have two EXTEND pipes back to back in this query. In SQL pipes, we need two separate pipes in this case because the latter one is dependent on the results of the former. So, the first EXTEND calculates the length of the command line. With that calculated, the second EXTEND can use that calculated value and based on the logic provided compares the command length to the values provided and if it meets the criteria, it outputs true in the newly named column and if not, it returns false.

If we had wanted to perform additional classifications or create additional columns, we could append additional logic to the second EXTEND pipe and separate the new logic from what we already have with a a comma. The last step of this query is the addition of another WHERE pipe to further filter the result set to just the “interesting” columns.

In my estimation, the additional bonus that EXTEND brings is that because SQL pipes operate in a linear manner, we can create new columns during a query and then perform operations on those columns within the same query. In traditional SQL, this is often handled with a common table expression (CTE) or using the last example, adding more calculations to the SELECT statement as well as filtering in the WHERE statement as the query gets refined. In YARA-L, these additional calculations are often handled by building a multi-stage search which I’ve covered previously.

We’ve scratched the surface of EXTEND and will follow this blog with another one with more examples of EXTEND which go deeper into its capabilities. In the meantime, here are a few things to keep in mind as you get started:

• EXTEND creates additional columns in the result set
• Using SQL functions, it can be used to concatenate values, extract strings, perform mathematical functions and more
• These newly created columns can then be used by subsequent pipe operators
• Just remember that the EXTEND pipe can’t be used to calculate a new column and then immediately use that newly created column in that same EXTEND pipe; you need to add a second EXTEND pipe

Try some of these concepts out in your next search and let us know how it goes. I’ll be back with more tips, more pipes and the concepts we covered today will be leveraged as we go deeper into SQL pipes!

New to Google SecOps: Same as It Ever Was? Not When You Use |> EXTEND was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

I rebranded a company. I swapped one Word file in a storage bucket, ran the same product sheet again, and warm editorial photography turned into neon cyberpunk anime.

Same agents, same prompts, zero edits.

Here’s how I built it, step by step.

If you read my previous article — Stop playing the lottery with AI: yet another prompting guide (that finally makes it click) — you know the golden rule: structuring your prompts with a clear role, context, constraints, and examples turns erratic AI outputs into predictable, high-quality results.

But in an enterprise setting, structured prompts hit a hard ceiling.

If you’ve ever run a marketing workflow with a gen-AI chat, you know the usual routine: manually copying and pasting prompt after prompt — ask for a specific format, clearing negative space on the left, checking tone of voice, paste the list of words legal doesn’t allow, start over when it forgets the layout rules— turns you into a human copy-paste machine. (If you want to see how grueling that manual back-and-forth really is, check out my companion piece: Why One-Shot prompts fail: the engineer’s guide to prompt chaining).

Even a perfect prompt is still a prompt. You paste it every time, into a tool that has never seen your company’s documents.

So here’s the plan. In Gemini Enterprise, we build a small team of AI agents that:

1. turns a product spec sheet into a brand-compliant 21:9 key visual;
2. reads the company’s real manuals from Cloud Storage, instead of having them pasted into a chat;
3. follows the manuals when they change, so updating a document is enough to update the behavior of the whole team.

That is the difference between prompting a chatbot and giving an agent access to your company’s knowledge.

⚠️ Keep in mind! “No-code” here means no code is written or deployed. The workflow logic is still natural-language system prompts, so think of it as prompt engineering with a UI. And the 4-phase flow lives in the conversation, not in a workflow engine: an agent can occasionally skip or mix up a phase. Same rule as last time: check what you get.

Ready? Let’s set the stage.

Our scenario revolves around Bit&Butter Tech, a fictional company that builds inclusive technology: dual-interface tablets for seniors, portable 5G hotspots, and more. (Fictional, of course: it’s just an example.)

Whenever the product engineers hand us a Product Spec Sheet, our marketing team has to deliver three things:

• a campaign concept aligned with company directives and internal policies
• a key visual in the format our brand requires
• a claim that passes legal and corporate review.

Those rules are not in anyone’s head. They live in three official documents:

• Art Direction & Mockup Guidelines (Creativity_Mockup_Manual.docx): the photographic style, the required format, where the subject sits in the frame, and three Brand Archetypes.
• Copywriting & Tone of Voice Manual (Copywriting_Manual.docx): a reassuring, solemn voice and the “Two-Beat Brevity” rule: a goal, a promise, and 3 to 5 words in total.
• Brand Safety & Legal Compliance Policy (BrandSafety_Manual.docx): blacklisted claims like “free” or “the best”, no competitor names, and mandatory disclaimers.

ℹ️ Demo kit: the product spec sheets and the three manuals, in English, are in the DEMO_EN/ folder of the companion repo.

Why Gemini Enterprise and not a consumer chat?
Because the rules above are exactly what people paste into consumer tools, and that is where the risk starts. Gartner’s research points the same way: in a survey of 302 cybersecurity leaders (March to May 2025), 69% of organizations suspected or had evidence that employees were using prohibited public GenAI tools. Gartner also predicts that by 2030 more than 40% of enterprises will face security or compliance incidents linked to unauthorized shadow AI.

Gemini Enterprise brings AI under corporate control, ensuring companies dictate who has access, how data is handled, and what guardrails are in place.

⚠️ Comparing enterprise AI platforms is a whole subject in itself, which I’ll dive into in a dedicated post. Stay tuned!

Setup the environment

⚠️ Before we dive in, let’s talk a bit about costs.
As of October 2026, Google Enterprise offers a 30-day free trial. However, these technologies and related products literally change day by day and country by country, so be sure to check the current terms that apply to you before you get started, and make sure to delete the resources at the end (the last section shows how).

Time: about 10min.

1. Activate Gemini Enterprise

1. In the Google Cloud Console, search for Gemini Enterprise and start the free trial.
2. If an error appears right after you click, refresh the page until the button changes to Create your first app. (This is a quirk I hit while testing, so it may not happen to you.)
3. Create an app called BitAndButter. Keep the default settings.
4. Under Integration, select Use Google Identity as the identity provider.

2. Create the bucket

Cloud Storage is where the manuals live. Bucket names are globally unique and visible to other users, so don’t use personal information. Use your project ID or a random suffix:

• Bucket name: bit-and-butter-7f3k2q (example)
• Location: choose a region that is eligible for the free trial.

⚠️ Keep in mind! Not all regions are, so check the up to date list of supported regions in the documentation before creating the bucket.

• Access control: uniform (the default; check it when you create the bucket)

Then create a folder called MarketingShared and upload the three manuals:

• Creativity_Mockup_Manual.docx
• Copywriting_Manual.docx
• BrandSafety_Manual.docx

Permissions. In a real setup, whoever can write to this bucket can change the brand and legal rules. For this demo, enable object versioning, so every change can be rolled back.

3. Connect the bucket as a data store

In Gemini Enterprise → Data Stores, add a Cloud Storage connector, name it MarketingSharedand point it to your_bucket/MarketingShared.

Now you have to choose how the agents receive updates. The connector doesn’t open your file each time an agent asks something. It builds a search index from the files, and the agents search that index. So after you change a file, the index has to be updated. There are several ways to do that:

• One time: the index is built once, when you create the connector, or when you run a manual re-import. It’s simple and predictable, but changes arrive only when someone triggers a re-import.
• Scheduled sync: the index is refreshed at set intervals (every one, three or five days). Changes arrive without manual steps, but there’s a delay between the edit and the effect.
• Streaming: changes are picked up as they happen, with the shortest delay.

What we use in this demo: one time, with a manual re-import when a manual changes. The cause and effect are easy to see: you change a file, you re-import, and the visual changes. In a production setup, a scheduled sync is usually the better choice, if you can accept a delay between the edit and the agent’s behavior.

4. Enable the agent features

In the Cloud Console, search for Gemini Enterprise and select your application.

This is where the organization has complete control over the environment — deciding what employees can and cannot do, enabling or disabling specific tools and features, defining policies, and configuring security settings.

Then go to Configurations > Feature Management and turn on:

• ✅ Enable chat agents

⚠️ Keep in mind! Test each change to a manual before you rely on it. If the index doesn’t update, the agents keep answering from the old version, with no warning.

The Agent Architecture (Why Sub-Agents?)

Instead of building a monolithic “Frankenstein” prompt that tries to do everything at once, we are using a Coordinator + Sub-Agents architecture.

Breaking complex workflows into specialized sub-agents prevents attention loss (“lost in the middle”), allows selecting the right model for the job (e.g., Gemini Pro for orchestration vs. Flash for speed), and enforces the Principle of Least Privilege (each agent only accesses the tools and files it needs).

Here is our team layout:

User uploads Product Sheet (.docx)
       │
       ▼
[Coordinator: DraftGenerator 9] (Creative Director)
       │
       ├──► Phase 1: Calls [01SceneGen]
       │      • Reads user's Product Sheet 
       │      • Queries Creativity_Mockup_Manual.docx (via GCS Connector)
       │      • Pitches 3 scenes based on Brand Archetypes
       │
       ├──► Phase 2: User chooses scene ──► Calls [02DraftGen]
       │      • Extracts layout rules (21:9, 35mm, right-aligned subjects, left Copy Space)
       │      • Crafts master prompt & hands off to Coordinator
       │      • Coordinator generates base visual
       │
       ├──► Phase 3: Coordinator checks Copy & Legal manuals ──► Proposes 10 compliant claims
       │
       └──► Phase 4: User picks claim ──► Coordinator renders final key visual.  

Step 1: Configuring the Agents (Copy-Paste Prompts)

In the Gemini Enterprise Agent Designer (1), skip the prompt and open the Agent Builder directly by clicking on Build manually (2), and configure the following three agents.

1. Root Agent: 00DraftGenerator(Coordinator)

The Creative Director. Handles the 4-phase state machine, human approval gates, image generation, and claim validation.

• Connectors Enabled: MarketingShared (Cloud Storage).
• Instructions:

You are the Creative Director and Coordinator Agent of "Bit&Butter". Your exclusive task is to welcome the user, oversee the 4-phase workflow, and generate images.

ROUTING AND WORKFLOW MANAGEMENT RULES:

Start (Phase 1): When the user uploads a product spec sheet, thank them briefly and immediately transfer both the document and control to sub-agent 01SceneGen.

Transition to Phase 2: When the user chooses one of the proposed scenes, immediately transfer control to sub-agent 02DraftGen.
IMPORTANT: When 02DraftGen returns control to you, stop and ask the user if they want you to proceed with generating the image.
- If the user confirms, generate the image (or invoke your image generation tool), display the image in the chat, and write to the user: "Base image generated according to guidelines. Next step: the Copywriting team (Phase 3) will craft 10 claim proposals. Do you confirm this visual framing to proceed?"
- If the user does not wish to generate the image right now, move directly to Phase 3.

Transition to Phase 3: When the user confirms that the generated image looks good:
STEP 1: Rule Retrieval (via Connector)
- Query "MarketingShared" to read the "Copywriting_Manual" and extract: Institutional Tone of Voice, metric architecture of the claim, punctuation rules, and maximum length constraints.
- Query "MarketingShared" to read the "BrandSafety_Manual" and extract: blacklisted forbidden terms, competitor policy, and legal clauses.
Generate 10 numbered text claims that are coherent with the scene approved in the previous phases and jointly respect all extracted metric rules and compliance filters.
Response to the user:
- Present the numbered list from 1 to 10 of the crafted claims.
- Next Step & Closing: "Next step: I will apply the selected claim inside the image's Copy Space, harmonizing contrast, font, and legibility according to our guidelines. Which of these 10 claims would you like to apply to the visual?"
Wait for the user's choice.

Transition to Phase 4: When the user confirms the claim to use:
STEP 1: Visual Parameter Retrieval (via Connector)
- Query "MarketingShared" to read "Creativity_Mockup_Manual" and extract the criteria for inserting the claim and managing the copy space.
- Ask the user if they want to proceed with generating the final image.
STEP 2:
- If the user confirms, update the image generated in Phase 2 by inserting the text claim into the reserved area (Copy Space), applying the typographic criteria defined in "Creativity_Mockup_Manual".
- If the user does not confirm, reply: "Understood. Here is the prompt we created: [INSERT ENGLISH PROMPT HERE] and this is the claim you chose: [INSERT CLAIM HERE]. Whenever you are ready to generate the final image, type 'Generate final image'."

BEHAVIORAL RULES:
- Maintain an authoritative yet encouraging Tone of Voice.
- If the user makes an out-of-context request or tries to skip a phase, gently guide them back to the workflow by indicating the current step.
- If a sub-agent reports an error (e.g., "File not found"), communicate the interruption to the user and ask them to verify the requirements before restarting.

2. Sub-Agent 01: 01SceneGen (Parsing & Scene Ideation)

Extracts product facts and matches them with brand narrative archetypes.

• Connectors Enabled: Enable MarketingShared connector for the cloud manual.
• Instructions:

You are Bit&Butter's Sub-Agent specialized in "Scene Parsing and Ideation". Your task is to analyze the product spec sheet provided by the Coordinator, retrieve the guidelines from Cloud Storage, and propose 3 visual directions.

STRICT TOOL AND FILE MANAGEMENT: You must execute data retrieval in THIS EXACT ORDER to avoid system conflicts:

STEP 1: Product Spec Sheet Reading (via Code Interpreter)
Use your internal file tool (file_and_coding_agent) EXCLUSIVELY to read and extract text from the document uploaded by the user (e.g., "BBGoAnywhere.docx" or "BBPadFamily.docx"). Important: DO NOT ask file_and_coding_agent to search for the creativity manual, because it does not have access to the cloud bucket.

STEP 2: Manual Reading (via Connector)
Once the product text is extracted, directly use the "MarketingShared" Cloud Storage connector (via ingestion_search) to find and read the file "Creativity_Mockup_Manual.docx".
Extract the brand's "Narrative Archetypes" from this document.
MANDATORY STOP: If the connector cannot find the file or extraction fails, retry using a different search query. If you still cannot find the file, halt the process and reply: "System Error: I was unable to read the Creativity Manual from the MarketingShared bucket."

OPERATIONAL WORKFLOW (Once all data is collected):
1. Analysis: Summarize from the product spec sheet: Product Name, Mission, Target Audience, and Key Specifications.
2. Creation of the 3 Scenes: Using the Narrative Archetypes extracted from the manual, translate the product into 3 visual scene proposals (each associated with one of the three archetypes).
3. Output for the User: Generate your response structured as follows:
   - Confirmation: "Spec sheet for [Product Name] acquired. I have consulted the Creativity Manual."
   - Proposals: Bulleted list of the 3 scenes (Archetype, Subjects, Action, Atmosphere).
   - Closing: "Next step: once you approve the narrative direction, the team will generate the base visual applying our compositional layout. Which of these 3 creative visions would you like to develop?"

Stop and wait for the user's response.

2. Sub-Agent 02: 02DraftGen (Art Direction)

The visual architect. Translates the chosen scene and technical framing rules into the master image generation prompt.

• Name: 02DraftGen
• Description: Sub-agent specialized in Art Direction that retrieves visual parameters from the brand book and crafts the master image generation prompt.
• Connectors Enabled: MarketingShared (Cloud Storage).
• Instructions:

You are Bit&Butter's Sub-Agent specialized in "Art Direction". Your task is to retrieve the visual directives from the brand book, craft the perfect image prompt, and hand it over to the Coordinator (Root Agent) so they can generate the image.

ENABLED CONNECTORS: "MarketingShared" (read access to the bucket).

MANDATORY OPERATIONAL WORKFLOW:

STEP 1: Visual Parameter Retrieval
Query "MarketingShared" to read the file "Creativity_Mockup_Manual.docx".
Extract: aspect ratio, visual/photographic style and lens, framing, asymmetric layout distribution (Copy Space), and lighting/atmosphere.

STEP 2: Prompt Creation
Create a detailed visual prompt in English combining the scene chosen by the user with ALL the extracted technical parameters.

STEP 3: Hand-off to the Coordinator
Write EXACTLY this text message in the chat to pass the data back to your Coordinator:
"I have completed the art direction. Coordinator, please proceed to generate the image using your native capabilities with this exact visual prompt: [INSERT ENGLISH PROMPT HERE]. Once you have shown the image to the user, ask them to confirm the framing to move to Phase 3 on Claims."

Do not invoke image generation tools yourself. Stop and let the Coordinator (Root Agent) take control by reading your message.

⚠️ Keep in mind! Generating text directly inside AI images works for quick mockups, but it’s rarely brand-perfect. For production assets, true typography and layout precision still require a dedicated design tool or a post-processing step.

Testing the workflow

Now open the chat in DraftGenerator and upload BBPadFamily.docx.

Observe how seamlessly the team executes:

1. 01SceneGen parses the tablet specs and suggests 3 emotional scenes rooted in our Brand Archetypes (The Human Bridge, Everyday Autonomy, The Collective Dimension).

1. You select Scene 1. 02DraftGen builds the master prompt enforcing the 21:9 panoramic aspect ratio, 35mm cinematic lens, subjects on the right, and negative Copy Space on the left.

1. 00DraftGenerator checks Copywriting_Manual.docx and BrandSafety_Manual.docx, serving up 10 compliant claims adhering to the Two-Beat Brevity structure (e.g., "Every generation. One family.").

1. You pick a claim, and the agent renders the final key visual with the typography placed inside the Copy Space.

⚠️ Keep in mind! If the agent struggles to generate images and returns a generic error, skip the intermediate image generation steps by declining them along the way. Instead, run the single command “Generate final image” when the coordinator offers it at the very end of the workflow.

The Real Power: The Agent as a Living Colleague

Here is the real revelation: companies are constantly evolving.

When brand guidelines or legal policies change, you shouldn’t have to rewrite 50 different prompts across your organization. Like a reliable human colleague, your agent already knows where the shared folder is — and simply checks the latest version before getting to work.

Proving it: the Cyberpunk rebrand

Imagine Bit&Butter rebrands overnight from warm editorial photography to High-End Cyberpunk Anime (neon lighting, saturated palette, cel-shading).

We don’t touch a single prompt or line of configuration in our agents. Instead:

1. In your Cloud Storage bucket (MarketingShared), overwrite Creativity_Mockup_Manual.docx with the file from DEMO_EN/MarketingShared_Var01/.
2. In Gemini Enterprise > Data Stores, click Re-import on the connector.

⚠️ Keep in mind! Data Stores do not update instantaneously. Document parsing, chunking, and embedding generation can take anywhere from a few minutes to half an hour depending on document size and queue traffic. Always check that the ingestion status has returned to “Completed” in the console before running your validation prompts, otherwise your agents will continue serving responses from the cached index.

Run the exact same product sheet through the agent again.

The agent automatically pulls the updated manual. It retains the 21:9 ratio, the right-side subject placement, and the compliant claims — but the resulting visual is now a dramatic, neon-soaked Cyberpunk Anime concept!

The Series Roadmap

Building enterprise agents is an iterative journey. To explore each layer in depth:

• Stop playing the lottery with AI: a 10-step blueprint to reliable prompts:
  A hands-on walkthrough showing beginners how to get more predictable, higher-quality results from Google Gemini.
• Why One-Shot prompts fail: the engineer’s guide to prompt chaining: Stop asking AI to build everything at once. Here is how step-by-step chaining unlocks deterministic output and lays the blueprint for multi-agent automation.

Coming soon…

• You probably don’t need an AI Agent. Here’s how to tell:
  Not every problem needs an AI agent. Learn how to choose between a prompt, a workflow, a single agent and sub-agents, with a decision framework and a real example.

Change the brand manual, not the prompts: a multi-agent marketing team in Gemini Enterprise was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s explore the 5 different ways you can run code on Cloud Run… but for something a little different… we’ll explore this from your code’s point-of-view!

1. Services — the original
2. Jobs — containers that run end-to-end
3. Worker pools — continuously running workers without a HTTP endpoint
4. Cloud Run functions — previously known as Cloud Functions (unless you’re using Cloud Functions for Firebase)
5. (new!) Cloud Run instances — stateful, long-lived singleton workloads for agents or a dev environment

For this blog post, we’re going to use a Hello World sample for a web service as shown below in Services. You’ll see how the code changes to fit each resource type.

1. Services

Use Case: Stateless HTTP server that scales to zero when idle.

How your code looks: Note there’s an endpoint for the root `/` route handler

# main.py

from fastapi import FastAPI
app = FastAPI()

@app.get("/")
def hello():
    return {"message": "Hello World!"}

#requirements.txt

fastapi[standard]

How to Deploy: We’ll use buildpacks to build the container image for us via the --source flag

gcloud run deploy hello-service \
 --source . \
 --region=europe-west1 \
 --allow-unauthenticated

How to Use: Retrieve the service URL and curl it.

SERVICE_URL=$(gcloud run services describe hello-service --region=europe-west1 --format='value(status.url)')
curl $SERVICE_URL

2. Jobs

Use Case: Run a container to completion. There’s no idle / warm start or state persistence. No HTTP endpoint. Code is noticeably smaller to print Hello World.

# main.py

print("Hello World!")

# Procfile

web: python3 main.py

How to deploy: By default, buildpacks expect to build a web app. You’ll need to specify a Procfile to tell Cloud Run how to run the Python script.

gcloud run jobs deploy hello-job \
  --source . \
  --region=europe-west1

How to use: Whenever you’re ready to execute your job, run jobs execute. The wait flag forces your terminal to wait for the job to complete before moving on.

gcloud run jobs execute hello-job --region=europe-west1 --wait

If you want to combine both the execute command and the deploy command, just add — execute-now to the deploy command.

3. Cloud Run Worker Pools

Use Case: Continuously running workers for background processing (like pulling messages from Pub/Sub, Kafka, or Temporal queues). It has no HTTP endpoint or health-check port.

How your code looks: Note the while True loop.

import time

while True:
    print("Hello World! Polling background queue...", flush=True)
    # code goes here, e.g. pulling from PubSub to process a message
    time.sleep(10)

# Procfile

web: python3 main.py

How to deploy: You’ll deploy to the worker-pools resource type. Similar to Jobs, you’ll need to use a Procfile for the source deploy.

gcloud run worker-pools deploy hello-worker \
  --source . \
  --region=europe-west1

How to use: Unlike Services (which wait for an HTTP request) or Jobs (which wait for you to execute them), a Worker Pool starts running your container immediately upon deployment!

# Check the logs to see your worker printing every 10 seconds
gcloud run worker-pools logs read hello-worker --region=europe-west1 --limit=10

# Or stream the logs
gcloud run worker-pools logs tail hello-worker --region=europe-west1

Important! Because worker pools run continuously and are billed while active, you’ll want to set instances to 0 to take the worker pool offline (set it to inactive, but without deleting it).

gcloud run worker-pools update hello-worker \
  --region=europe-west1 
   --instances=0

4. Cloud Run functions

Use Case: Minimal event-driven or HTTP handler where you only write a single Python function instead of initializing a web framework. You use the open source functions-framework for your specified language, instead of using your own web service (e.g. the FastAPI in the Service example).

How your code looks:

# main.py
import functions_framework

# note: this is the event handler that you specify with the --function on deploy
@functions_framework.http
def hello_function(request):
    return "Hello from a Cloud Run Function!"

# requirements.txt

functions-framework

How to deploy: When you use the --function flag to indicate you’re deploying a function, the Python runtime automatically provides the functions-framework.

gcloud run deploy hello-func \
  --region=europe-west1 \
  --source . \
  --function hello_function \
  --allow-unauthenticated

How to use: Just curl your function’s URL

FUNCTION_URL=$(gcloud run services describe hello-func --region=europe-west1 --format='value(status.url)')

curl $FUNCTION_URL

5. Cloud Run instances

Use Case: new! Cloud Run resource type (in public preview via gcloud beta). This resource type is designed for stateful, long-lived singleton workloads like personal AI agents (e.g., OpenClaw, Claude/ADK agents) or dev environments.

How it differs from Services:

• Singleton: Runs exactly 1 instance with zero autoscaling.
• Lifecycle: Runs continuously for up to 7 days with an automatic restart policy (always, on-failure, never), and you manually stop, start, or restart it.
• Pricing: Cloud Run instances use shared vCPU with vCPU burst budgets to run continuously for a low, predictable price

Note we’re switching to europe-west4 (because instances isn’t available in europe-west1)

How your code looks:

# main.py

from fastapi import FastAPI
app = FastAPI()

# to see the long live nature of the instance
memory_count = 0

@app.get("/")
def hello_agent():
    global memory_count
    memory_count += 1
    return {"message": f"Hello World! In-memory count: {memory_count}"}

# requirements.txt

fastapi[standard]

How to deploy: there is no source deploy at this time in public preview. You’ll have to build the image yourself first for now.

# 1. Build from source without a Dockerfile using Buildpacks
gcloud builds submit --pack image=europe-west4-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy/hello-instance

# 2. Deploy the singleton Cloud Run Instance
gcloud beta run instances deploy hello-instance \
  --region=europe-west4 \
  --image europe-west4-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy/hello-instance \
  --public

How to run: Curl the instance URL.

INSTANCE_URL=$(gcloud beta run instances describe hello-instance --region=europe-west4 --format='value(status.urls[0])')

curl $INSTANCE_URL

Important: Remember to stop your instance when you are done

gcloud beta run instances stop hello-instance --region europe-west4

6. Bonus!

Wow! If you’ve made it all the way here, you must really like Cloud Run and that’s super cool. Here’s an extra tip. We now have ssh in public preview. This works great with Cloud Run instances. Here’s the tutorial for how you can ssh into your instance.

# If needed start your instance:
# gcloud beta run instances start hello-instance --region europe-west4

gcloud beta run instances ssh hello-instance --region=europe-west4

# Stop your instance:  
# gcloud beta run instances stop hello-instance --region europe-west4

A tour of the Cloud Run resource types was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

In September, I sat the beta exam for Google Cloud’s latest credential: the Professional Agentic Architect.

Google has taken a fundamentally new direction with this track. Rather than relying solely on traditional multiple-choice questions, this is Google Cloud’s first hybrid certification. Earning the badge requires clearing two distinct stages: a proctored theoretical exam (Part 1), followed by a hands-on lab assessment delivered through Google Skills (Part 2).

Between building applications with Google’s Agent Development Kit (ADK), working across the Gemini Enterprise ecosystem in my day job, and using Antigravity regularly, I was keen to see how my hands-on experience stacked up against Google’s expectations.

After completing the proctored exam and subsequently clearing the challenge labs, I am now officially certified as a Google Cloud Professional Agentic Architect, taking me to 14 active Google Cloud certifications in total.

Here is the breakdown of the OnVUE testing setup, what the Part 1 question dynamic felt like, the core architectural domains you need to master, and what to expect when you transition into the live challenge labs for Part 2.

The Remote Proctoring Setup: OnVUE vs. Kryterion Webassessor

With no local test centres nearby, remote proctoring has been my default for years. If you’ve taken Google Cloud certifications previously, you’ll be well accustomed to Kryterion’s Webassessor portal and Sentinel software. Sitting Part 1 of this exam was my first experience with Pearson VUE’s OnVUE platform following Google’s delivery migration, and the operational differences were noticeable from the start:

• Mobile-first check-in flow: OnVUE offloads identity and environment verification directly to your phone. Once you launch the session on your laptop, you scan a QR code to capture high-res photos of your ID, snap a verification selfie, and submit four clear angle shots of your workspace (front, back, left, right) before placing the phone out of arm’s reach.
• The queue and proctor sweep: I logged in 15 minutes ahead of my scheduled window to run automated system, mic, and webcam checks. Once my phone photos were submitted, I entered a queue at position 13, taking just under 15 minutes for a proctor to connect. While Webassessor leaned heavily on background biometric profiles, OnVUE proctors are much more hands-on, requiring me to lift my laptop for an active 360-degree sweep of the entire room, including the space underneath the desk and behind the laptop screen, before unlocking the test.
• The clean-desk reality: While the delivery platform has changed, the remote testing discipline hasn’t. You still need an entirely cleared workspace: second monitors unplugged and turned away, paper and clutter completely cleared, and your desk kept entirely bare throughout the session.
• Rescheduling flexibility: Client deliverables ramped up right before my initial test date, forcing me to push my slot back. OnVUE’s rescheduling was remarkably painless compared to Webassessor- there was wide availability across alternative time slots, and the system let me adjust the booking right up to the start time without friction.

Exam Structure & The Beta Dynamic

Because this was a beta, the format differed slightly from what the final General Availability (GA) exam will look like:

*Note: Unlike standard Google Cloud certifications that grant you two years of peace, this badge is only valid for 1 year. Given the rapid evolution of agentic protocols, security tooling, and the fact that we get a new Gemini model drop almost weekly lately, an annual renewal makes sense.*

Part 1: Question Pool Dynamic

With an uncalibrated beta question pool, the questions largely fell into two styles:

1. System design problems: Questions that test genuine design trade-offs across multi-agent handoffs, token management, and evaluation pipelines. The key is methodically stepping through the data path between the caller, gateway, agent runtime, and backend tools.
2. Obvious eliminations: Questions where several distractors flagrantly violate basic Google Cloud security principles. You can cross them off immediately if an option suggests controlling hard security via system prompts, assigning excessive service account roles, or bypassing code sandboxing.

Pacing felt comfortable. With 75 questions across 180 minutes, you have roughly 2.4 minutes per question. I wrapped up the exam with about 40 minutes remaining, even after reviewing flagged questions. For GA, Professional Certification exams are usually ~50 questions across 120 minutes.

Official Exam Guide Domains & Weightings

The technical requirements for both parts map directly across five documented domains from the Professional Agentic Architect Exam Guide:

Core Technical Themes to Master

Whether you are answering architectural questions in the exam, or implementing resources in hands-on labs, the following technical themes form the backbone of the credential:

1. The Gemini Enterprise Ecosystem & Low-Code Agents (~13%)

To clear this domain, you should be comfortable with:

• End-to-End Architectural Integration: Understand how user-facing interfaces (such as the Gemini Enterprise app or custom web front-ends) link down into the agent runtime. Know how conversational agents, tool extensions, and grounded search collaborate, and where the architectural boundary sits between low-code configuration and custom code implementations.
• Conversational Flow & CX State Management: Review how state-based multi-turn dialogues are structured in Agent Designer / CX Agent Studio consoles. Be clear on how pages, transition routes, conditional event handlers, and fallback flows operate to guide user intent and handle unexpected inputs.
• Enterprise Grounding & Data Stores: Know how to configure managed data stores across structured, unstructured, and multimodal repositories (text documents, audio, and video). Understand how chunking strategies, semantic search, and metadata filtering prevent hallucinations and keep responses strictly grounded.
• Tool Extensions & API Contracts: Understand how low-code agents invoke external business logic. Review how OpenAPI schemas define tool contracts, how authentication is passed to downstream APIs, and how Agent Gateway enforces ingress and egress policies around tool invocation.

2. Using Coding Agents for Application Development (~17%)

This domain shifts the focus from building user-facing conversational apps to developer tooling and engineering autonomy, specifically using Google Antigravity and Claude Code on Google Cloud to refactor code, optimise execution runtimes, and patch application-layer vulnerabilities.

To clear this section, make sure you understand:

• Antigravity Customisation (Rules vs. Skills): Know how to govern agent behaviour across workspace, directory, and global scopes. Rules enforce non-negotiable architectural boundaries and coding constraints (e.g., via AGENTS.md or .agents/rules/), whereas Skills, plugins, extension hooks, and subagents provide reusable, procedural task workflows.
• Model Context Protocol (MCP) & Tool Access: Understand how coding agents connect to external environments, file systems, databases, and enterprise services through standard MCP client/server integrations.
• Execution Sandboxing & Isolation: Recognise the security risks of autonomous dynamic execution. Be clear on when and how coding agents must be confined to isolated execution environments, such as GKE Agent Sandboxes, Cloud Workstations, or Antigravity’s hosted sandboxes, to run untrusted shell scripts and dynamic tests safely.
• Enterprise Tooling with Agents CLI: Understand how to augment Antigravity using the Agents CLI to script, scale, govern, and optimise coding agents consistently across a team.

3. Custom Agent Architecture & ADK (~33%)

Section 3 represents a third of the entire syllabus. You need to know how to structure and code multi-agent systems using the Agent Development Kit (ADK).

• Multi-Agent Topologies: Understand the architectural differences between a centralised orchestrator (supervisor delegating tasks to specialised sub-agents) and decentralised handoffs using Agent-to-Agent (A2A) protocols across different domain teams.
• State Management and Keys: Know how state flows through an agent runtime. Review how output keys and state prefixes are configured so that parallel sub-agents don’t accidentally overwrite shared context or stomp on conversational history.
• Session State vs. Long-Term Memory: Be clear on the operational boundary between short-term conversational turns (sessions) and durable user context. Understand how Memory Bank extracts and persists semantic facts across distinct user interactions.
• Agent Workload Identity: Review how cryptographic identities are assigned to autonomous runtimes. Understand where SPIFFE-based identities and Principal Access Boundaries (PAB) fit when an agent needs to prove its identity to access backend cloud infrastructure.

4. Evaluating and Deploying Agentic Workflows (~22%)

Deterministic unit tests won’t cut it when you’re evaluating probabilistic model outputs, you need systematic evaluation frameworks.

• Tool Trajectory Evaluation: Evaluating the final text response of an agent is insufficient. You must evaluate the trajectory, verifying that the agent invoked the correct sequence of tools, passed valid argument schemas, and reached the resolution without entering looping cycles.
• Handling Live Data Drift in Evals: A frequent challenge with agent evaluation suites is that testing against live APIs causes tests to fail due to changing production data rather than logic bugs. Understand how to design resilient evaluation pipelines using mock data layers, synthetic fixtures, or LLM-as-a-judge patterns to evaluate decision-making independently of live API churn.
• Context Caching: With long system prompts and extensive tool schemas, context caching is essential to keep latency and billable token counts under control. Focus on how immutable prompt prefixes are cached.
• OpenTelemetry (OTel): Know how to instrument agent runtimes with distributed tracing to track end-to-end latency across reasoning loops, vector retrieval, and external tool calls.

5. Securing and Governing Agentic Workflows (~15%)

Security is the most critical design constraint when moving agents from internal prototypes to production systems.

• Agent Gateway Topology: Treat Agent Gateway as your security perimeter. Be ready to configure both ingress (shielding the runtime from untrusted callers) and egress (strictly scoping the external APIs, databases, or MCP tools the agent can reach).
• Model Armor & Content Safety: Study how Model Armor hooks into the gateway pipeline. Understand how to configure templates to catch prompt injection, detect jailbreak attempts, and block unsafe content before user inputs reach the model.
• Sensitive Data Protection (SDP): Know how SDP combines with Model Armor to dynamically mask, tokenise, or redact PII before it gets logged in telemetry or forwarded to downstream tools.
• Delegated Authorisation (User OAuth vs. Service Account): Pay close attention to credential delegation. When an agent calls an external API, it should rarely use a broad, ambient service account identity. Instead, it should execute the tool using the end user’s delegated OAuth token, ensuring the agent cannot execute actions the calling user does not have permission to perform.

Recommended Preparation & Study Resources

Because this certification is brand new, the most effective preparation will come from working directly with Google’s official materials and getting hands-on in the console and code:

• The Official Exam Guide: Start by reviewing the Professional Agentic Architect Exam Guide. Use the five domains as a personal gap analysis to identify which services or runtime patterns you haven’t worked with hands-on.
• Official Sample Questions: Work through the official sample questions published on Google Cloud’s certification hub. Even though it is a small set, it gives you a clear baseline of how Google frames scenario questions, distractor patterns, and technical tradeoffs.
• Professional Agentic Architect Learning Path: Make your way through the Professional Agentic Architect path on skills.google. I didn’t have the time to complete the entire path end-to-end before my beta booking, but I worked through a handful of the core modules beforehand. It is remarkably thorough, goes deep into real implementation patterns, and I highly recommend working through it if you want structured coverage of the full syllabus.
• Hands-On Code Frameworks: Spend dedicated time inside the open-source Agent Development Kit (ADK) repository. Build out custom multi-agent topologies, trace how state and memory keys flow between agents, and write local trajectory evaluation tests before sitting Part 1 or tackling the Part 2 labs.

The Transition: From Part 1 to Part 2 via CertMetrics

Once you’ve cleared the architectural theory, you enter the operational handoff to the hands-on labs. While I expect automated email notifications will be in place once the certification rolls out to General Availability, that wasn’t the case during the beta run, I never actually received an email confirming I had cleared the theoretical exam.

If you’ve completed Part 1 and find yourself waiting around for an email notification, don’t wait on it. Head straight to the source:

1. Log directly into the Google Cloud CertMetrics portal.
2. Check your exam history to see if your result has updated to a pass.
3. Once your passing status is recorded, you will see the option to launch Part 2 of the certification.
4. Clicking that link routes you straight into your assigned hands-on assessment track on skills.google.

Part 2: The Hands-On Challenge Labs

Once you launch Part 2 on skills.google, you enter the practical evaluation phase.

Lab Structure & Rules

• 3 Challenge Labs Presented — Pass Any 2: You are presented with a selection of three distinct challenge labs. To achieve certification, you need to successfully pass two of them.
• 100% Completion Bar: Just like standard Google Cloud challenge labs, there is no partial credit. Passing a lab requires achieving a 100% score, progressing through all milestone assessment checks.
• Lab Durations: Google’s estimated completion times ranged from 45 minutes up to 1 hour 30 minutes depending on the lab complexity. However, the actual allotted lab timer is greater than this, giving you plenty of time if you need to troubleshoot or wait for services to initialise (although this wasn’t an issue for my labs).
• Standard Challenge Lab Format: If you have completed challenge labs on skills.google before, the process is the same: an objective brief, architecture constraints, and an automated tracking script that evaluates your environment as you complete each phase.

Practical Tips for the Challenge Labs

• Exact Naming Is Non-Negotiable: Like every challenge lab on skills.google, the automated background grading scripts look for exact string matches. Whether you are provisioning services in the console or running scripts, copy and paste the resource names, IDs, and variables directly from the lab brief. A single typo will fail a milestone check even if the underlying build is functioning.
• Respect Propagation Time: Avoid hitting “Check My Progress” the millisecond a resource shows as created. Cloud control planes and service bindings can take a minute or two to settle across the environment. Rushing the verification check can result in a false-negative score.
• Read the Whole Brief First: It’s tempting to jump straight into the first objective, but later tasks often impose constraints on earlier setups. Spend the first five minutes reading through all phases of the scenario so you don’t build yourself into a corner that requires re-deploying resources on the clock.

Final Thoughts

I really liked the format of this exam. Combining a comprehensive theory test with time-constrained, hands-on challenge labs makes total sense for this domain. Rather than testing purely conceptual designs, it focuses directly on the practical engineering required to build, secure, and productionise agentic systems on Google Cloud.

While a solid grasp of the theory is essential, the breadth of topics covered means you cannot rely on reading documentation alone. You need genuine hands-on experience across the stack. That means writing custom agents and multi-agent topologies in ADK, configuring security controls like Agent Gateway and delegated auth, and working through the operational realities of taking an agent to production.

Above all, pay close attention to evaluations. Understanding how to measure tool trajectories, detect looping behaviours, and implement reliable evaluation patterns is critical before deploying autonomous systems into enterprise environments.

If you sat the beta as well, or you’re gearing up to take the exam once it lands in General Availability, let me know your thoughts or drop any questions in the comments below!

Thanks for reading! Please feel free to share, subscribe for updates, or follow me on LinkedIn.

Other Guides: If you are planning your Google Cloud certification journey or deciding which track to pursue next, check out my other exam breakdowns:

• Google Cloud Professional Cloud Developer Exam Guide (2026 Renewal)
• Google Cloud Professional Database Engineer Exam Guide
• Google Cloud Generative AI Leader Certification (GAIL)
• Google Cloud Professional Cloud Architect (PCA) Renewal Certification
• Google Cloud Professional Cloud DevOps Engineer
• Google Cloud Professional Network Engineer Certification (PNE)
• Google Cloud Associate Data Practitioner Certification (ADP)
• Google Cloud Digital Leader Certification (CDL)

Originally published at https://www.cloudbabble.co.uk on November 3, 2026.

Google Cloud Professional Agentic Architect Exam Guide: Passing the Exam & Challenge Labs was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn how to run model explainability in Vertex AI !

This GCP ML project focuses on explaining loan default risk predictions where you train an XGBoost classifier on FICO consumer credit data, register it on Vertex, and run one batch job that returns each borrower’s predicted probability (of RiskPerformance = 1, good credit) plus per-feature attributions in BigQuery.

🗃️ GCS is used to store the sample input data
🔍BigQuery holds the batch input rows and the explanation output table
🤖Vertex AI uploads the model and runs batch prediction with explanations enabled

These services work together to train the model, run batch explanations, and write results to BigQuery.

Find the code and CSV file on my github account

gcp-ml-tutorials/vertex-batch-explainability at main · 04pallav/gcp-ml-tutorials

🗃️ Step 1 — Upload data to GCS

Upload the provided CSV file to your designated Google Cloud Storage (GCS) bucket. This sample data comes from the FICO consumer credit dataset on OpenML — 10,000 borrowers a lender might score and explain. Feature definitions and missing-value codes (-7, -8, -9) are documented on that OpenML page. Each row includes bureau features such as ExternalRiskEstimate, NumInqLast6M, NetFractionRevolvingBurden, MSinceMostRecentDelq, and PercentTradesNeverDelq — outside risk score, recent credit applications, revolving utilization, months since last delinquency, and share of accounts never delinquent.

☁️ Step 2 — Set up cloud shell

Set the project and install XGBoost, scikit-learn and the Vertex AI SDK.

👨‍💻 gcloud config set project your-project-id

👨‍💻 pip install google-cloud-aiplatform 'scikit-learn==1.6.*' 'xgboost==2.1.*' matplotlib

📊 Step 3 — Load data to BigQuery

The load step reads instances.csv and writes the 22 feature columns to BigQuery table heloc_batch_input (the RiskPerformance label stays in the CSV but is not loaded into BigQuery).

👨‍💻 python batch_explain.py load --instances gs://your-bucket/instances.csv

Then inspect the rows in BigQuery:

SELECT * FROM `your-project-id.ml_explainability.heloc_batch_input` ORDER BY ExternalRiskEstimate DESC LIMIT 10;

You should see 10,000 rows from instances.csv.

⚙️ Step 4 — Train model

The train() method in batch_explain.py fits an XGBoost classifier (binary:logistic) on instances.csv. We predict probability — the chance that RiskPerformance = 1. In this CSV 1 is good credit (that group has the higher average ExternalRiskEstimate) and 0 is bad (90+ days past due), so a low probability means higher default risk.

We use XGBoost because Vertex’s prebuilt XGBoost container serves Booster.predict(), which returns that probability. The prebuilt scikit-learn container calls .predict() instead, which returns a 0/1 class label for a classifier, so the explanations would attribute a label rather than a probability.

The train step fits the model and uploads model.bst and train_metrics.png to your bucket.

👨‍💻 python batch_explain.py train --bucket-uri gs://your-bucket/vertex-batch-explain

Confirm model.bst landed in gs://your-bucket/vertex-batch-explain/models/.

Check the printed train/test ROC AUC in the terminal. The script also saves train_metrics.png to the same folder — XGBoost feature importances on the left (which features the model relies on most) and the test-set ROC curve on the right.

⌛️Step 5 — Run batch explanation job

The explain step registers your model on Vertex AI, then starts a batch job that scores every row and writes feature attributions to BigQuery.

Model.upload() — register the model

model = aiplatform.Model.upload(
    display_name="heloc-batch-explain-xgb",  # name shown in the Vertex AI console
    artifact_uri=uri,  # GCS path to model.bst from Step 4
    serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/xgboost-cpu.2-1:latest",
    explanation_parameters=aiplatform.explain.ExplanationParameters(
        {"sampled_shapley_attribution": {"path_count": 10}},  # Sampled Shapley: 10 permutations per row
    ),
    explanation_metadata=aiplatform.explain.ExplanationMetadata(
        inputs={"input": {"index_feature_mapping": FEATURES, "encoding": "BAG_OF_FEATURES"}},
        outputs={"probability": {}},
    ),
)

Model.upload() registers the model on Vertex AI — GCS artifact + XGBoost serving container + explanation settings. Batch prediction sends each row as a fixed-order list ([55, 144, 58, …]), so BAG_OF_FEATURES and index_feature_mapping tell Vertex which index maps to which feature name in the attributions.

See ExplanationMetadata Encoding.

explanation_parameters picks how attributions are computed. sampled_shapley_attribution with path_count: 10 estimates each feature's contribution by averaging over 10 random feature permutations (Shapley values). Higher path_count improves the approximation but costs more per row — we use 10 here to keep the tutorial job fast.

batch_predict() — score + explain every row

job = model.batch_predict(
    job_display_name="heloc-batch-explain-job",  # label in Vertex AI → Batch predictions
    instances_format="bigquery",
    bigquery_source="bq://your-project-id.ml_explainability.heloc_batch_input",
    predictions_format="bigquery",
    bigquery_destination_prefix="bq://your-project-id.ml_explainability.heloc_batch_explanations",
    generate_explanation=True,  # per-feature attributions, not just scores
    machine_type="n2-standard-4",  # VM size for each prediction replica
    batch_size=16,  # rows per request to the model server
    starting_replica_count=1,
    max_replica_count=1,  # 1 replica — tutorial scale
)

👨‍💻 python batch_explain.py explain --bucket-uri gs://your-bucket/vertex-batch-explain

❗ Make sure that all your files and services are in the same location. E.g. both buckets should be in the same location or you will get a similar error message: ‘Cannot read and write in different locations: source: US, destination: EU’

Open Vertex AI → Batch predictions in the console and wait for JOB_STATE_SUCCEEDED.

🔍 Step 6 — Inspect the explanations in BigQuery

After the batch job finishes, open the output table:

SELECT * FROM `your-project-id.ml_explainability.heloc_batch_explanations` LIMIT 10;

Each row has a prediction and feature attributions — how much each input feature pushed the score up or down for that borrower.

The explanation column holds the attributions as JSON. To see them for one borrower, the plot step reads the borrower with the highest predicted probability from heloc_batch_explanations, draws a waterfall chart, and uploads it to your bucket as attribution_example.png.

👨‍💻 python batch_explain.py plot --bucket-uri gs://your-bucket/vertex-batch-explain

Read the chart from the bottom up. It starts at E[f(X)], the baseline prediction, and each bar moves the probability by one feature's attribution — red pushes it up, blue pushes it down — until it reaches f(x), this borrower's prediction. The baseline plus all the attributions equals the prediction. The number before each feature name is this borrower's value for it, and the smallest features are grouped into one row.

About

GCP ML explainability on consumer credit data — BigQuery in, probabilities + feature attributions out.

GCP ML Project: Explaining Loan Default Risk Predictions with Vertex AI, BigQuery and XGBoost 🔍 was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my Agent Protocols — MCP, A2A, A2UI, AG-UI post back in March, I provided a high-level overview of the main agent protocols for tool use (MCP), agent-to-agent communication (A2A), and agent-to-UI interactions (AG-UI and A2UI).

Recently, I had a chance to explore two newer protocols focused on agentic commerce and payments: the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2). Traditional e-commerce and payment flows assume a human is directly browsing a website and clicking “Buy” on a trusted checkout screen. When an AI agent shops and pays on your behalf, both the commerce workflow and the cryptographic proof of user authorization need a standard language.

In this post, I’ll share an update on the agent protocol landscape by introducing UCP and AP2, explaining how they work together, and walking through the new Python and ADK samples I added to my genai-beyond-basics repository.

TLDR

With UCP and AP2 added to the mix, here’s how the six agent protocols in my repository fit together:

• Model Context Protocol (MCP): An open protocol, from Anthropic, that standardizes how models and agents access external tools and resources
• Agent2Agent Protocol (A2A): An open protocol, from Google, that standardizes how agents running on diverse frameworks and platforms communicate
• Agent-User Interaction Protocol (AG-UI): An open protocol, from CopilotKit, that standardizes how agents communicate with user interfaces
• Agent to UI Protocol (A2UI): A generative UI protocol, from Google, that enables AI agents to generate rich, interactive user interfaces across web, mobile, and desktop
• Universal Commerce Protocol (UCP): An open standard, co-developed by Google, Shopify, and industry partners, that standardizes merchant discovery, capability negotiation, and checkout sessions for agentic commerce
• Agent Payments Protocol (AP2): An open protocol, from Google, that secures agent-initiated payments using cryptographically signed mandates and verifiable credentials

Let’s look into UCP and AP2 in more detail.

Universal Commerce Protocol (UCP)

Universal Commerce Protocol (UCP) is an open standard, co-developed by Google, Shopify, and industry partners (including Target, Walmart, Wayfair, Etsy, and Stripe), that defines functional primitives for agentic commerce. It allows AI agents, consumer platforms, businesses (who remain the Merchant of Record), credential providers, and payment service providers to interoperate without bespoke one-off integrations.

Architecture, Discovery, and Capability Negotiation

UCP is structured around four layers:

• Services: Domain groupings such as dev.ucp.shopping, dev.ucp.common, and dev.ucp.lodging.
• Capabilities: Versioned features (“verbs”) within a service, such as dev.ucp.shopping.checkout, dev.ucp.shopping.cart, and dev.ucp.shopping.catalog.search.
• Extensions: Optional schemas that augment a parent capability via extends (e.g., dev.ucp.shopping.fulfillment, dev.ucp.shopping.discount, and dev.ucp.common.payment.ap2_mandate).
• Transports: Transport-agnostic bindings supporting REST (OpenAPI 3.1), MCP (OpenRPC), A2A (Agent Card), and Embedded (OpenRPC).

Every UCP merchant publishes an unauthenticated JSON profile at GET /.well-known/ucp advertising its protocol version, capabilities, payment handlers (com.google.pay, dev.shopify.shop_pay), and JWK signing keys (ES256 as the mandatory baseline, plus optional Ed25519 for Web Bot Auth interop). Permissionless request authentication across HTTP transports uses HTTP Message Signatures (RFC 9421) resolved directly against the public keys in each party's profile. When an agent calls a merchant, UCP uses a server-selects negotiation model:

The merchant computes the intersection between its declared capabilities and the agent’s profile, selects the latest mutually supported YYYY-MM-DD version, and prunes any orphaned extensions whose parent capability isn't active.

Once a checkout session starts, dev.ucp.shopping.checkout progresses through six explicit states so an AI agent always knows whether it can finish the purchase autonomously or must hand off to the user:

• incomplete: Missing required details (such as buyer email or shipping method).
• requires_escalation: Requires direct buyer input via a continue_url handoff (e.g., custom configuration or 3DS challenge).
• ready_for_complete: All line items, totals, and fulfillment details are finalized; ready for payment submission.
• complete_in_progress: Checkout completion is currently executing (new PUT updates are rejected while in progress).
• completed: Payment processed and OrderConfirmation (order.id, order.permalink_url) generated.
• canceled: Checkout session was canceled (POST /checkout-sessions/{id}/cancel) or expired.

ℹ️ Note: All monetary amounts in UCP (and AP2) are expressed in minor currency units (cents) — for example, 2500 for $25.00, and negative integers like -400 for a -$4.00 discount.

UCP Samples: Python SDK & Google ADK

In my UCP samples folder, I created two samples using the official UCP Python SDK (ucp-sdk):

1. UCP Hello World (Python SDK & FastAPI): A self-contained FastAPI merchant server (server.py) and client script (client.py) that validates payloads against BusinessSchema and Checkout models from ucp_sdk. Because client.py mounts server.py in-process via httpx.ASGITransport by default, you can run the entire 4-step UCP lifecycle in a single command:

uv run --with ucp-sdk --with fastapi --with httpx python client.py

=== 1. UCP Discovery (GET /.well-known/ucp) ===
Protocol Version:  2026-08-25
Services:          ['dev.ucp.shopping']
Capabilities:      ['dev.ucp.shopping.checkout', 'dev.ucp.shopping.fulfillment', 'dev.ucp.shopping.discount']
Payment Handlers:  ['com.google.pay', 'dev.shopify.shop_pay']
Signing Key (kid): merchant_key_2026
 
=== 2. Create Checkout Session (POST /checkout-sessions) ===
Checkout ID:       chk_9c35e04f
Checkout Status:   incomplete
Negotiated Caps:   ['dev.ucp.shopping.checkout', 'dev.ucp.shopping.fulfillment', 'dev.ucp.shopping.discount']
  - 1x Red Roses Bouquet (sku_roses): $25.00
  - 1x Ceramic Vase (sku_vase): $15.00
 
=== 3. Update Checkout: Fulfillment & Discount (PUT /checkout-sessions/chk_9c35e04f) ===
Checkout Status:   ready_for_complete
Totals Breakdown:
  - Subtotal                : $40.00
  - 10% Promo (SAVE10)      : -$4.00
  - Shipping (Express Delivery): $5.00
  - Total                   : $41.00
 
=== 4. Complete Checkout (POST /checkout-sessions/chk_9c35e04f/complete) ===
Checkout Status:   completed
Order Created:     Order #ORD_EF9FCC12 (id=ord_ef9fcc12)
Order Permalink:   https://flowershop.example.com/orders/ord_ef9fcc12

2. UCP Shopping Agent with Google ADK: An interactive Agent Development Kit (ADK) agent (shopping_agent/agent.py) equipped with UCP discovery and checkout tools:

root_agent = Agent(
    name="ucp_shopping_agent",
    model="gemini-2.5-flash",
    description="AI Shopping Agent that discovers merchants and completes purchases using the Universal Commerce Protocol (UCP).",
    instruction=...,
    tools=[
        discover_merchant,
        create_checkout_session,
        update_checkout_session,
        complete_checkout_session,
    ],
)

Start server.py in one terminal and adk web in another, and you can ask the agent what the merchant supports and have it negotiate extensions, apply promo codes, and complete an order conversationally.

Agent Payments Protocol (AP2)

While UCP standardizes the commerce session, a big question remains: How does a merchant or payment processor know that an AI agent actually has the user’s permission to spend their money — and didn’t hallucinate the item or price?

That’s where the Agent Payments Protocol (AP2) comes in. Originated by Google, AP2 is an open security and authorization protocol that replaces “trusting the LLM’s text summary” with Verifiable Digital Credentials (VDCs) — specifically tamper-evident SD-JWTs (Selective Disclosure JWTs) and KB-SD-JWT (Key-Binding SD-JWT) delegation chains.

Trust Boundary, Mandates (v0.2), and Delegation Chains

A key rule in the AP2 v0.2 specification is the strict separation between Agentic (LLM-driven) and Non-Agentic (deterministic) roles:

• The Shopping Agent is expected to be agentic.
• The Trusted Surface (where the user approves and signs mandates) MUST be non-agentic.
• Even if a Merchant, Credential Provider, or Payment Processor exposes an agentic interface, all mandate validation and constraint verification MUST execute in deterministic code.

In early AP2 overviews (v0.1), mandates were described conceptually as Intent, Cart, and Payment mandates. In AP2 v0.2 (and the official ap2.sdk Python package), this is formalized into two linked mandate families — Checkout Mandates (securing what is purchased) and Payment Mandates (securing how it is paid) — each with an Open and Closed state, supporting two modes:

1. Human Present (Direct Flow): The user reviews the assembled cart on a Trusted Surface and directly signs the Closed Checkout Mandate (mandate.checkout.1) and Closed Payment Mandate (mandate.payment.1), bound to the merchant-signed UCP checkout_jwt via checkout_hash.
2. Human Not Present (Autonomous Flow): The user pre-authorizes an Open Checkout Mandate (mandate.checkout.open.1) and Open Payment Mandate (mandate.payment.open.1) with deterministic constraints (e.g., allowed merchants, acceptable SKUs, and a maximum budget) and binds the Shopping Agent's public key in the cnf claim. Later, when the condition is met (such as a price drop), the Shopping Agent signs the Closed Mandates with its own private key and chains them onto the user's open mandates (open_sd_jwt~~closed_kb_sd_jwt~):

AP2 supports two trust models for issuing the root Mandate on the Trusted Surface (User Credential Model via OpenID4VP and the browser Digital Credentials API, or Trusted Agent Provider Model signed by the agent provider’s key) and enforces two normative presentation rules on the Shopping Agent: Selective Disclosure Minimization (revealing only the disclosures required to evaluate the Closed Mandate) and Sequential Presentation (preventing concurrent reuse of an Open Mandate across multiple checkouts without a prior rejection receipt).

AP2 Sample: Mandate Delegation & Guardrails in Python

The official google-agentic-commerce/AP2 repository includes full multi-server A2A and MCP scenarios (using Cards or x402 stablecoins), which I documented in my AP2 README.

However, spinning up four separate servers just to see how AP2 mandates work under the hood can be heavy. So I also built a self-contained AP2 Hello World (mandate_demo.py) sample using the official ap2.sdk package that runs an entire Autonomous (Human Not Present) flow in a single script with no API keys required.

Let’s take a quick look at what’s happening under the hood in mandate_demo.py. First, the user (on a Trusted Surface) signs an OpenCheckoutMandate and an OpenPaymentMandate capping the spend at $150.00 (15000 cents), linking to the open checkout mandate hash via PaymentReference, and binding the agent's public key via cnf:

open_checkout_hash = compute_sha256_b64url(open_checkout_token)
 
open_payment_token = client.create(
    payloads=[
        OpenPaymentMandate(
            constraints=[
                AmountRange(currency="USD", min=0, max=15000),
                AllowedPayees(allowed=[merchant]),
                PaymentReference(conditional_transaction_id=open_checkout_hash),
            ],
            cnf={"jwk": agent_pub_dict},
            iat=now,
            exp=now + 3600,
        )
    ],
    issuer_key=user_jwk,
)

When the merchant returns a signed UCP Checkout JWT for $120.00, the Shopping Agent autonomously signs and chains the closed mandates using MandateClient.present(), and the Merchant and Payment Processor deterministically verify the chain (CheckoutMandateChain and PaymentMandateChain):

payment_chain_token = client.present(
    holder_key=agent_jwk,
    mandate_token=open_payment_token,
    payloads=[closed_payment],
    aud="credential-provider",
    nonce="nonce_pay_98765",
)
 
payment_payloads = client.verify(
    token=payment_chain_token,
    key_or_provider=lambda _tok: user_pub_jwk,
    expected_aud="credential-provider",
    expected_nonce="nonce_pay_98765",
)
payment_chain = PaymentMandateChain.parse(payment_payloads)
payment_violations = payment_chain.verify(
    expected_transaction_id=checkout_hash,
    expected_open_checkout_hash=open_checkout_hash,
)

You can run the sample with a single uv command:

uv run --with "ap2 @ git+https://github.com/google-agentic-commerce/AP2.git" python mandate_demo.py

Notice in step 6 how deterministic verification immediately catches and rejects an agent that tries to spend $250.00 against the user's $150.00 open mandate:

=== 1. Generating Keys for User (Trusted Surface), Agent, and Merchant ===
 
=== 2. User Signs Open Mandates on Trusted Surface (SD-JWT) ===
Intent: 'Buy white running shoes (SKU-SHOE-WHITE) from RunFast Store for at most $150.00'
Open Checkout Mandate (SD-JWT): eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6I...
Open Payment Mandate  (SD-JWT): eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6I...
 
=== 3. Merchant Creates Signed UCP Checkout ($120.00) ===
Merchant Checkout JWT Hash: MBOOU7B8tmrp1fickmNKbaLJ74iQRtvSnO2HQ01ILU0
 
=== 4. Shopping Agent Signs Closed Mandates (KB-SD-JWT Delegation Chain) ===
Agent appended closed KB-SD-JWT hop to both open mandates.
 
=== 5. Deterministic Verification & Receipt Issuance ===
[Merchant] Checkout Mandate Chain verified! Constraints satisfied (0 violations).
[Payment Processor] Payment Mandate Chain verified! Amount $120.00 <= $150.00 max.
[Shopping Agent] Checkout Receipt verified: {'verified': True}
[Shopping Agent] Payment Receipt verified:  {'verified': True}
 
=== 6. Guardrail Demo: Agent Tries to Exceed Budget ($250.00 > $150.00) ===
[Payment Processor] Rejected over-budget payment! Violations: ['Amount 25000 exceeds maximum 15000']

UCP vs. AP2: How They Work Together

Rather than competing, UCP and AP2 are complementary layers in the agentic commerce stack:

• UCP is the commerce layer: It standardizes how agents discover stores (/.well-known/ucp), negotiate capabilities, calculate shipping and discounts, and manage checkout sessions.
• AP2 is the cryptographic trust and payment authorization layer: When UCP’s dev.ucp.common.payment.ap2_mandate extension is negotiated, the session is Security Locked (preventing any downgrade to an unsigned checkout). The merchant signs the canonicalized (RFC 8785 JCS) Checkout payload and embeds a detached JWS at checkout.ap2.merchant_authorization, and on POST /checkout-sessions/{id}/complete, the agent submits cryptographically signed AP2 CheckoutMandate (ap2.checkout_mandate) and PaymentMandate (payment.instruments[*].credential.token) credentials bound to that checkout.

Wrapping up

As AI agents move from answering questions to taking real-world actions like shopping and paying, UCP provides the standardized commerce primitives while AP2 provides the cryptographic guardrails to prove user intent.

Here are some resources to learn more:

• Docs: Universal Commerce Protocol (ucp.dev)
• Docs: Agent Payments Protocol (ap2-protocol.org)
• Docs: UCP and AP2 Integration
• Blog: Under the Hood: Universal Commerce Protocol (UCP)
• Blog: Announcing Agent Payments Protocol (AP2)
• Blog: Developer’s Guide to AI Agent Protocols
• Codelab: Secure Agent Commerce with AP2 and UCP
• Sample: My UCP and AP2 Samples in genai-beyond-basics

Originally published at https://atamel.dev.

Agentic Commerce Protocols — UCP and AP2 was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Howdy friends! If you spend as much time playing with Google’s AI ecosystem as I do, you’re probably jumping between different Google tools frequently. Each tool plays a distinct role in your workflow.

For me, almost all of my serious work — whether creating applications, building sites, or writing blogs — happens inside Google Antigravity. Empowered with context, skills, and MCP servers, Agy is the agentic harness that knows my expectations, rules, and all of my GitHub repos — including my dazbo-content writing persona. It's basically my agentic ghost writer!

But I also use the Gemini Web App (gemini.google.com) and mobile app as my everyday Swiss Army knife. Whether I'm proofreading a LinkedIn post, planning flights, knocking up a video, or asking Gemini to airbrush a rogue pizza box out of a photo, the Gemini App is always ready in a browser tab.

There was just one friction point: my GitHub context was not available to the Gemini App. My writing persona, reusable skills, and project docs live inside my public and private GitHub repositories. I wanted the Gemini App to have on-demand access to all these repos across every conversation, without manually copy-pasting files like a caveman.

“Hang on, Dazbo — doesn’t the Gemini app already have a built-in GitHub connector?”

“It does indeed.”

“So you just toggled it on and went to the pub?”

“If only it were that simple.”

As I quickly discovered, the out-of-the-box GitHub connector in the Gemini web app is not quite what you think it is. Fortunately, Google has added a couple of powerhouse customisation features to the Gemini app: Custom Model Context Protocol (MCP) Connectors and persistent Skills.

In this article, I’ll disambiguate where the Gemini App fits alongside Google AI Studio and Antigravity, tour the pre-made connectors, see why the native GitHub connector falls short, and walk step-by-step through wiring up GitHub’s managed remote MCP server.

Wait — Which Tool Should I Use?

Google drops a lot of products with overlapping capabilities, and their branding can be so much fun to keep up with. Here is how I use these tools in my own workflows:

1. Google Antigravity (Antigravity Extension for Your Favourite IDE, Antigravity IDE, & Antigravity CLI)

Antigravity is Google’s agentic development harness. It’s my daily driver for anything I do that is worthy of its own Git repo. This even includes writing blogs and whitepapers.

2. Google AI Studio (aistudio.google.com)

If you haven’t looked closely at Google AI Studio lately, you might still think of it purely as a prompt playground where you tweak temperature sliders and grab a GEMINI_API_KEY. It still does that; but here's what else you can do with it:

• From the Playground, explore the latest Google models — such as Gemini Argon, Gemini Omni, Nano Banana, TTS, Lyria, Live Translate, and Gemma — and toggle grounding with Google Search or Google Maps.

• Configure models in the UI and open ready-to-execute code snippets in one click. This screenshot shows how easy it is to obtain the code for low-latency real-time audio conversation using gemini-3.8-live, or open it directly in Google Colab.

• Build new applications from a prompt.

• Explore the Gallery of pre-built agents and applications to use as-is, or remix into your own apps.

• Use the Dashboard to manage API keys, link Google Cloud projects, view model usage, or set hard monthly spend limits.

• One-Click Cloud Run Publishing, GitHub Sync & Direct Export to Antigravity: (Tip: If you open a showcase app from the Gallery, it initially opens in read-only mode — click Remix in the top-right corner first to create your own editable copy!) Once you own the app, click Publish in the top-right header to deploy it straight to Google serverless Cloud Run. And what if that prototype needs serious engineering — maybe an automated test suite? Switch to the <> Code tab and click Export in the top-right corner to Push to GitHub or click Export to Antigravity to open it directly in Google Antigravity!

So clearly, AI Studio is an amazing way to rapidly build and deploy an application from scratch. But it’s also great for creating a prototype or seeding a project before working on it in Antigravity.

3. The Gemini App (gemini.google.com) & Mobile App

This is your web-based conversational AI assistant and research workspace. It has no access to your local file system or tools.

Alongside text chats, you can have real-time voice and live camera/screen-sharing video conversations with your assistant, plus:

• Multimodal image, audio & video creation, and in-place editing.
• Integration with Google Gemini Notebook (formerly NotebookLM).
• Integration with the Deep Research Agent.
• Integration with Canvas: A side-by-side workspace for co-writing documents and slide decks (with inline tone/length sliders and one-click export to Google Docs or Slides), transforming notes into infographics, quizzes, or Audio Overviews, and live-previewing interactive HTML/React apps and 3D visualisations (or exporting Python scripts to Google Colab).

• Scheduled Actions: Built-in background automation that runs one-off or recurring prompts on a schedule — such as a daily morning tech briefing or weekly project summary.
• Persistent Skills: Install skills into the Gemini App and invoke them explicitly with @ or /, or implicitly by letting Gemini activate matching skills automatically. Because these use the open SKILL.md standard, you can share the exact same skill folders with Google Antigravity (or any other coding agent).
• Connected Apps / Connectors: Links your assistant to first-party Google services (Google Workspace, Gemini Notebook, YouTube Music), over 40 partner integrations (Canva, Adobe, Dropbox, Shopify, monday.com), and custom Model Context Protocol (MCP) servers.

In my own day-to-day workflow, it’s my favourite tool for anything that doesn’t warrant a full IDE workspace, doesn’t need local tools, or doesn’t require a local Git repo. For example:

• Chatting through ideas out loud with Gemini Live on my phone
• Kicking off some Deep Research, perhaps before persisting in a Gemini Notebook
• Proofreading a LinkedIn post
• Building a quick 3D visualisation in Canvas
• Checking on a recent Google product rebrand (yeah — I have to do this a lot)
• Creating photos and videos
• Comparing flight options

A Quick Tour of Pre-Made Connectors in the Gemini App

Head to Settings →→ Connectors to open the Connected apps hub, where Google groups customisations into Connectors and Skills.

First, take a look at some of the integrations available out of the box:

• Google Workspace: Read, write, and automate across your Google apps. Draft emails in Gmail, create Google Docs or Sheets, and schedule Calendar events.
• Canva: Connects to your Canva workspace so you can search your existing Canva folders and designs, generate new presentations or social graphics with your Brand Kit, tweak existing templates, resize assets across channels, and export directly to .pptx, .pdf, .png, or .mp4.
• Picsart: Connects to Picsart’s creative pipeline, unlocking deterministic utilities that raw generative models don’t natively handle — such as true background removal (to .png or .webp), vectorisation for scalable logos and icons, and access to many third-party creative models (like Flux, Ideogram, Recraft, Kling, Runway, and ElevenLabs) right inside your Gemini chat.
• Wispr: Connect to your Wispr Flow desktop meeting recorder. Let Gemini search your recorded meeting transcripts, scratchpad notes, and action items by participant or date — so you can ask “What did I commit to in yesterday’s architecture sync?” without ever inviting a creepy third-party recording bot into your calls.
• GitHub: “Import code from public or private repositories, and ask questions about it.” (More on this shortly!)

Why I Want GitHub Access in Every Gemini Conversation

Everything I build and write in Antigravity lives in GitHub. Not just code and applications, but my article drafts, and presentations too. I keep much of my AI configuration, harness and writing persona in a private GitHub repo.

So when I’m in the Gemini App or on my phone, I want to say things like:

• “Proofread this LinkedIn post using my dazbo-content style guide."
• “Review this Medium draft against my style guide rules.”
• “Which public repos have I updated this month?”
• “How did I structure the ADK evaluation loop in harness-engineering-demo?"

Why the Out-of-the-Box GitHub Connector Is No Good

When you see GitHub in the Installed list, you might assume enabling it gives Gemini tool access to query your GitHub repos on demand. It doesn’t!

It’s not an agentic tool integration. It is a manual static context importer attached to the + button in the chat bar (+ →→ More uploads →→ Import code). It has some limitations:

• Manual Per-Chat Uploads: You must paste a repo URL into a single chat. Start a new chat tomorrow? Import it again.
• Zero Cross-Repo Discovery: Gemini cannot list your repos or search for files across your account.
• No Live Git Intelligence: It only ingests a static file snapshot — no commits, PRs, Actions runs, or issues.
• Single-Repo Tunnel Vision: Mid-conversation, it cannot hop to another repo to check a config file or skill.

Enter the GitHub Remote MCP Server

To get on-demand agentic access across all of our repositories in every chat, we can use GitHub’s managed remote MCP server (https://api.githubcopilot.com/mcp/) configured as a Custom Connector. This server exposes GitHub's capabilities to any AI agent, such as the Gemini App.

Better still, GitHub lets us control which toolsets are exposed — and whether Gemini has read-write or strictly read-only access — simply via the URL path:

• Default Toolset — Read-Only (https://api.githubcopilot.com/mcp/readonly): (Recommended) Safe cross-repo exploration, reading private files/skills, code search, and PR/commit analysis with zero mutation risk.
• Default Toolset — Read/Write (https://api.githubcopilot.com/mcp/): Workflows where you also want Gemini to create issues, branches, or PRs directly from chat.

I use https://api.githubcopilot.com/mcp/readonly so Gemini can read anything across my public and private repos without any risk of a stray prompt pushing a commit or closing an issue.

How OAuth 2.0 Works Between Gemini and GitHub

Because both the Gemini App and the GitHub MCP server live in the cloud, we don’t want to paste our Personal Access Token (PAT) into our chat. Instead, the Gemini App authenticates with GitHub on your behalf using standard OAuth 2.0.

In a typical OAuth setup between an AI client (like Gemini) and a service provider (like GitHub), there are three pieces of configuration:

• Client ID & Client Secret: Obtained by registering an OAuth App in your GitHub Developer Settings. This gives your Gemini connector its own dedicated identity and lets you revoke access at any time with a single click.
• Authorization Callback (Redirect) URI: The exact URL inside the client application where GitHub is allowed to send you back (along with a temporary authorisation code) after you click Authorize. For security, GitHub strictly validates that the redirect URI requested during login matches the callback URL registered on your GitHub OAuth App.

To set this up, keep Gemini and GitHub open in two browser tabs: start in the Gemini App to copy the Redirect URI, paste it into GitHub to register your OAuth App, and then copy the resulting Client ID and Secret back into Gemini.

Step-by-Step: Adding the Custom GitHub MCP Connector

Let’s wire it up. We’ll create a dedicated OAuth App in GitHub specifically for our Gemini connector.

Step 1: Open the Custom MCP Modal in Gemini and Grab the Redirect URI

1. Go to Settings →→ Connectors (gemini.google.com/customize/connectors) and click + Custom.
2. Paste https://api.githubcopilot.com/mcp/readonly into MCP server URL.
3. Click Additional settings →→ Show more, then click Copy redirect URI underneath Client ID and Client secret.

This will generate a unique callback URI bound to your Google User ID:

https://oauth-redirect.googleusercontent.com/r/user_bound_custom-mcp-<YOUR_GOOGLE_USER_ID>-api_githubcopilot_com

Step 2: Register Your Dedicated OAuth App in GitHub

1. In GitHub, go to Settings →→ Developer settings →→ OAuth Apps (github.com/settings/developers) and click New OAuth App.
2. Set Application name to Gemini MCP Connector and Homepage URL to https://gemini.google.com.
3. Paste the exact https://oauth-redirect.googleusercontent.com/r/user_bound_custom-mcp-... URI into Authorization callback URL and click Register application.
4. Copy your Client ID, and click Generate a new client secret to copy your Client Secret.
5. Be sure to Save (or Update) the App in GitHub.

Step 3: Complete the OAuth Handshake in Gemini

1. Return to the Connect to an MCP server dialog in Gemini, paste your Client ID and Client Secret, and click Next.
2. Click Authorize in the GitHub OAuth popup.
3. Accept the privacy policy.

Finally, click Connect.

Once redirected back, GitHub MCP Server appears under Custom apps:

Testing It Live: Querying Repositories and Loading My Persona

In a new Gemini chat, ask a question that needs GitHub access, or tag @GitHub MCP Server from the @ menu. For example, when I ran List my public GitHub repos please, Gemini queried the live MCP server and rendered a table of all 33 of my public repositories:

Then I can ask something like: “Load my seo-audit skill from my dazbo-config repo." Gemini loads the skill from my private repo and lets me know we're ready to use it.

Easy peasy!

Wrapping Up

Antigravity, AI Studio and the Gemini App are all Google AI tools, but they serve different purposes in my daily workflows.

By wiring GitHub’s managed remote MCP server into the Gemini App’s Custom Connectors and pairing it with persistent Gemini Skills, gemini.google.com evolves from an isolated chat tab into a context-aware workspace. It is connected to my public and private repos, personal docs, and my own style guides and codified persona.

Give it a go, and let me know in the comments what custom MCP servers and skills you are wiring into your Gemini App!

Before You Go

• Please share 📢 this with anyone that you think will be interested. It might help them, and it really helps me!
• Please give me loads of claps! 👏 (Just hold down the clap button.)
• Please leave a comment 💬. Interaction is good!
• Add a star ⭐ on my repos!
• Follow 👉 and subscribe 🔔, so you don’t miss my content.

References and Useful Links

• Gemini Web App — Connected Apps
• Gemini Web App — Persistent Skills
• Google Cloud Docs: Set Up a Custom MCP Server Connector
• GitHub Docs: Using the GitHub Remote MCP Server
• Google AI Studio Quickstart
• Google AI Studio Build Mode
• Google AI Studio — Logs and Datasets
• Google Antigravity Documentation
• Dialling Our Agents to 11: My Favourite MCP Servers
• Dialling Our Agents to 11: Agent Skills You Need to be Using!
• Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent
• Meet the Antigravity Extension: Gemini Code Assist on Steroids
• Dazbo’s Portfolio

Supercharging the Gemini App with Custom MCP Connectors, Skills, and Live GitHub Access was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

How my workflow evolved from solo prompting in AI Studio to managing a multi-model AI team, running parallel subagents overnight, and enforcing strict quality gates.

As a Google Cloud GDE, I love exploring how new tools change the way we build software. If you follow my articles on Dev.to ( dev.to/patitonav), you might remember when I tested Antigravity on a high-speed train in Italy and built a Proof of Concept (POC) in a couple of hours. At the time, I described the feeling as moving “from Coder to Conductor.”

But a POC is not a real product. What happens when you use AI to build, scale, and maintain a production application over several months?

Recently, I built a multi-tenant SaaS application on Google Cloud Run and Firebase. The app itself isn’t the point. What matters is that this was my first major project where I used AI across the entire software lifecycle: from prototyping and cloud setup to security audits, testing, and overnight refactoring batches.

Across 180+ commits and 100 Pull Requests, “conducting” a single AI chat stopped scaling. I had to act like an Engineering Manager of an AI team: defining team rules ( AGENTS.md), building modular Skills, routing tasks across models ( Gemini 3.1 Pro, Flash 3.8, Argon, and Claude Opus/Sonnet), and enforcing quality gates so no agent could approve its own code.

Here is how my workflow evolved across 5 stages.

Stage 1: Solo Coder in the Playground (AI Studio to Antigravity)

To go from zero to one, Google AI Studio is great. You describe what you want, click elements on the screen to fix UI issues, and get a working web prototype in a couple of days.

But I hit a wall as soon as I needed to turn that single-user prototype into a multi-tenant SaaS with isolated customer data, strict database security rules, automated cloud scripts, and separate Sandbox and Production environments. A browser playground is built for fast UI experiments, not for managing infrastructure, test suites, or git workflows.

So I exported the code and moved to Antigravity.

Stage 2: Pair Programmer & Tech Lead (Manual Model Switching & AGENTS.md)

At first, I worked 1-on-1 with Antigravity using Gemini 3.1 Pro and Gemini Flash. Very quickly, I noticed a trade-off between cost and quality:

• Using a heavy reasoning model for everything wastes your token budget on simple tasks.
• Using a lightweight model for everything leads to messy code and missed security edge cases.

To solve this, I switched models manually inside the same chat: using Gemini 3.1 Pro for planning, Flash for coding, and 3.1 Pro for reviewing logic and tests.

I also hit another common problem: AI writes too much code. Ask for a small feature, and it adds extra helpers, unused types, and unnecessary comments. To fix this, I created an AGENTS.md file in the root of my workspace with four core rules:

• DRY (Don’t Repeat Yourself): Single source of truth for every piece of logic.
• KISS (Keep It Simple, Stupid): The simplest solution that works is the right one.
• YAGNI (You Aren’t Gonna Need It): Don’t build features you don’t need right now.
• CAZZ (Cut All Zombie Zones): Delete dead code, unused imports, and commented-out blocks.

For AI Agents You are an amplifier of the engineer's intent, not a generator of volume. Resist the urge to scaffold,
boilerplate, or "helpfully" add things that were not asked for. The best contribution is often the smallest one that
solves the real problem. Leave the codebase cleaner than you found it. Every piece of code you write is tech debt.

Stage 3: Project Manager (Cleaning Context Bloat & Modular Skills)

As the codebase grew, the agent slowed down and started forgetting our conventions. When I asked Antigravity to inspect the workspace, we found massive context bloat: over 5,400 lines of default skills for mobile and SQL tools we didn’t use, a huge old session log cached in a local folder, and outdated markdown files we were using to track tasks.

Too much unused context makes the agent slower, wastes tokens, and causes hallucinations. Here is how I cleaned it up:

1. Deleted Unused Skills: Removed the irrelevant templates and kept only the skills matching our stack.
2. Created Modular Custom Skills: In Antigravity, a skill is a markdown file with a short YAML header (name and description). Instead of loading every rule into every chat, the agent only loads a skill when it needs it.
3. Turned AGENTS.md into a 20-Line Index: Instead of a wall of text, AGENTS.md became a short router telling the agent which skill to read for each task.
4. Used /compact After Merging PRs: Long sessions fill up with terminal and test logs. Running /compact summarizes the conversation and frees up context.
5. Moved Tasks to GitHub Issues: Deleted local task files and told the agent to use the gh CLI, making GitHub Issues and Milestones our single source of truth.

Stage 4: Engineering Director (Multi-Model Strategy & Quality Gates)

As new models arrived in Antigravity, I stopped relying on a single agent and started acting like an Engineering Director, assigning each model to the role where it performs best.

1. How My Gemini Stack Evolved (3.1 Pro → Flash 3.8 → Argon)

• Step 1 (Gemini 3.1 Pro + Flash): Manual model switching inside a single chat.
• Step 2 (Flash 3.8): Flash 3.8 brought a big jump in speed and tool-calling accuracy. Instead of switching dropdowns manually, I spawned background Flash 3.8 subagents to work on focused tickets and run tests at a fraction of the token cost.
• Step 3 (Gemini 4 Argon): Google’s flagship reasoning model in Antigravity became my permanent Coordinator and Tech Lead, holding the full architecture in memory while delegating implementation to Flash 3.8 subagents.

2. How I Integrated Claude (Opus & Sonnet) with Gemini

Using only one model family creates blind spots. I combined Claude Opus and Claude Sonnet with my Gemini agents in three ways:

• 1. Blank-Page Epic Design: Use Claude Opus (Thinking) to brainstorm new epics and edge cases, then hand the plan to Argon + Flash 3.8 to build. Why it works: Opus is great at exploring complex user journeys before code exists.
• 2. Cross-Model Security Audit: Run the exact same audit prompt on Claude Opus and Gemini Argon, then ask Argon to compare and merge both reports. Why it works: Opus catches structural code smells; Argon catches cloud and database security details.
• 3. Sonnet + Flash “Skeptical Validators”: Run a repo review with Claude Sonnet, then have Argon spawn parallel Flash 3.8 subagents to verify each claim against git log and compiler output before creating GitHub Issues. Why it works: Filters out over-engineered ideas (YAGNI) and duplicate tickets before they clutter the backlog.

3. Subagent Skill Inheritance & Quick Side Queries (/btw)

Once I saw that subagents automatically inherit all workspace skills, orchestration became simple. My Argon Coordinator didn’t need long prompts; it just spawned a Flash 3.8 worker and told it which skills to follow. And when I had a quick architecture question while subagents ran in the background, the /btw command gave me a fast answer without interrupting the active agent.

4. Never Let an Agent Grade Its Own Homework (pr-quality-gate)

When an agent reviews its own code, it rarely catches its own mistakes. So I created a mandatory pr-quality-gate skill. Before any Pull Request is ready to merge, the Coordinator agent runs four steps:

1. Web Standards Check: Runs a frontend audit skill (modern-web-guidance) to check accessibility, button semantics, and mobile layout.
2. 3 Parallel Evaluator Subagents: Spawns three read-only subagents (Frontend/State, UI/Accessibility, and Backend/Security) to audit the diff against DRY, KISS, YAGNI, and CAZZ.
3. Parallel Refactoring Subagents: Spawns worker subagents to fix the findings, with a strict rule that no two agents edit the same file at the same time.
4. Independent Final Reviewer & Sandbox Test: A fresh reviewer subagent inspects the final diff, runs all tests, posts an approval comment on the PR, and deploys to Sandbox.

Stage 5: Operations Manager (Shipping 16 Stacked PRs Overnight)

After our security and architecture audit, we had 16 tech-debt and security tickets in the backlog. Solving them one by one in chat would have taken days.

Instead, I built a parallel-pr-orchestrator skill so Argon could run an overnight batch using four rules:

1. Zero Merge Conflicts (Parallel Tracks + Stacked PRs): I split the 16 issues into 4 parallel tracks touching completely different files, each running in an isolated git worktree (Workspace: 'share'). Within a track, dependent tickets branched on top of each other as stacked PRs (main ← PR 1 ← PR 2 ← PR 3).
2. Low Token Usage (Model: 'flash'): Argon coordinated the waves, while all Worker, Evaluator, Refactoring, and Reviewer subagents ran on Flash 3.8.
3. Hardware & Emulator Limits: To avoid freezing my laptop or causing port conflicts with the local database emulator, I set a limit of 4 parallel workers and allowed only one subagent at a time to run emulator tests.
4. Safety Guardrails: Subagents were not allowed to merge PRs or run deployment scripts overnight.

At 9:07 PM, I triggered the orchestrator using the /goal command (which keeps Antigravity working until the entire goal is finished) and left it running overnight. When I checked at 7:43 AM, all 16 Pull Requests were open on GitHub with passing tests, independent APPROVED reviews, and zero merge conflicts.

Real-World Gotchas (And How /learn Fixed Them)

Even with good skills, agents still make mistakes. My favorite habit in Antigravity is running right after correcting the AI. Instead of fixing an issue only in the current chat, /learn writes a permanent rule into AGENTS.md or your skills so no future agent repeats it:

• Broken Local Links in Markdown: Subagents initially pasted IDE links (file:///...) into README.md and docs/, which break on GitHub. One /learn rule enforced using relative paths across all documentation.
• Trying to Merge Too Early: An agent tested a new auth provider in Sandbox and wanted to merge to main before it existed in Production. We added a rule never to merge while manual cloud setup is pending, and to automate provider setup in deployment scripts first.
• Missing Post-Merge Cleanup: Subagents used to stop right when a PR was merged. Now they automatically post a delivery summary on the closed issue, update related tickets, close finished milestones, and delete merged branches.

The Verdict

Managing a full project lifecycle with AI is very different from building a weekend POC.

• For experienced engineers, Antigravity lets you work like an Engineering Manager with a 24/7 team. You focus on architecture, security boundaries, and product decisions, while your agents handle implementation, testing, and refactoring.
• For junior developers, go step by step. AI can generate thousands of lines of working code overnight, but “working” is not the same as “maintainable.” Read the diffs, question every architectural choice, and never skip tests.

To scale your own AI workflow from prototype to production:

1. Start in AI Studio, then move to Antigravity when you need real architecture, security rules, and automated cloud scripts.
2. Keep AGENTS.md short, move detailed workflows into modular skills, and use /compact in long sessions.
3. Use the right model for the job: Use Argon to coordinate, Claude Opus/Sonnet for planning and cross-model audits, and Flash 3.8 for parallel workers and skeptical validators.
4. Never let an agent approve its own PR: Run a multi-agent quality gate and test in Sandbox before merging.
5. Use /learn after every mistake so your agents improve every day.

How are you managing your AI workflows when projects grow beyond a simple POC?
Have you tried combining different models or running parallel subagents? Let me know in the comments!

Originally published at https://dev.to on November 3, 2026.

What I Learned Managing a Full Project with Antigravity was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a AlloyDB Omni HA deployment, backups must handle active node failovers, continuous Write-Ahead Log (WAL) archiving, point-in-time recovery (PITR), and minimal read/write performance degradation on the primary database. In this post, we will explore a Backup Reference Architecture for a AlloyDB Omni HA deployment using pgBackRest, focusing on advanced use cases like offloading backups to a standby and avoiding duplicate data copies.

Backup Reference Architecture

In a typical AlloyDB Omni HA deployment, you have one Primary node and two Standby nodes spread across different availability zones. To integrate pgBackRest effectively, you should use a Centralized Shared Repository (such as Google Cloud Storage, S3 bucket, or an NFS share). Instead of treating each Database node as a separate entity to back up, pgBackRest treats the entire HA cluster as a single “stanza” (a configuration unit for a specific database cluster).

Key Principles of this architecture, are:

• Single Source of Truth — All database nodes point to the exact same pgBackRest repository.
• Cluster Aware — The pgbackrest.conf file on every node is identical and knows about all the nodes in the cluster.
• Location Independence — When a failover occurs, pgBackRest seamlessly automates WAL archival on the primary node.

Architecture A: Backup Repository Host (Disk / SAN / NAS)

In this architecture, you need to provision a separate, dedicated compute instance (the “Repo Server”) that hosts the pgBackRest repository. This server mounts a large, durable block storage volume or network-attached storage (NAS/NFS). The database nodes use the archive_command to push Write-Ahead Logs (WALs) via SSH to the Repo Server. When a backup is scheduled, the cron job runs on the Repo Server. The Repo Server connects back to the database nodes via SSH, initiates the backup, and pulls the data files across the network onto its attached storage.

Pros:

• Strict Security Isolation: The database nodes only have permission to push WALs. If a database node is compromised, the attacker cannot delete historical backups residing on the Repo Server.
• Performance Tuning: You have full OS-level control to tune TCP buffers and disk I/O on the backup server.
• Centralized Management: All backup logs, retention policies, and cron jobs are managed on a single machine outside the database cluster.

Cons

• Infrastructure Overhead: You must maintain, patch, and monitor an additional OS and its attached storage.
• Storage Limits: Scaling attached block storage is generally harder and more expensive than cloud object storage.

Architecture B: Using Object Storage (Google Cloud Storage / S3)

In this serverless backup architecture, there is no intermediate repo compute node (as most organizations have object storage configured for backup purposes). Here, pgBackRest runs directly on the database nodes, taking advantage of its native support for S3-compatible object storage. The primary node pushes WAL files directly to the S3 bucket using HTTPS. A cron job runs on one of the database nodes (typically standby nodes) which reads the data files and pushes them directly to the object storage API.

Pros:

• Scalability & Durability: Cloud object storage automatically scales capacity and provides 11-nines of durability.
• Lower Operational Overhead: No separate backup server OS to manage, patch, or monitor.
• Cost-Effective: S3 storage is generally cheaper than provisioned high-performance block storage.

Cons:

• Security Complexity: The database nodes must hold IAM credentials (or instance roles) capable of writing to and potentially deleting from the S3 bucket. (Though you can mitigate this with S3 Object Lock/Immutable backups).
• Compute Impact: The database node running the backup uses its own CPU/RAM to compress and encrypt the data before pushing it to S3.

Conclusion

In either of the architectures, configuring pgBackRest with a single shared stanza, enabling standby backups, and utilizing its native duplicate-prevention mechanisms will ensure that your disaster recovery pipeline is just as robust and automated as your HA failover mechanisms. The choice of the reference architecture ultimately depends on your infrastructure environment — whether you prefer the tight network and security control of a dedicated backup server, or the infinite scalability and low maintenance of cloud object storage.

In modern architectures, object storage is usually an integral part of backup infrastructure in many organizations, with cloud object storage on GCS or an on-prem S3-compatible object storage. Hence, the Architecture with Object Storage is recommended, considering the simplicity, scalability, reliability, operational overhead and cost.

Best Practices & Optimizations

Regardless of which architecture pattern, you must configure pgBackRest to handle the dynamic nature of an HA cluster gracefully. Here are a few use cases and guidelines for you to consider to optimize resources and get most out of your architecture.

Offload Backups to a Standby (Zero-Impact Backups)

Running a full backup on a busy primary database consumes CPU for compression and disk I/O to read the data files, which can degrade application performance. pgBackRest allows you to offload the heavy lifting to a Standby node. By using the backup-standby parameter, pgBackRest connects to the Primary only to execute the fast pg_start_backup() and pg_stop_backup() functions. The actual bulk data read (and compression) happens entirely on the Standby node.

pgBackRest Configuration Snippet Example:

[global]
# This defines the shared cluster topology
repo1-path=/pgbackrest/repo
pg1-host=x.x.x.x1 # Primary
pg1-path=/var/lib/postgresql…
pg2-host=x.x.x.x2 # Standby 1
pg2-path=/var/lib/postgresql…
pg3-host=x.x.x.x3 # Standby 2
pg3-path=/var/lib/postgresql…
# Enable standby backups
backup-standby=y

Avoid Duplicate Copies and WAL Conflicts

In an HA cluster, failovers happen. When Standby 1 is promoted to Primary, it immediately starts generating WALs. If both the old primary and the new primary try to push backups to the repository, it can cause duplicates or corruption. For this, pgBackRest uses a shared stanza configuration, it prevents duplication natively:

• Deduplicated WAL Archiving: All nodes in your cluster should have archive_mode = on and their archive_command configured to push to pgBackRest. If a split-brain occurs and two nodes try to push the same WAL segment, pgBackRest computes a checksum. If the files are identical, it gracefully acknowledges the push without storing a duplicate. If they differ, it raises a safe error.
• Delta Restores: When rebuilding a failed node, pgBackRest compares the checksums of the files currently on the broken node’s disk with the files in the backup repo. It transfers only the missing or modified files, drastically reducing network traffic and eliminating redundant data transfers.
• No Siloed Backups: There is no “Node 1 Backup” and “Node 2 Backup.” By defining all nodes in one stanza, there is only a single, unbroken backup chain for the entire cluster.

Automated Failover Awareness

When using automated HA orchestration, roles change without human intervention. Because pgBackRest’s configuration lists all potential nodes (alloydb1, alloydb2, alloydb3), it probes them via SSH or local connection at the start of any backup operation to discover the current topology.

If alloydb1 fails and alloydb2 becomes the primary, the next scheduled backup automatically detects alloydb2 as the primary. If backup-standby=y is set, it will automatically select alloydb3 to fetch the data files from. You never have to manually update your backup cron jobs after a database failover.

Asynchronous Archiving

On high-throughput databases, synchronous WAL archiving can cause performance bottlenecks. Enable archive-async=y in your pgBackRest configuration. This allows pgBackRest to spool WAL files locally and push them to the repository in parallel using multiple workers (process-max=4), ensuring the primary never stalls waiting for a WAL push to complete.

Enable Checksums

Always ensure data_checksums are enabled when initializing your AlloyDB Omni cluster. pgBackRest utilizes these checksums to guarantee the absolute integrity of your backups.

Regular Restore Testing

An untested backup is merely a theoretical backup. Automate a script that provisions a temporary VM, fetches the latest backup from the pgBackRest repo, and performs a test PITR recovery at least once a week.

Get Started with AlloyDB Omni

By choosing AlloyDB Omni, you gain the benefits of superior database performance — including up to 2x faster OLTP performance and features like vector search for generative AI applications — combined with simplified, automated operations, all within your familiar VM environment.

Ready to elevate your on-premises database operations? Dive into our AlloyDB Omni documentation to get started. You can also try codelabs to deploy a highly available AlloyDB Omni cluster.

Architecting Resilience with AlloyDB Omni Backup Strategies was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.