Google Cloud Pushes ADK Architecture to Scale Enterprise AI Agents

Scaling Agents through Agent Engineering [HANDS ON; LAPTOP REQUIRED] With Google Cloud — Ai4

Ai4

Local AI agent prototypes stall in production because monolithic prompts degrade reasoning, requiring developers to decouple execution into graph workflows and centralized cloud skill registries.

AI-assisted summary of Scaling Agents through Agent Engineering [HANDS ON; LAPTOP REQUIRED] With Google Cloud — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by Ai4 on August 15, 2026, this hands-on workshop is led by Google Cloud Product Manager Alan Blount and Developer Advocate Christina Zhu. According to the session description, the presentation explores 'agent engineering' by showing how to separate core agent logic in the Agent Development Kit (ADK) from session-tenant cloud infrastructure to scale stateful AI agents across an enterprise.

## TL;DR The workshop guides participants through building, debugging, and scaling 'Nimbus,' an SRE triage co-pilot designed to inspect microservice health and calculate error rates. The instructors explain why single monolithic prompts fail in production and showcase how ADK v2 uses directed graph orchestration, deterministic local functions, and a visual debugger to achieve reliable reasoning. Addressing the transition from local prototypes to production, the team outlines how to prevent prompt bloating and skill siloing by decoupling agent capabilities into a centralized, semantically searchable Google Cloud Skill Registry.

## Atmosphere & style The workshop has a brisk, hands-on, and candid tone, cutting introductory chatter to get participants straight into Cloud Shell terminals. The hosts cultivate an interactive, pair-programming atmosphere, taking real-time glitches—such as unexpectedly running out of pre-allocated GCP credits—in stride with humor and quick improvisational fixes. It feels pragmatic and technical rather than promotional, focusing directly on developer ergonomics, visual execution traces, and practical architectural trade-offs.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=4s) Enterprise AI agent projects frequently stall at the prototype stage because local implementations rely on in-memory state, un-sandboxed code execution, and lack systematic evaluation or governance required for production. - [00:04](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=4s) The workshop hands-on exercises center on building and hardening Nimbus, an SRE CloudOps co-pilot designed to triage infrastructure health for a fictional enterprise. - [06:03](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=363s) Google Cloud Shell is recommended for agent development over local machines because it eliminates cross-platform OS friction and runs directly on the cloud backbone adjacent to downstream APIs. - [06:03](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=363s) Configuring LLM inference against global endpoints rather than regional endpoints ensures higher availability and resilient rate limits during workshop development. - [15:45](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=945s) Standard monolithic LLM prompting fails in production SRE scenarios because single prompts cannot compute exact arithmetic, parse real-time telemetry, or access operational runbooks deterministically. - [15:45](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=945s) The Agent Development Kit (ADK v2) replaces monolithic prompts with explicit directed graphs connecting LLM sub-agents, deterministic code functions, tools/MCP servers, and human-in-the-loop pauses. - [15:45](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=945s) ADK supports zero-model code execution, allowing non-generative tasks like mathematical calculations to run as deterministic local functions, reducing latency, API costs, and hallucinations. - [19:09](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1149s) The ADK Web visual debugger exposes intermediate graph transitions, tool payloads, agent state updates, and sub-agent handoffs in real time instead of treating the LLM as an opaque black box. - [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) Local agent architectures suffer from prompt bloating, where appending too many instructions and tools to a single prompt degrades reasoning performance and increases hallucination rates. - [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) Skill isolation on local developer environments prevents multi-agent collaboration and Agent-to-Agent (A2A) orchestration across distributed enterprise teams. - [28:55](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1735s) Google Cloud Agent Platform provides a managed Skill Registry that enables version-controlled, semantic discovery and execution of modular tools on demand without bloating the base agent prompt. - [28:55](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1735s) Cloud-based skill discovery relies on strict formatting and detailed semantic descriptions to match runtime user intent against registered enterprise skills dynamically.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=4s) Workshop Introduction and the Production Gap

The session kicks off with brief introductions from the Google Cloud team. Alan sets the pace immediately, noting that because of the dense material ahead, they will minimize introductory chatter and dive straight into the hands-on work. Dr. Emanuel introduces himself as an educator passionate about sharing cutting-edge technology, and Christina Zhu introduces herself as a Developer Advocate at Google Cloud.

The goal of the workshop is to provide participants with the practical confidence required to build, evaluate, and deploy production-ready AI agents on Google Cloud. After surveying the room to verify that attendees brought their laptops—and encouraging those without one to pair up—Christina outlines the primary challenge in modern agent engineering. While building a functional agent prototype locally with the Agent Development Kit (ADK) can be done in a single afternoon, the vast majority of enterprise agent projects stall right at that threshold. Local prototypes rely on in-memory state, local tool scripts, and un-sandboxed code execution, none of which survive the transition to production where durability, scaling, isolated execution, enterprise governance, and systematic evaluation loops are required.

```mermaid flowchart TD accTitle: The Production Gap in Agent Engineering subgraph LocalPrototype["Local Prototype (Fragile)"] A["In-Memory State"] B["Local Tool Calling"] C["Unconstrained Execution"] end subgraph ProductionRequirements["Enterprise Production (ADK + Google Cloud)"] D["Durable Session State"] E["Sandboxed Code Isolation"] F["Governance & Policy Layers"] G["Evaluation & Feedback Loops"] end LocalPrototype -.->|"The Production Gap\n(Where projects stall)"| ProductionRequirements ```

- **Target project**: Throughout the hands-on labs, attendees build and iteratively harden **Nimbus**, a CloudOps co-pilot for the fictional enterprise Cymbal. - **The enterprise dilemma**: Shipping an agent is insufficient if teams cannot answer whether the system is reliable, how to systematically measure and improve it, or how other employees across the organization can safely interface with it.

---

[03:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=196s) Environment Setup and the GCP Credit Crunch

Christina directs attendees to a QR code and URL on screen granting temporary Google Cloud Platform (GCP) credits to fund the lab exercises for the day. Attendees are instructed to complete a captcha, link the promotional code, and verify that a dedicated billing account appears in their GCP console. For attendees without immediate billing access, Christina highlights that they can fall back to using a Gemini API key via Google AI Studio for Lab 1, though full GCP access is required for subsequent deployment labs.

During the setup window, the workshop runs directly into real-world capacity constraints: the pool of pre-allocated credit redemptions runs out almost immediately due to high attendee turnout. Christina and Alan acknowledge the hiccup—"we are now out of free credits, which sucks"—explaining that demand exceeded the pre-provisioned allocation. Christina quickly promises to request an expanded batch of credits and reactivate the link after the session so everyone can complete the exercises independently, advising uncredited attendees to pair up with neighboring participants who successfully claimed a coupon.

---

[06:03](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=363s) Launching Google Cloud Shell and Authentication

Alan introduces the lab repository and provides recommendations on the local vs. cloud development environment. While participants fluent in terminal workflows are welcome to run everything locally on their own machines, the team strongly advises using Google Cloud Shell directly from the GitHub repository's README.

```mermaid flowchart LR accTitle: Cloud Shell Setup Flow subgraph RepoSetup["1. Workspace Setup"] A["GitHub Repo"] -->|"Click 'Open in Cloud Shell'"| B["Google Cloud Shell"] B --> C["Trust Repository & Confirm"] end subgraph CloudAuth["2. Cloud Provisioning"] C --> D["Set PROJECT_ID variable"] D --> E["gcloud auth & config"] E --> F["Global LLM Endpoint Ready"] end ```

Alan emphasizes two practical advantages of Cloud Shell for live workshops: 1. **OS Agnostic**: It removes cross-platform friction between Windows command-line idiosyncrasies and macOS/Linux shells. 2. **Network Proximity**: Event venue Wi-Fi is notoriously unreliable; running inside Cloud Shell keeps the environment execution directly on the Google Cloud backbone adjacent to downstream APIs and managed services.

Attendees click the "Open in Google Cloud Shell" badge, accept the repository trust prompt, and wait for the Cloud Shell container to provision. Once inside the shell, Alan walks the room through setting their active GCP `PROJECT_ID` environment variable and executing the prerequisite script. He points out that inference is deliberately configured to point to a global Large Language Model (LLM) endpoint rather than a constrained regional endpoint to ensure high availability and rate limits during the workshop.

---

[12:46](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=766s) Introducing Lab 1 and the Nimbus CloudOps Co-Pilot

Alan navigates the room into `labs/01` and runs the pre-flight test harness. He highlights that the repository is designed like a "cooking show": core Model Context Protocol (MCP) server configurations, custom skills, and unit test suites are pre-wired to enable quick experimentation without getting bogged down in boilerplate setup.

```bash cd labs/01 ./test.sh ```

After validating that the local environment passes its prerequisite checks, Alan executes the Nimbus agent via the command line runner. The running operational scenario asks the agent to evaluate the health of an infrastructure microservice.

- **Primary Persona**: Nimbus serves as an Site Reliability Engineering (SRE) triage co-pilot. - **Sample Query**: *"Is checkout healthy? What is its error rate?"* - **Execution Output**: The agent inspects metrics, identifies a degraded status, computes an error rate of 4.7%, and reports elevated latencies along with anomalous upstream dependencies.

Alan then hands the microphone back to Christina to explain the underlying mechanics of ADK and why traditional single-prompt model invocations fall apart for this class of enterprise problems.

---

[15:45](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=945s) ADK Architecture: Graph-Based Orchestration vs. Monolithic Prompts

Christina explains why standard LLM prompting fails when responding to mission-critical infrastructure triage. If an on-call engineer prompts a single LLM call with *"Is checkout healthy? Triage it"*, the model cannot reliably answer: it lacks real-time service metrics, access to live incident runbooks, memory of previous conversational interactions, and the ability to compute exact mathematical error rates. Unconstrained models will inevitably guess or hallucinate.

A production-ready system requires a four-phase operational loop: **gather facts**, **follow procedure**, **compute exact numbers**, and **report structured findings**.

```mermaid flowchart TD accTitle: ADK v2 Graph-Based Agent Architecture subgraph ADKGraph["ADK v2 Graph Engine"] Root["Root Coordinator Node"] --> ToolNode["Tool / MCP Node\n(Live Metrics)"] Root --> FuncNode["Deterministic Function Node\n(Math / Code Sandbox)"] Root --> SubAgent["LLM Sub-Agent Node\n(Runbook Evaluation)"] Root --> HumanNode["Human-in-the-Loop Node\n(Approval / Pause)"] end ToolNode --> Res["State Aggregator"] FuncNode --> Res SubAgent --> Res HumanNode --> Res Res --> Out["Final Grounded SRE Report"] ```

To coordinate this reliably without manual plumbing, Google provides the **Agent Development Kit (ADK)**: - **Framework & Model Agnostic**: Optimized for Gemini and Google Cloud primitives, but fully capable of invoking third-party models and deploying across external runtimes. - **Graph-Based Workflows (ADK v2)**: Replaces monolithic prompts with an explicit directed graph of nodes connected by edges. Nodes can represent AI sub-agents, deterministic Python functions, external tool/MCP calls, human-in-the-loop input pauses, or encapsulated sub-workflows. - **Zero-Model Code Execution**: Steps that do not require generative intelligence (such as mathematical computations or data transformations) execute via deterministic local functions, saving latency, API costs, and eliminating stochastic failure modes.

---

[19:09](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1149s) Hands-On Lab 1: Testing, Querying, and the ADK Visual Debugger

Participants navigate into the `01_adk` lab directory inside their Cloud Shell terminals. The codebase defines a root coordinator agent, resolvers for toolsets and execution sandboxes, and a local runner managing sessions, memory, and artifact persistence.

```bash cd labs/01_adk ./test.sh ./run.sh "is checkout healthy? what is its error rate?" ```

Running `test.sh` confirms that the local runner, mocked toolsets, and credential layers are operational. When queried via `run.sh`, Nimbus executes its graph: pulling simulated metrics, running the arithmetic resolver to calculate the exact 4.7% error rate, identifying degraded operational health, and surfacing specific error traces.

Christina then demonstrates the ADK local web server by running the dev playground command:

```bash adk web ```

Opening the web preview URL launches the ADK Visual Debugger interface. In this interactive environment, users can open a fresh session, submit queries, and observe the live execution trace. Rather than treating the LLM as an opaque black box, the debugger exposes the intermediate graph transitions, state updates, tool invocation payloads, and sub-agent handoffs in real time.

[22:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1327s) Debugging and Triaging with ADK Web

The session transitions into real-time debugging using ADK Web, where developers can inspect event logs and trace the execution graph constructed during the first lab. Looking at the event sidebar reveals the individual nodes and graph paths triggered as the agent reasons through a problem. Attendees are encouraged to directly prompt their agent, trigger alternative decision branches, observe state transitions, and inspect generated artifacts. While deeper evaluation frameworks are touched upon lightly due to time constraints, the interface provides a window into the agent's internal orchestration and operational state.

The central takeaway of Lab 1 is that relying on a single monolithic prompt fails when diagnosing complex operational queries like determining whether a checkout system is healthy. A standard prompt lacks real-time metrics, access to operational runbooks, and mathematical computation capabilities. The Agent Development Kit (ADK) bridges this gap through graph-based workflows that orchestrate specialized nodes to triage and resolve system issues reliably. Because the resulting agent is modular, engineers can adjust reasoning steps, swap underlying capabilities, or integrate custom tools for production without needing to rewrite the application from scratch.

- **ADK Web Capabilities**: Live event stream tracing, node execution monitoring, agent state inspection, and artifact generation tracking. - **Single-Prompt Limitations**: Inability to compute math, parse runbooks dynamically, or ingest live operational metrics without structured graph orchestration. - **Extensibility**: Users can introduce new reasoning nodes directly into the ADK graph, which instantly reflect in the ADK Web UI.

---

[24:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1456s) The Scaling Challenge: Moving Beyond Local Development

While building and testing locally on a laptop enables rapid prototyping and immediate feedback, it represents only the first half of agent engineering. The system built in Lab 1 is fully functional locally, but it does not yet scale. The subsequent architectural challenge lies in scaling orchestration: moving from a single developer environment to serving the "Nimbus" agent to thousands of concurrent enterprise users as managed services without re-architecting the core code.

To address this, the workshop shifts focus to Lab 2, designed to decouple agent skills from the local runtime. By registering skills to a centralized cloud server, organizations can govern, version, and share capabilities across distributed development teams. As Emanuel takes over the presentation, he resets the room to transition from local node graphs to centralized cloud infrastructure.

```mermaid flowchart LR accTitle: Transitioning from Local Agent Prototyping to Cloud-Scale Deployment subgraph Local["Phase 1: Local Development (Lab 1)"] A["Laptop Runtime"] --> B["ADK Graph Logic"] B --> C["Rapid Local Iteration"] end subgraph Cloud["Phase 2: Cloud Scaling (Lab 2)"] D["Skill Registry"] --> E["Managed Cloud Services"] E --> F["Multi-User Scaling (Nimbus)"] end Local -.->|"Publish & Decouple"| Cloud ```

---

[25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) The Bottlenecks of Local Agents: Prompt Bloating and Skill Silos

After polling the room on Lab 1 progress, Emanuel prompts the audience to identify what is fundamentally required to scale an AI agent once built. The audience responds with practical realities: *"Money,"* *"Customers,"* and *"Infrastructure."* Validating these points, Emanuel underscores the core engineering hurdle: locally hosted agents bundle instructions, context, and tool definitions directly on the developer's machine, which introduces two critical architectural failure modes.

The first issue is "prompt bloating." When developers attempt to expand an agent's capabilities by appending instructions, rules, and examples to a single monolithic system prompt, the model's reasoning degrades. Overburdened context windows increase the likelihood of hallucinations and make the agent functionally *"dumber."* The second issue is skill isolation: when capabilities reside locally, they remain inaccessible to external systems or peer agents, preventing collaborative Agent-to-Agent (A2A) orchestration. Scaling requires decomposing these capabilities into modular skills stored in a centralized cloud registry where agents can search, retrieve, and execute them on demand.

- **Prompt Bloating**: Appending too many instructions into a single system prompt degrades attention and increases hallucinations. - **Skill Siloing**: Hardcoded local tool definitions prevent cross-team governance and multi-agent reuse. - **Dynamic Retrieval**: Agents must query a remote registry to pull down and execute only the specific skill required for a given subtask.

---

[28:55](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1735s) Cloud-Based Skill Registries: The Three-Step Scaling Workflow

Instead of requiring teams to build custom discovery backends, Google Cloud provides a built-in Skill Registry within Agent Platform. This managed registry includes package management, built-in version control, and semantic search capabilities, allowing agents to dynamically query and load relevant skills at runtime without inflating their base prompts.

```mermaid flowchart TD accTitle: Three-Step Cloud Skill Registry Architecture subgraph Step1["1. Define Skill"] S1["Name: < 64 chars lowercase\nDescription: Semantic search query"] end subgraph Step2["2. Push to Registry"] S2["Google Cloud Agent Platform\nSkill Registry (Versioned)"] end subgraph Step3["3. Dynamic Discovery & Invocation"] S3["Agent performs Semantic Search"] --> S4["Agent pulls & executes Skill"] end

Step1 --> Step2 Step2 --> Step3 ```

Implementing this architecture follows a three-step workflow: 1. **Define the Skill**: Create a structured definition with strict formatting (lowercase names under 64 characters) and an expressive, descriptive summary. The description is critical because the registry uses it to perform semantic vector searches when matching user intent to tools. 2. **Push to Google Cloud Registry**: Register the skill code into the Google Cloud project's Agent Platform via a lightweight API or SDK call. 3. **Invoke via Agent**: The runtime agent dynamically searches the registry, fetches the required skill definition, and executes it.

Closing out the session as time runs short, the speakers point attendees to the workshop GitHub repository for hands-on self-paced modules, confirming that Google Cloud project credits will remain active for the rest of the day so participants can complete the advanced scaling labs.

## Notable quotes > [03:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=196s) we are now out of free credits, which sucks — Christina Zhu

> [12:46](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=766s) cooking show — Alan Blount

> [12:46](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=766s) Is checkout healthy? What is its error rate? — Alan Blount

> [15:45](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=945s) Is checkout healthy? Triage it — Christina Zhu

> [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) Money — Audience

> [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) Customers — Audience

> [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) Infrastructure — Audience

> [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) prompt bloating — Dr. Emanuel

> [25:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1516s) dumber — Dr. Emanuel

## Mentioned Ai4, Alan Blount, Christina Zhu, Dr. Emanuel, Google Cloud, Gemini Enterprise, Google AI Studio, Google Cloud Shell, Agent Development Kit (ADK), Agent Substrate, Agent Platform, Skill Registry, AX, Agent-to-Agent (A2A), Nimbus, Cymbal, Model Context Protocol (MCP), GitHub, Python

## Video description Alan Blount - Product Manager, Google Cloud Christina Zhu - Developer Advocate, Google Cloud

Important Note: This hands-on, interactive workshop is led by Google Cloud and is open to all Ai4 attendees at no additional cost. No RSVP or separate registration is required. To participate and get the most out of this session, please bring your own device (a laptop is recommended). Devices will not be provided on-site.

ABOUT THIS WORKSHOP: Building a single AI agent locally is straightforward; scaling it reliably across an enterprise is where traditional request-based architecture breaks down. This session explores 'agent engineering' and the shift toward session-tenant compute. We will demonstrate how to separate your agent's core logic using the Agent Development Kit (ADK) from the complex infrastructure of durable execution. By pairing Agent Substrate for secure, sandboxed isolation with AX for a resumable runtime harness, you can efficiently scale stateful, long-running sessions. Finally, we will showcase how Gemini Enterprise serves as the unified interface to orchestrate these capabilities, seamlessly connecting users to specialized agents via Agent-to-Agent (A2A) protocols.

[Source](https://www.youtube.com/watch?v=bmpGoCDvcOA)

中文简报

Google Cloud 推进 ADK 架构以规模化扩展企业级 AI Agent 本地 AI Agent 原型在生产环境中屡屡停滞,原因在于单体 Prompt 会削弱推理能力,这要求开发者将执行流程解耦为图工作流与集中式云端技能注册表。 本次研讨会指导参与者构建、调试并扩展“Nimbus”——一款旨在检查微服务健康状况并计算错误率的 SRE 分诊 Copilot。讲师们阐释了为何单一单体 Prompt 会在生产环境中失效,并展示了 ADK v2 如何利用有向图编排、确定性本地函数以及可视化调试器来实现可靠推理。针对从本地原型向生产环境的过渡,团队概述了如何通过将 Agent 能力解耦至支持语义搜索的集中式 Google Cloud 技能注册表,以防止 Prompt 膨胀和技能孤岛问题。 多数企业级 AI Agent 项目往往停滞在原型阶段,原因在于本地实现过度依赖内存状态、缺少沙箱执行隔离,且缺乏生产所需的系统化评估与治理。 (0:04) 本次工作坊围绕构建 SRE 运维助手 Nimbus 展开,推荐通过 Google Cloud Shell 及全局 LLM 端点进行开发,以规避跨平台环境冲突并保障调用配额与可用性。 (6:03) ADK v2 采用有向图架构取代单体提示词,通过连接子 Agent 与确定性本地函数实现零模型代码执行,并借助 ADK Web 可视化调试器实时监控状态转换和工具载荷。 (15:45) 针对本地 Agent 容易引发的提示词膨胀和技能孤岛瓶颈,Google Cloud 提供了云端技能注册表(Skill Registry),支持通过语义搜索在运行时动态检索并按需加载执行技能。 (25:16)

Reading summary

According to Google Cloud presenters Christina Zhu, Alan, and Dr. Emanuel, enterprise AI agent initiatives frequently stall because local prototypes rely on fragile in-memory states and monolithic prompts that cannot scale. To build production-ready systems, engineering teams must transition to graph-based orchestrations that separate deterministic logic from generative models and decouple tools into centralized, cloud-hosted skill registries. The Enterprise Production Gap in Agent Engineering (0:04) Google Cloud's team outlines a fundamental divide in agent engineering: while functional prototypes can be built quickly with the Agent Development Kit (ADK), they rely on in-memory state, local tool scripts, and un-sandboxed execution. These local implementations fail to survive the transition to enterprise production, which demands durable session management, isolated execution environments, policy governance, and systematic evaluation loops. To address this gap, the workshop centers on building Nimbus, an Site Reliability Engineering (SRE) co-pilot for the fictional enterprise Cymbal. The presenters emphasize that real-world deployment requires answering how to systematically measure reliability and enable safe multi-user access across an organization. Initial onboarding also faced practical cloud constraints, such as temporary credit pool exhaustion from high attendee demand, prompting the team to use Google Cloud Shell to bypass venue network instability and cross-platform operating system discrepancies. Graph-Based Workflows Versus Monolithic Prompts (15:45) Christina Zhu argues that traditional monolithic prompting fails for operational tasks like infrastructure triage. A single model prompt cannot reliably query live telemetry, parse operational runbooks, preserve interaction history, and execute arithmetic computations simultaneously. Unconstrained models facing these tasks inevitably hallucinate or guess instead of adhering to the required operational sequence: gathering facts, following runbooks, computing exact numbers, and reporting structured findings. To resolve this, ADK v2 replaces monolithic prompts with directed graph workflows consisting of coordinated nodes. These nodes include LLM sub-agents, external Model Context Protocol (MCP) tools, human-in-the-loop pauses, and deterministic local code functions. By running arithmetic calculations and data transformations through zero-model code execution rather than LLMs, systems reduce API costs, cut latency, and eliminate stochastic errors. In the Nimbus lab, this graph enables the agent to pull metrics, compute an exact 4.7% error rate, and identify degraded dependencies, with execution traces visible via the ADK Web debugger. Bottlenecks of Prompt Bloating and Skill Siloing (25:16) Dr. Emanuel identifies two primary architectural bottlenecks that emerge when developers attempt to expand locally hosted agents: prompt bloating and skill siloing. Prompt bloating occurs when engineers continuously append instructions, behavioral rules, and contextual examples to a single system prompt. Overburdening the context window degrades model attention and reasoning, increasing hallucination rates and reducing overall agent performance. At the same time, hardcoding tool definitions on a single developer's machine creates isolated skill silos. Because local tools are coupled to an individual runtime, peer agents and external systems cannot discover or reuse them, preventing collaborative Agent-to-Agent (A2A) orchestration. Scaling requires decomposing monolithic agents into modular, remotely accessible skills that agents search and retrieve dynamically at runtime. Decoupled Scaling with Cloud Skill Registries (28:55) To overcome skill isolation without custom discovery backends, Google Cloud provides a managed Skill Registry within its Agent Platform. The registry incorporates version control, package management, and semantic search, allowing runtime agents to dynamically locate and invoke tools on demand without carrying static tool definitions inside their base prompts. Implementing this architecture follows a three-step workflow: defining the skill with strict constraints (including a lowercase name under 64 characters and a detailed description for semantic matching), publishing the versioned skill to the cloud registry via an API or SDK, and configuring agents to discover and execute skills dynamically. This decoupling allows enterprise teams to govern, update, and share capabilities across distributed systems without rewriting core agent logic. While the workshop demonstrated how graph orchestration and cloud skill registries resolve local prompt bloating and tool isolation, tight session time limits prevented a full exploration of production evaluation frameworks and governance loops, leaving attendees to complete advanced deployment exercises via self-paced repositories.

精炼阅读摘要

Google Cloud 团队指出,当前企业级 AI 智能体开发的核心瓶颈在于本地原型与生产部署之间的工程断层;通过采用图编排架构的 Agent Development Kit (ADK) 与云端技能注册表,开发者能够克服单体提示词失真与本地工具孤岛问题,构建具备确定性计算与动态扩展能力的云端智能体。 本地原型转向生产环境的工程鸿沟 (0:04) Christina Zhu 与 Google Cloud 团队指出,尽管开发者借助工具可以在短时间内搭建出功能性的本地智能体原型,但绝大多数企业级项目都会在迈向生产环境时停滞。本地原型通常依赖内存状态、本地工具脚本以及非沙箱化的代码执行环境,这些设计无法满足企业级生产环境对持久化会话状态、安全隔离沙箱、合规治理策略以及系统化评估与反馈循环的严苛要求。 研讨会以虚构企业 Cymbal 的运维协同助手 Nimbus 为案例展开实践。该系统的设计目标是作为站点可靠性工程(SRE)辅助工具排查微服务故障。演讲者强调,单纯发布一个智能体远远不够,企业工程团队必须能够系统性地衡量其可靠性,持续优化推理路径,并确保组织内其他成员能够安全、一致地调用该系统。 图编排架构克服单体提示词缺陷 (15:45) Christina 解释称,面对关键基础设施排障等复杂任务时,依赖单一系统提示词的大语言模型(LLM)调用必然会发生故障。当要求模型判断微服务健康状态时,缺乏外部约束的模型无法获取实时指标数据、缺乏突发事件排障手册(Runbook)、无法维持长周期对话上下文,更无法精确完成数学运算,极易产生凭空猜测与幻觉。高可靠性的运维流程必须严格遵循收集事实、遵循标准流程、精确计算数值以及输出结构化报告四个阶段。 为了保障执行的确定性,ADK v2 引入了基于有向图的工作流编排引擎。该引擎将系统逻辑分解为协调节点、确定性 Python 函数节点、外部工具及模型上下文协议(MCP)节点、LLM 子代理以及人工干预节点构成的图结构。在 Nimbus 的运行测试中,智能体通过实时指标调用与确定性数学函数精确计算出 4.7% 的错误率,并在零模型代码执行机制下规避了随机算术错误,显著降低了调用延迟与 API 成本。 可视化调试破除黑盒并提供实时追踪 (19:09) 在本地开发与验证环节,研讨会通过 Google Cloud Shell 与本地开发界面 ADK Web 展示了智能体执行过程的可观测性。传统的模型调用通常被视为不可透视的黑盒,而 ADK 调试界面能够实时呈现事件流日志、节点状态变迁、外部工具调用的请求载荷以及子代理之间的任务交接过程。 开发者可以在交互界面中直接触发不同的决策分支,并实时检查系统生成的运行工件。这种模块化的图编排结构允许工程师在不重构整体代码的前提下,针对特定推理步骤进行局部调整,随时插入新的推理节点或替换底层工具,从而深入验证智能体在诊断降级状态、上游依赖异常及高延迟链路时的决策逻辑。 云端技能注册表破解提示词膨胀与孤岛 (25:16) Emanuel 提出,将智能体从单机开发扩展至支撑数千名企业用户并发访问时,本地托管架构会面临两大工程失效模式。其一是“提示词膨胀”(Prompt Bloating):如果开发者不断向单个系统提示词中追加规则与示例,上下文负担将严重削弱模型的注意力与推理能力,增加幻觉概率;其二是“技能孤岛”(Skill Siloing):硬编码在本地环境中的工具定义无法被外部系统或协同智能体(A2A)复用,阻碍了跨团队的治理与协作。 Google Cloud 在 Agent Platform 中提供了集中式技能注册表(Skill Registry)作为解题方案。规模化扩展包含三个核心步骤:首先以严格规范定义技能(名称控制在 64 个字符以内且采用全小写,并编写用于向量语义搜索的详尽描述);其次通过 API 或 SDK 将技能打包发布至具备版本控制的云端注册表;最后由运行时智能体根据用户意图进行动态语义检索与按需执行,在避免基底提示词过载的同时实现能力的解耦治理。 研讨会展示了结合图编排与云端技能注册表能够有效提升运维智能体的工程可靠性,但现场也暴露了现实约束,例如因参会人数超出预估导致临时 Google Cloud 额度一度耗尽,以及受限于课时而未能深入展开企业级评估框架。演讲者总结指出,智能体工程的核心在于将本地脆弱逻辑逐步重构为托管式、解耦化的云端服务。

Detailed notes — zh

## Background 本视频由 Ai4 频道于 2026 年 8 月 15 日在 YouTube 发布,记录了 Google Cloud 团队的 Alan Blount 与 Christina Zhu 主持的一场全实操互动工作坊。根据页面描述,工作坊旨在探讨“Agent 工程化(Agent Engineering)”,指导开发者利用 Agent Development Kit (ADK)、Agent Substrate 与 AX 运行时,突破传统基于请求的单机架构局限,将 AI Agent 扩展为企业级、会话持久化的生产系统。 ## TL;DR 工作坊围绕从本地原型跨越到生产级系统的核心痛点展开,指出单一 Prompt 和内存状态无法满足生产环境对持久化、可观测性与治理能力的要求。主讲人以虚构的云运维助手 Nimbus(SRE Copilot)为例,演示了如何使用基于图架构的 ADK v2 构建结构化的排障与分流智能体,并通过 ADK Web 进行可视化链路追踪与调试。最后,课程介绍了借助 Google Cloud Skill Registry 解决 Prompt 膨胀与技能孤岛问题的实践路径,展示了如何将本地技能发布到云端供多智能体按需语义检索与协同调用。 ## Atmosphere & style 整场工作坊节奏紧凑且充满实践气息,省去了客套开场,直接切入高密度的代码实操与云端部署环节。主讲人与学员之间互动频繁,既有现场免费额度被抢空后的幽默调侃,也有助教现场答疑的活跃技术氛围。整体基调专业、务实且接地气,兼顾了架构理论的深度拆解与手把手终端配置的操作质感。 ## Key takeaways - [01:23](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=83s) 企业级 AI Agent 的核心痛点在于原型与生产环境间的鸿沟:本地运行的 Agent 依赖内存状态与本地工具,缺乏持久化执行、沙箱隔离、弹性伸缩、统一治理以及评测反馈闭环。 - [01:23](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=83s) 工作坊通过构建云运维副驾驶 Nimbus(SRE / Cloud Ops Copilot)演示完整流程,证明单一模型调用或单一 Prompt 无法直接解决缺乏实时指标、排障手册及数值计算的复杂生产问题。 - [03:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=196s) 推荐采用 Google Cloud Shell 统一开发环境,可消除不同操作系统在本地环境与依赖上的兼容性差异,并借助 Google Cloud 内部网络降低网络延迟。 - [15:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=907s) ADK(Agent Development Kit)v2 采用基于图的工作流(Graph-based Workflow)架构,通过显式定义节点与分支,实现比单纯依赖 Prompt 更精确、可预测且具备事实接地(Grounded)的状态控制。 - [15:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=907s) 基于图的架构允许将数据清洗、规则判断等无需 LLM 的逻辑以确定性代码函数运行,大幅降低推理成本并提升执行效率。 - [19:09](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1149s) ADK Web 调试器(adk dev)提供了全链路白盒化可视化能力,开发者可在浏览器中实时监控事件日志(Event Log)、状态流转、构件追踪以及子 Agent 调用链。 - [25:13](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1513s) 单机本地 Agent 面临 Prompt 膨胀(Prompt Bloating)与技能孤岛两大瓶颈,把所有指令堆入单一大 Prompt 会加剧模型幻觉并使模型能力退化。 - [28:53](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1733s) Google Cloud Skill Registry 提供了云端技能注册与治理方案,支持技能的语义描述定义、一键发布推送,以及 Agent 在运行时通过语义搜索动态按需加载和跨团队复用技能。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=4s) 开场介绍与工作坊目标 Google Cloud 团队的 Alan Blount 与 Christina Zhu,携手客座讲师 Dr. Emanuel Eadik 共同拉开本次实战工作坊的序幕。主讲人直奔主题,表示由于内容极为充实,将省去冗长的前置介绍。本次工作坊的核心目标在于建立开发者在 Google Cloud 上构建、评估以及部署企业级 AI Agent 平台的信心与实操能力。 现场调查显示绝大部分参会者均携带了笔记本电脑,讲师们鼓励少数未带设备的学员与身旁同伴组队参与。整个 Session 强调高互动性与全实操(Hands-on),所有流程均配合云端 Live Demo 同步推进。 ```mermaid flowchart LR accTitle: Agent开发全生命周期 A["构建 Agent<br/>(Building)"] --> B["评测 Agent<br/>(Evaluating)"] B --> C["部署到 GCP<br/>(Deploying)"] ``` --- ### [01:23](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=83s) 从原型到生产:Agent Engineering 的鸿沟 Christina 介绍了工作坊的核心议程与技术背景。开发者使用 Agent Development Kit (ADK) 通常只需一个下午就能搭建出一个功能不错的本地 Agent 原型,但项目往往在此停滞不前。**本地原型与生产系统之间的巨大鸿沟,正是大多数 AI Agent 项目夭折的主因。** 本地运行的 Agent 依赖内存状态、本地工具与本地代码执行,这些机制完全无法直接承受生产环境的考验。企业级系统缺乏持久化执行能力(Durability)、弹性伸缩能力(Scaling)、沙箱隔离(Isolation)、统一治理(Governance)与反馈闭环(Feedback Loop)。团队往往将身份认证、内容审查和策略执行当作事后补丁而非底层架构,导致系统上线后无法回答“Agent 表现究竟如何”以及“该如何持续优化”。 本次实验系列通过逐步集成 Google Cloud 托管服务来跨越这道鸿沟,并将构建一个贯穿全流程的示例 Agent —— 虚构公司 Symbol 的云运维副驾驶 **Nimbus**(SRE / Cloud Ops Copilot)。 ```mermaid flowchart TD accTitle: 本地 Agent 原型与生产级系统的差距 subgraph Local["本地原型 (Local Prototype)"] L1["内存状态 (In-memory State)"] L2["本地工具调用 (Local Tools)"] L3["无沙箱代码执行 (Local Execution)"] end subgraph Gap["生产化鸿沟 (The Production Gap)"] G1["无持久化 (No Durability)"] G2["无隔离与治理 (No Isolation/Governance)"] G3["无反馈与评测 (No Feedback Loop)"] end subgraph Prod["生产级架构 (Production System)"] P1["会话租户运行时 (Session-tenant Runtime)"] P2["沙箱安全隔离 (Sandboxed Substrate)"] P3["Gemini Enterprise 编排与 A2A"] end Local --> Gap --> Prod ``` - **核心挑战**:单模型调用无法回答生产级运维问题(缺乏实时指标、无法计算错误率、缺少运行手册上下文)。 - **演示案例**:Nimbus —— 面向云运维(Cloud Ops / SRE)的排障与分流智能体。 --- ### [03:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=196s) 实验环境配置与 GCP 资源准备 为保证学员能顺利运行 Lab,团队提供了免费的 Google Cloud 额度兑换链接与二维码。由于现场参会人数超出预期,免费额度短时间内被领取一空,讲师团队随即协调后台追加配额,并建议未抢到额度的学员两人一组协作,或在 Lab 1 中使用 Google AI Studio API Key 作为备用鉴权方案。 针对环境准备,Alan 强调工作坊推荐使用 **Google Cloud Shell** 运行所有实验,主要基于两点工程考量: 1. 统一云端环境,避免 Windows 与 macOS 在本地命令行、依赖安装和环境变量上的兼容性差异。 2. 现场 Wi-Fi 网络负载较高,而 Cloud Shell 直接运行在 Google Cloud 内部网络中,与云端资源的通信延迟极低且不受本地网络波动影响。 学员只需访问 GitHub 仓库并在 `README.md` 中点击“**Open in Google Cloud Shell**”大蓝按钮,即可自动克隆项目并初始化云端虚拟机环境。 --- ### [09:12](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=552s) Cloud Shell 环境变量与鉴权配置 进入 Cloud Shell 终端后,学员需要设置项目环境变量并完成身份验证,以便后续命令能够无缝调用底层模型与 API 接口。 Alan 演示了环境初始化的核心步骤: 1. **指定项目 ID**:通过设置 `PROJECT_ID` 环境变量,将当前操作绑定到新创建的 GCP 项目。 2. **全局端点与认证**:配置 gcloud 命令行工具以使用全局推理端点(Global Endpoint)而非单一区域端点,以获得更优的模型可用性与吞吐量。 3. **完成 OAuth 登录**:通过命令行触发认证流程,在弹出的授权窗口中确认账号权限,使本地环境具备调用 Vertex AI 和 Gemini 模型的凭证。 --- ### [12:46](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=766s) Lab 1 初始化与本地测试验证 Lab 1 采用“半成品/预制工作区”模式,预先配置好了基础的 MCP(Model Context Protocol)服务器定义、技能集(Skills)、测试套件以及 Nimbus 的初始代码框架。 在深入代码之前,Alan 演示了标准的验证流程: ```bash cd labs/01_adk ./test.sh ``` 通过运行内置测试套件及环境依赖检查脚本 `python check_prereqs.py`,确保所有依赖项、GCP 鉴权凭据及网络链路均处于绿色就绪状态。 --- ### [15:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=907s) ADK v2 架构原理解析:基于图的工作流与节点组合 Christina 深入解析了为什么单靠 Prompt 无法支撑复杂企业任务,以及 **ADK (Agent Development Kit)** 的核心设计理念。 当运维工程师向 Agent 询问“Checkout 服务是否健康?请进行故障排查”时,单一的大语言模型调用根本无法给出准确答案——它不掌握实时指标、没有运维手册(Runbook)、无法进行错误率数值运算,也缺乏多轮对话的上下文记忆。生产级 Agent 必须经过“**收集事实 $\rightarrow$ 执行流程 $\rightarrow$ 计算推导 $\rightarrow$ 生成报告**”的严格编排,所有输出必须具备扎实的事实接地(Grounded),严禁臆测与幻觉。 ADK 是 Google 推出的模块化、模型无关(Model-agnostic)的 Agent 开发框架,专为 Gemini 和 Google Cloud 进行了深度优化,同时支持接入任意模型并部署在任意平台上。ADK v2 采用了标准的**基于图的工作流(Graph-based Workflow)**架构,节点(Nodes)之间通过边(Edges)连接: ```mermaid flowchart TD accTitle: ADK v2 图工作流架构 subgraph Graph["ADK 复合工作流图 (ADK Workflow Graph)"] N1["代码函数节点<br/>(Deterministic Function)"] --> N2["LLM 子智能体<br/>(LLM Sub-agent)"] N2 --> N3["工具执行节点<br/>(Tool / MCP Action)"] N3 --> N4["人工介入节点<br/>(Human-in-the-loop)"] end N4 --> Out["状态持久化与输出 (Persist & Report)"] ``` #### 为什么采用图结构而非长 Prompt? - **精确的状态控制**:显式定义节点间的流转、状态共享与分支逻辑。 - **降本增效**:无需调用 LLM 的环节(如确定性数据清洗、规则判断、工具前置处理)以纯代码函数运行,速度极快且完全免费。 - **高可靠与可预测性**:将不可控的模型生成约束在确定的工作流骨架中。 在代码实现层面,开发者使用 Python 定义技能解析器(Resolvers)、MCP 工具集、根智能体(Root Agent)以及本地运行器(Local Runner),由运行器统一接管会话管理(Sessions)、记忆(Memory)与制品服务(Artifact Services)。 --- ### [19:09](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1149s) 运行 Nimbus 并启动 ADK Web 可视化调试器 学员随后在 Cloud Shell 中实际执行了 Nimbus Agent 的测试与对话命令: ```bash cd labs/01_adk ./test.sh ``` 测试通过后,向命令行中的 Agent 发送排障指令: > “Is checkout healthy? What is its error rate?” Agent 经过多步工具调用与计算后返回了结构化诊断结果:检测到服务处于**降级状态(Degraded)**,当前错误率为 **4.7%**,并输出了延迟指标及异常根因分析。 最后,Christina 演示了通过 `ADK Web`(即 `adk dev` 调试套件)启动图形化 Playground。开发者在浏览器新标签页中不仅可以与 Agent 进行交互式对话,更能实时观测到后台完整的调用链路追踪(Trace):从用户输入、意图分发、工具检索、子 Agent 触发到参数序列化,提供了白盒化的全链路可视化排错能力。 ### [22:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1327s) 通过 ADK Web 调试与检验 Agent 在 Lab 1 的实操环节中,讲师展示了刚刚构建完成的 Agent 调试日志。通过界面侧边的事件日志(Event Log),开发者可以直观地看到此前讲解的各个执行节点以及图结构(Graphs)的流转过程。这虽然只是 Agent 的基础形态,但 ADK Web 为开发者提供了一套完整的可视化调试、对话交互以及事件追踪机制。 讲师鼓励在场学员主动与自己的 Agent 对话,尝试触发不同的图节点,探索并观察它的行为与状态。在 ADK Web 中,用户不仅能查看 Agent 的内部状态(State),还能追踪它生成的构件(Artifacts)并进行评估(Evals)。现场多位助教(TA)随时协助解决学员在运行 ADK Web 时遇到的问题。 ```mermaid flowchart LR accTitle: ADK Web 调试流程图 subgraph Client ["ADK Web 交互界面"] A["开发者交互输入"] --> B["触发图节点/工作流"] end subgraph Observability ["状态与监控"] B --> C["Event Log 事件日志"] B --> D["State & Artifacts 追踪"] end C --> E["问题排查与评估"] D --> E ``` ### [23:00](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1380s) Lab 1 核心收获与本地模块化设计 讲师总结了 Lab 1 的核心认知:面对像“结账系统是否健康(Is checkout healthy?)”这样复杂的运维问题,单一的 Prompt 根本无法给出可靠答案,因为 Prompt 本身既没有系统指标数据,也没有排障手册(Runbook),更不具备数学计算能力。ADK 提供的图编排工作流(Graph-based workflows)能够协调复杂的子任务,从而准确地进行问题分诊与排障。 在架构设计上,本地构建的 Agent 具备极佳的模块化特性,开发者无需重写核心逻辑即可自由替换其功能组件。学员可以动手修改内部的推理逻辑、增加新的节点并在 ADK Web 中实时查看更新,或者挂载自定义工具。 - **为什么单一 Prompt 会失效**:缺乏动态指标、缺少标准排障手册且无数学计算支持,必须依赖图工作流。 - **模块化优势**:支持随时热插拔或替换能力,面向生产环境无需推倒重写代码。 - **自主实验方向**:修改 Agent 推理逻辑、添加新工作流节点、绑定自定义 Tools。 --- ### [24:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1456s) 从本地迭代迈向云端扩展 完成单机验证后,讲师提出了关键挑战:“Agent 现在是否具备扩展性(Scale)?”目前的 Agent 仅在本地笔记本上运行,虽然具备了扩展的架构基础,但尚未真正具备分布式扩展能力。构建 Agent 的正确路径是:先在本地笔记本上实现极速迭代与调试,随后在不重写代码的前提下,将 Agent(如 Nimbus)以托管服务(Managed Services)的形式提供给海量用户。 为了展示如何将本地技能发布到云端并让团队成员协同治理,讲师将主持棒交接给 Emmanuel,正式进入 Lab 2 的内容。 --- ### [25:13](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1513s) 扩展 Agent 的挑战:Prompt 膨胀与孤岛效应 Emmanuel 首先确认了学员的进度,并指出即使没有完全做完 Lab 1 也不影响参与 Lab 2。他向全场提问:“构建完 Agent 之后,要扩展它究竟需要什么?”现场观众幽默地喊出“金钱(Money)”,随后也有人指出“客户(Customers)”和“基础设施(Infrastructure)”。 Emmanuel 深入剖析了单机本地 Agent 面临的两个核心技术瓶颈: ```mermaid flowchart TD accTitle: 本地 Agent 与云端 Skill 注册中心对比 subgraph LocalPain ["传统本地模式问题"] P1["单一大 Prompt 持续堆叠"] --> B1["Prompt 膨胀 (Prompt Bloating)"] B1 --> H1["模型幻觉加剧 / 变笨"] P2["技能/指令仅存本地"] --> S1["其他 Agent 无法复用 (孤岛)"] end subgraph CloudRegistry ["云端 Skill Registry 架构"] R["Google Cloud Skill Registry"] R --> F1["按需语义检索 (Semantic Search)"] R --> F2["动态拉取技能 (Dynamic Loading)"] R --> F3["多 Agent 协同与跨团队共享"] end ``` 1. **Prompt 膨胀(Prompt Bloating)与幻觉加剧**:若所有指令和技能全塞在一个本地 System Prompt 中,随着能力增加,Prompt 会变得极其臃肿,反而使模型变得更笨、更容易产生幻觉。必须将技能模块化拆分并托管到云端注册中心,让 Agent 根据任务需要动态进行语义检索(Semantic Search)并按需加载。 2. **多 Agent 协作受阻(技能孤岛)**:技能保存在个人本地电脑上,其他 Agent 和团队成员便无法发现和调用该技能。一旦上云,所有 Agent 都可以跨网络搜索并共享同一套技能库。 --- ### [28:53](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1733s) Google Cloud Skill Registry 的三步实践与总结 为了解决上述问题,Google Cloud 在 Agent Platform 中内置了 Skill Registry,开发者无需自行搭建基础设施。该注册中心原生支持语义搜索、高效 Prompt 组装以及技能版本管理(Versioning)。 ```mermaid flowchart LR accTitle: Skill 发布与调用三步流程 A["步骤 1:定义 Skill<br/>(名称 & 语义描述)"] --> B["步骤 2:Push 到 Registry<br/>(Google Cloud Agent Platform)"] B --> C["步骤 3:Agent 检索并调用<br/>(Semantic Search & Runtime)"] ``` Emmanuel 详细拆解了使用 Skill Registry 的三个核心步骤: 1. **定义技能(Write Skills)**:设定符合规范的名称(小写字母、64 字符以内)并编写详细的 `description`。该描述至关重要,因为 Agent 是基于语义搜索来匹配并定位最合适技能的。 2. **推送到云端(Push to Registry)**:利用几行简洁的代码,将定义好的技能直接发布到当前 Google Cloud 项目的 Agent Platform 注册中心。 3. **Agent 按需调用(Agent Calling)**:Agent 在执行任务时动态查询注册中心并调用该技能。 由于现场时间紧张,Emmanuel 提醒学员可以参考 GitHub 仓库中的后续 Lab 指南继续操作,活动提供的 Google Cloud 额度在当天全天有效,学员可在会后继续完成技能注册与云端扩展的完整实验。 ## Notable quotes > [01:23](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=83s) 本地原型与生产系统之间的巨大鸿沟,正是大多数 AI Agent 项目夭折的主因。 — Christina Zhu > [03:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=196s) Open in Google Cloud Shell — Alan Blount > [15:07](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=907s) 收集事实 → 执行流程 → 计算推导 → 生成报告 — Christina Zhu > [19:09](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1149s) Is checkout healthy? What is its error rate? — Christina Zhu > [23:00](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1380s) 面对像“结账系统是否健康(Is checkout healthy?)”这样复杂的运维问题,单一的 Prompt 根本无法给出可靠答案,因为 Prompt 本身既没有系统指标数据,也没有排障手册(Runbook),更不具备数学计算能力。 — Christina Zhu > [24:16](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1456s) Agent 现在是否具备扩展性(Scale)? — Christina Zhu > [25:13](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1513s) 构建完 Agent 之后,要扩展它究竟需要什么? — Dr. Emanuel Eadik > [25:13](https://www.youtube.com/watch?v=bmpGoCDvcOA&t=1513s) 若所有指令和技能全塞在一个本地 System Prompt 中,随着能力增加,Prompt 会变得极其臃肿,反而使模型变得更笨、更容易产生幻觉。 — Dr. Emanuel Eadik ## Mentioned Google Cloud, Ai4, Alan Blount, Christina Zhu, Dr. Emanuel Eadik, Agent Development Kit (ADK), ADK Web, Nimbus, Symbol, Agent Substrate, AX, Gemini Enterprise, Agent-to-Agent (A2A), Vertex AI, Google AI Studio, Google Cloud Shell, Model Context Protocol (MCP), Skill Registry ## Video description Alan Blount - Product Manager, Google Cloud Christina Zhu - Developer Advocate, Google Cloud Important Note: This hands-on, interactive workshop is led by Google Cloud and is open to all Ai4 attendees at no additional cost. No RSVP or separate registration is required. To participate and get the most out of this session, please bring your own device (a laptop is recommended). Devices will not be provided on-site. ABOUT THIS WORKSHOP: Building a single AI agent locally is straightforward; scaling it reliably across an enterprise is where traditional request-based architecture breaks down. This session explores 'agent engineering' and the shift toward session-tenant compute. We will demonstrate how to separate your agent's core logic using the Agent Development Kit (ADK) from the complex infrastructure of durable execution. By pairing Agent Substrate for secure, sandboxed isolation with AX for a resumable runtime harness, you can efficiently scale stateful, long-running sessions. Finally, we will showcase how Gemini Enterprise serves as the unified interface to orchestrate these capabilities, seamlessly connecting users to specialized agents via Agent-to-Agent (A2A) protocols. [Source](https://www.youtube.com/watch?v=bmpGoCDvcOA)

Source quotes

[1:23] Christina Zhu: 本地原型与生产系统之间的巨大鸿沟,正是大多数 AI Agent 项目夭折的主因。 [3:16] Alan Blount: Open in Google Cloud Shell [15:07] Christina Zhu: 收集事实 → 执行流程 → 计算推导 → 生成报告 [19:09] Christina Zhu: Is checkout healthy? What is its error rate? [23:00] Christina Zhu: 面对像“结账系统是否健康(Is checkout healthy?)”这样复杂的运维问题,单一的 Prompt 根本无法给出可靠答案,因为 Prompt 本身既没有系统指标数据,也没有排障手册(Runbook),更不具备数学计算能力。 [24:16] Christina Zhu: Agent 现在是否具备扩展性(Scale)? [25:13] Dr. Emanuel Eadik: 构建完 Agent 之后,要扩展它究竟需要什么? [25:13] Dr. Emanuel Eadik: 若所有指令和技能全塞在一个本地 System Prompt 中,随着能力增加,Prompt 会变得极其臃肿,反而使模型变得更笨、更容易产生幻觉。

Source quotes

[3:16] Christina Zhu: we are now out of free credits, which sucks [12:46] Alan Blount: cooking show [12:46] Alan Blount: Is checkout healthy? What is its error rate? [15:45] Christina Zhu: Is checkout healthy? Triage it [25:16] Audience: Money [25:16] Audience: Customers [25:16] Audience: Infrastructure [25:16] Dr. Emanuel: prompt bloating [25:16] Dr. Emanuel: dumber

Original transcript

[0:04] I'm Alan. I'm happy to be here. Uh we're  going to go real quick because we got a [0:06] lot of material to go through. I'm not  going to do a lot of intros. You go. [0:11] Oh. And my name is Dr. Emanuel Eadik. I'm  really passionate about um sharing cutting [0:18] edge technology to the um everyone. So  really excited for this presentation. [0:25] And my name is Christina. I'm a  developer advocate here at Google Cloud. [0:33] Awesome. So, our goal today is to empower you to  have confidence in using agent platform in terms [0:41] of building your agent, evaluating your agent,  and deploying your agent to the Google cloud. So, [0:48] by your show of hands, how how many of you have  your laptops? Okay, pretty much everybody, right? [0:54] Is there anyone that doesn't have a laptop?  Okay, I see a few hands. So, if you don't mind, [0:59] if you don't have a laptop, if you don't  mind, you know, joining someone next to you [1:04] so that you can, you know, participate. So, this  is going to be a very interactive session. Um, [1:10] it's going to be very handsome. So, we encourage  everyone to follow along and and we're going to [1:15] also be running live demo. So, with that, I will  pass it to Christina to kick us off. Thank you. [1:23] So, this is going to be our agenda for today.  We're going to be spending some time setting up [1:27] everyone's computers with some free GCP credits  and getting the lab demo code working. After that, [1:33] we're going to go straight into building some  agents with ADK as well as adding some skills, [1:38] tools, and deployment. Um, we're going to try  and get through of as many of these as we can. [1:43] Uh, but even if we don't get through all of  them, you guys will still have the credit and [1:47] still have the code. So, after this workshop, you  guys continue at your own pace. So, what is this [1:53] workshop about? Why why should you guys care? So  you can build a pretty capable agent in ADK in [2:00] one afternoon and then stall. So the gap between a  working prototype and a production system is where [2:05] most agent projects die. There's no durability,  scaling, isolation, governance or feedback loop. [2:12] Um so this workshop series is about crossing  that gap deliberately one service at a time. [2:19] While a local agent has in-memory state, some  local tools, and some local code execution, [2:24] none of it really survives production yet.  The platform has many managed services, [2:28] but no single story connecting them  all like identity, content screening, [2:32] and policies. They get treated as, you know,  afterthoughts instead of additive layers. [2:37] So, teams ship agents, but they can't answer,  is it any good? You know, how do I improve it? [2:43] And even a great agent is useless if no other  employee can access it. Here are a couple of the [2:48] features that we have on agent platform on Google  cloud that helps bring your agents to production. [2:53] We will not be touching upon all of these  today but we will be touching on a few of them. [3:00] So today's workshop demo we will be  creating Nimbus uh which is going to [3:04] be our running example of a cloud ops code  pilot for the fictional company symbol. [3:09] Um every capability in this lab series makes  Nimbus a little bit more production ready. [3:16] So, we are going to be spending some time setting  up. So, I encourage you guys to take a picture of [3:21] this screen if you can or scanning this QR code,  but today we will be giving you guys a couple [3:28] dollars of free GCP credits um and they expire at  the end of the day today. So, while you can please [3:34] claim them um so we can continue in our  workshop and use them during this session. Um, [3:40] anyone blocked on billing can create a  AI Studio API key for lab one, but um, [3:46] I'm going just wait a couple more minutes and wait  for people to finish claiming their GCP credits. [3:54] So, if you guys have taken a picture of the GCP  credits and have accessed the link, this is what [4:00] you guys will be seeing. It will probably ask you  to do a capture of some sort. Um, and after you [4:06] claim your credit successfully, it will say it has  created a new billing account. So, if you look on [4:11] the right side of the screen, if you click through  that link that says go open my billing accounts, [4:17] um, you will see a brand new billing account  show up after a few minutes. So, it might take a [4:21] little bit, but you will have a brand new billing  account in your Google Cloud account called um, [4:30] yeah, so if anyone still needs this is this  is the link put your hand up. Yeah. So, [4:35] if you if anyone needs help, like, please put your  hand up. And if you don't have a GCP account yet, [4:40] now is probably a good time to make one. [4:43] Okay. So, it has come to my attention that we  are now out of free credits. Um, which sucks. [4:56] So, I think the we did not properly um  account for this demand. That being said, [5:03] I will be requesting a new batch of credits for  everyone that has attended today and reactivating [5:09] this code. So, for those who  were able to get credits, um [5:15] Huh? That's true. Yeah, we will be reactivating  the credits. So, for those who were not able to [5:20] claim the credits today, maybe partner up with  someone who was able to do so and then we will [5:26] be reactivating this after this workshop so you  can claim your own and try it out yourself. Yeah. [5:35] Okay. So, for those of you who are able to  create a new project and attach the credits, [5:41] um the next thing we're going to be doing is  going to the workshop. So, this is going to be [5:45] the workshop itself and the demo.  Uh and we will be cloning this code. [5:51] So, if you have the ability, I recommend taking  a picture of this slide just so you have the URL. [6:03] You also don't necessarily need a git clone. We  will be using a cloud shell for most of this demo. [6:16] And I would like to say that we're setting this  up with some decisions to try and make it easier [6:21] for a wide audience. If you are comfortable with a  command line and you would like to do this on your [6:26] own laptop, do it on your own laptop. Uh we're  going to demonstrate doing it on a cloud shell [6:33] for a couple of reasons. One, it simplifies  the Windows versus Mac command choice. And two, [6:39] Wi-Fi in places like this are a little bit  spotty. And the cloud shell is actually running [6:46] in the cloud very close to all of the other  resources and doesn't rely on so much Wi-Fi. But [6:51] dealer's choice. You're allowed to uh run  this on your laptop if you would rather. [7:00] So if you have made it to the GitHub  page, if you scroll down in the readme, [7:06] you will see a section that says cloud shell.  So if you click on open in Google Cloud Shell, [7:11] it will automatically clone the repository for  you into the GitHub and you will have the code [7:17] ready for you in the cloud shell. You may have  to provision your cloud shell first if it is [7:21] your first time using it in a while and it will  take about a minute, but that is to be expected. [7:27] You will probably be see something like  this. You are about to clone this repo. [7:31] Um, just say yes, I trust this repo.  It's for a workshop. And confirm. [7:41] And if you're really scared of the command  line, don't worry. There are some commands, [7:45] but they're pretty much all copy and  paste. We're going to get you through it. [7:51] Uh, how do we get it over there? [8:05] Uh yeah, [8:10] if you're using the cloud shell, the answer  is no. If you're using your local machine, [8:17] the commands that we have prepared for you  will sort of do the installs automatically. [8:26] Uh there is a big blue button in the readme  of the repo. We just think that this is the [8:33] easiest option if you're not familiar  with a terminal on your local machine. [8:43] First, you need to open the repo in the  browser so you can find and click on the [8:47] big blue button that says open in cloud shell.  That's a good point. That's a good point. [8:52] All right, we'll give this a couple  more minutes to get going and then we'll [8:55] we'll actually start doing  stuff. Thank you very much. [9:12] Yeah. So, this command should give you a  cloud shell interface something like this. [9:18] We're opening a terminal that's running on a  server in the cloud. Um, it should automatically [9:24] clone this repo for you and we're going to  start copy and pasting commands as we need to. [9:30] I'm not going to go too fast here. We're just  in the setup phases, but this is the one command [9:38] where I think you might need to go look up the  value for the project that you just created. [9:45] What is that project that you created? I am kind  of cheating here. And I have an easy project name. [10:02] Your project is going to be  de uh different than that. [10:05] Don't type in my project  name. It's not going to work. [10:08] This command simply sets a variable that we're  going to use in future commands and it's going [10:13] to make your life easier. So you can just copy and  paste the rest of the set of commands as they are. [10:24] Once you do that, you can literally copy and paste  this entire block of commands and it should work. [10:35] We can go through what each of these commands do.  Ultimately, it's just a bunch of prerequisites. [10:41] I want to run LLM inference from a global endpoint  as opposed to original uh regional endpoint. [10:48] Hold on. Let me uh oh there cursor.  There we go. I want to run this from a a [10:57] global endpoint instead of a regional  endpoint. I am telling the command line [11:02] that this is the project that I want to use and  I'm going to authenticate with this project. [11:08] That authentication step is going to pop  up a uh environment variable. Sorry, a uh [11:16] a browser window browser window. That's the  word. So, let's go through it. We've got [11:25] Oh, I'm already logged in. It didn't pop up a  browser window. Dang it. It's hard to uh hard [11:29] to explain to you what it's going to look like.  It pops up a little ooth and says, "Are you this [11:34] person? Do you want to authenticate?" It'll  open a new browser window. You got to copy [11:39] and paste a command. Dang. I want to be able  to recreate that for you and I can't do it. [11:52] That I went that I went too quick. My environment  is too already set up. Uh, maybe I should [12:00] I don't know how to reset it. Uh, probably should  have copy and paste each command. All right. So, [12:14] if you're here, have you copied and pasted  this whole block of commands? And did it work [12:19] for anybody? Yes, we got some thumbs up.  All right. I I'm seeing a critical mass [12:24] of thumbs up. I'm moving forward. put  your hands up if you have problems. Um, [12:29] okay. So, this is further setup steps in case  that didn't work, right? If you need to fail [12:34] over and use an AI Studio Lab key, you can do  that. You're not using Google Cloud and you [12:39] can't continue through the future labs, but you  could get through lab one. Let's go to lab one. [12:46] This is kind of a cooking show setup in which  we have a lot of this already built. We've [12:52] made some design choices. We have a MCP server  configured for you. We have some skills set up. [12:58] We have the source code of our Nimbus  agent. We have some tests that we can run. [13:05] We have an environment variables that we can set  up, but I think that that's optional in a stack. [13:10] And then we have this readme that  we're going to kind of walk through. [13:13] So if you look at lab one and scroll down, it says  change directory into labs01 and run the tests. [13:22] I'm going to do just that set of commands so  I don't go quite so fast like I did last time. [13:27] So I'm going to CD into that directory and  just going to run some automated tests. [13:32] I like tests. I like running tests anytime  I do anything. So we might as well just [13:36] verify that things worked. They worked on my  machine. I hope they work on your machines. [13:41] This is a good sort of calibration step  to make sure that setups all worked. [13:49] Assuming that that worked, we're going to execute  our agent with this run command. Now, this might [13:55] not be the interface that you're always going to  use, but we're going to use it right now because [14:00] it's convenient for us to see that the agent did  all of the parts and pieces that it needed to do [14:07] without opening things, clicking things, etc.  This is just a single copy and paste command [14:11] that executes the whole life cycle of this system  and we should get a response. Remember that the [14:17] use case for this agent is uh sort of an S  sur agent. We're troubleshooting problems. [14:23] What are the types of problems that we have?  Describe them to me. That's what's happening here. [14:31] Now, let's take a look in more detail. Do do we  want to switch to a manual because he was supposed [14:34] to do this part or do you want me to keep going?  Are you going to do it? Yeah, you go. You go. [14:42] So, I'm glad to hear that some people were able  to do it. So, if you are finished verifying and [14:49] setting up your environment, you can also run  python check_perx.py. And if that's all green, [14:57] um we can move forward to the  next step, which is lab one. [15:07] So lab one um what we will be  building is a very basic ADK agent. [15:13] So right now if you ask an on call engineer um to  ask its agent is check out healthy triage it the [15:20] single model call can't answer that very honestly.  It has no live service metrics no incident runbook [15:26] and no way to do the error rate math. It also has  no memory of the last conversation. A production [15:33] agent has to orchestrate several steps in order to  answer this question honestly like gather facts, [15:38] follow procedure, compute and report. So it has  to be grounded and not guessed or hallucinated. [15:45] So plumbing these capabilities are not easy. You  have to create a tool calling loop. You also have [15:50] to add session and memory and then also a code  execution sandbox where it can't touch other [15:55] parts of your computer and then you have to  rebuild it so it can scale reliably as well. [16:01] So for lab one, we try to answer the question,  how do we orchestrate and scale the agent to serve [16:06] thousands of users and this is where ADK comes in.  ADK is Google's modular model agnostic framework [16:14] for building agents like standard software  development is optimized for Gemini and Google [16:19] Cloud. But because it's framework independent,  you can use any model you want and deploy it [16:23] on any platform you like. And these are a few of  the reasons why I like ADK. So the standard shape [16:31] of ADK v2 is a graph-based workflow. There are  nodes that are wired by edges. Um and this is [16:37] like an example very basic architecture  of what ADK looks like under the hood. [16:44] So an ADK uh graph can have a node that can be  an AI agent, a tool that performs an action, a [16:51] function that runs your own code, and then we also  have a human input node that pauses for a person [16:56] or a whole subworkflow used as one  node. So there's agents, sub agents, [17:00] and all these other functions that you can add  onto your ADK agent to make it more effective. [17:05] So for the app that we are building called Nimbus,  it mixes all of them. We have plain functions, [17:11] we also have LLM sub agents, we also have report  presence and persists. So this mix is exactly how [17:18] you put AI um to work in production. So why not  just run one super super long prompt with all [17:27] the steps? Why do we have to break it up into  these little nodes and these little graphs? So, [17:32] first it defines precise logic. It explicitly  maps the transitions between nodes. Um, it can [17:37] introduce really complicated structures like  branching and state management. And next, [17:42] it can run chains of functions without AI. So,  it can call tools and your own code without [17:47] invoking a model, which is faster and free. So,  it also enhances reliability and predictability [17:54] as well. So these are all very important things  to consider when deploying a agent in production. [18:00] When we define the whole agent in Python with  a ADK, um we write a bunch of resolvers like [18:06] skills MCPN code. We wire the four-stage graph  and then we wire it locally. So the first thing [18:12] we have to do today is run the tests, ask a  question from the CLI, and then open ADK dev [18:18] and then we can actually do the trace. So this  is actually what you're going to do right now. [18:25] I'm just going to give you a little overview on  the code that is included in lab one. Um, so this [18:31] is how we wire the agents capabilities. We're  going to be creating a couple different tool [18:35] sets. Um, as well as a resolver for the executor.  We're also going to build a root agent here. So, [18:41] this is going to be the main agent triaging the  different things that Nimbus will be handling. [18:47] And then this is how we actually run the  agent. So we will be building a local runner [18:51] that will be handling our sessions, our  memory and our artifact services as well. [18:57] So let's go back to the actual code  in the lab which down here somewhere. [19:09] So if we go into labs in the  GitHub repo that you just cloned um [19:15] and you can reach here if you go to like  the homepage of the GitHub oops sorry [19:22] uh right here and then go down  to here and click on 01 ADK. [19:29] This will actually bring you to the first lab  which you will be doing what I just explained. [19:35] And what you will want to be doing is running  this lab here and running these commands in [19:40] the cloud shell that you just created. So  if we copy this command and cd into it. [19:48] So we already are in 01. So now we want  to run test.sh in the same cloud shell. [20:03] So hopefully you guys will be able to run these  tests successfully and hopefully they will be [20:08] passing. So if you see your test passing that is  good and that means all your GCP credentials and [20:14] whatnot are wired up. Afterwards we want to  actually query the agent that we just built. [20:21] So if we copy this line we can actually talk  to our agent that we just created. So this says [20:26] is checkout healthy um what is its error  rate? You actually can change this prompt [20:31] if you like and ask it something else as well.  So I'm going go here and run this command. [20:43] And it does take a little while to  reply back to us because it's thinking. [20:48] But this will be the very basic version  of Nimbus that you have created today. [20:55] So we can see that Nimbus replied and it said  the status is degraded. Our error rate is 4.7% [21:00] and it also tells us the latency and a couple  other things that are wrong. So this will be [21:05] the very basic version of ADK primitives that  run locally on your machine. So the next thing [21:10] we want to do is actually open ADK web source. And  what this is going to do is open like a very basic [21:16] playground for you to actually interactively  talk to your agent. So if we launch this [21:23] and we'll give it a little bit here, you will be  actually able to see if we open this in a new tab. [21:36] So this is actually the agent we just created  and we click a new session, we can talk to it. [21:42] Let me let me zoom in. [21:56] So this is kind of like think of it as a visual  debugger for all of the agent stuff that you just [22:03] created. So even though I just said hi, you  can see all the different tool calls and all [22:07] the debugging logs for the agent you just created.  And if you look at the event log here on the side, [22:12] you can see all the different nodes and the  graphs that I explained earlier for lab one. [22:17] So while this is the very base case for  your agent, now you have a way to debug, [22:20] talk to it and see its events as well.  So I encourage you to talk to your agent, [22:25] see what kind of different nodes you can trigger  and, you know, kind of explore and interact with [22:29] your agent this way. You can also view the state  of the agent, see what artifacts it can make, [22:35] and see what other evals, but we're not going to  get into that today. But yeah, this is this is the [22:39] cool part where you kind of debug and see what's  up. So if you have any problems running ADK web, [22:48] uh please raise your hand if you see a  TA and hopefully we will get to you soon. [23:00] But yeah, for lab one, here are a couple of  the key takeaways once you have finished um [23:06] interacting with with it with ADK web. So, one  prompt cannot really answer is checkout healthy. [23:13] There are no metrics, no runbook, and no math.  ADK provides graph-based workflows to orchestrate [23:18] complex agents that can actually accurately answer  and help triage the problems that you face. Your [23:24] agent is modular, so you can swap its capabilities  for production without rewrite anytime. [23:33] Um, so now you can tweak it yourself. Actually,  now it's time to get hands-on. The lab for this [23:38] module challenge you to create a new agent or to  edit it how you wish. You can actually edit the [23:45] reasoning within the agent itself. Um, you can add  a new node if you would like and you will actually [23:50] see a popup in ADK web. You can add your own tools  or actually just ask something else which might be [23:57] um the lightest lift here, but there are a couple  different things that you can do with your agent. [24:03] Um I do have a Q&A section, but maybe we  can leave that at the end. We do have about [24:10] a couple minutes left, I think. [24:16] And one last section. So, does the agent scale  yet? Um this is the second half of the problem. [24:22] I mentioned earlier. So it currently does  not scale. It is still currently local but [24:26] it is ready to scale. Um the second half of  the problem is the orchestration of scaling. [24:32] You want to start on your laptop for fast  iteration which is a step that we completed. [24:36] But eventually we want to serve Nimbus to many  users as managed services without rewriting it. [24:43] Um okay. So I'm going to go around and answer some  questions and then maybe if we have time we can go [24:48] over lab 2 really quickly. We are just going to  skip into lab two. Hopefully lab one was somewhat [24:57] successful. Let's go into lab two. The purpose of  lab two is to show that the skills that you have [25:04] can be registered to a cloud server and then  governed by other team members and we're going [25:09] to show you how to do that. Emanuel's here and  this is his section. So I'm going to hand it off. [25:13] Yeah. Just a quick show of hands like  just let's let's do a quick um reset. [25:18] Quick show of hands. How many of you  were able to get through lab one? [25:23] Okay. Okay. So, a lot of people. How many  of you were still trying to get through it? [25:30] Okay. Um, no worries. If you didn't get  through lab one, you still have time, [25:35] you know, after this to to to catch up. But  that is not a prerequisite for lab two. Um, [25:43] actually, I have some Do we want to present  some slide or we just go straight away? [25:49] Okay. Okay. So, right now let's assume we are all  we all have built an agent, right? Um so now that [25:56] we have built an agent, so please if you can go  to the slide. Um now that we've built an agent, [26:00] we want to scale our agent. By a show of hands  well I would like to um ask a question here [26:08] like so once you have built your agent what  do we need to scale the agent? Shout it out [26:14] if if you um know like what what is required  to scale your agent once you have built it. [26:22] Money. Okay. [laughter] Exactly. I mean  that that's part of it. Um any anybody else? [26:31] Sorry. Customers. Okay. Um  infrastructure. Exactly. Yeah. [26:40] All all of these are in the right direction.  Um but yeah to scale your agent um one of the [26:47] things that are important like the agent that you  have all created live in your local laptop. Um [26:53] one of the things that's required to scale it  is actually to move some of the instructions [26:58] or the skills to the cloud. Um and the  the there are two major challenges of the [27:05] current setup that we all have gone through  now is that our um context or our prompt [27:13] all lived in our local laptop and the scales live  in a local laptop and that has that's problematic [27:20] for two main reason. Number one is whenever you  try to add additional capability to your agent, [27:27] you will continue to expand this prompt and you  will lead to something called the pro prompt [27:32] bloating and that will make your agent even  dumber. So the more you are writing big prompt, [27:39] one single system prompt for your agent um the  more the agent you know can actually hallucinate. [27:46] So what we need to do is to find a way to um split  like modualize these skills and push it to some [27:57] um registry on the cloud. So, a better setup is  where you um clean up your like you write your [28:07] um some of these skills and push it to some  registry. And then your agent should be able to [28:14] um your agent should be able to search for any  skills that he want that that he needs to use [28:21] um at the right time and be able to pull that  skill and use it um to accomplish the task. [28:27] And this also solves the second problem that I  I will mention with the old approach which is [28:34] if you want another agent to use your  skill. If he lives in your local machine [28:39] then other agents will not be able to use  it. So but now that he lives in the cloud [28:44] other agents can be able to search the same  skills and be able to um use it as well. [28:53] Okay. So to wrap up here um now how  do you um build a skill register? [29:00] The good news is that you don't have to build  one yourself. Google has already built one. Um so [29:06] in agent platform we have um a skill register [29:10] and the interesting thing about this skill  registry is that it has a lot of packages. [29:15] It can search you can do semantic search. So your  agents should be able to search those skills and [29:21] be able to load them. um efficient prompt. It's  you can also version your your skills. Now, [29:30] so um so now that we like we're going to build  these skills in three key steps. One is you write [29:40] your skills like you define what these skills  are and we're going to show you quickly how you [29:45] write those skills and then the second step is you  just push it to the registry. You all have created [29:49] a Google cloud project. So there's a registry  within agent platform. You push those skills [29:55] into that agent platform and then you step three  is just your agent will call them. So let's do a [30:00] quick um let me quickly show you what this looks  like and we can go straight into lab two. So um [30:09] yeah, so this is what uh a scale looks like.  You give it a name and this valid name like it [30:15] has to be less than 64 characters lower case you  know um and then you give it a description. This [30:21] description is very important because this is the  semantic search. This is what the agent uses to [30:27] search and find the right skill. So now that you  define a skill, the second step is to push it to [30:33] Google Cloud registry. And it's as simple as  this. Um with this code you can quickly push it to [30:41] the Google cloud registry and then um you  can have your agent call it. I know we are [30:46] short on time. We are running um short on  time but if you go back to the GitHub page [30:52] we have many labs. We have labs for um this this  particular um skill u pushing your skill to to [31:01] cloud registry and we have other labs. So feel  free to follow up and complete the remaining labs [31:08] and your Google Cloud credits will still be  available for the um for the rest of the day. [31:12] But with that, thank you so much for attending  this talk. We really appreciate your presence.