DEV Community: Google AI

Claude Haiku 5.5 is available on Google Cloud

Jen Harvey — Wed, 07 Oct 2026 18:06:52 +0000

Hey developers!

If you’ve been building autonomous agents or multi-agent orchestrations, you already know the pain: latency degrades the user experience, and high token volume stretches production budgets.

Developer choice is important to us so today, we're excited to share that Anthropic’s Claude Haiku 5.5 is officially available on Google Cloud!

As the fastest, most efficient member of the Claude 5.5 family, Claude Haiku 5.5 is engineered from the ground up for high-volume, latency-sensitive agentic work. It is designed to be the ultimate supporting player in your agent systems.

Is it time for you to try it? -> https://console.cloud.google.com/agent-platform/publishers/anthropic/model-garden/claude-haiku-5-5

And enjoy this Haiku about Claude Haiku 5.5:

Fast subagent flies,
Model Garden hosts the spark,
Agents run in light.

stop-using-complex-urls-for-your-demos.us-central1.run.app

Ruchika Goel — Wed, 07 Oct 2026 01:00:03 +0000

Wish you had a custom domain for all of your demos and AI prototypes? When you deploy your apps with Google Cloud Run, you can claim easy-to-remember, globally available subdomains at zero cost (no load balancers required) with zero DNS configuration.

With Cloud Run, it’s as easy as one command to turn your code into a live, shareable app without having to manage any infrastructure. With custom URLs, you can create memorable and shareable endpoints in seconds by claiming any available subdomain: my-cool-app.cloud.run.

You won’t have to worry about load balancer setup, DNS records, CNAME setups, or certificate renewals — Cloud Run automates SSL/TLS certificates and global routing for you.

Deploy your apps on Cloud Run with a custom URL today! Read the docs for more info on getting started.

Activating Your Data Layer for Production-Ready AI

Gleb Otochkin — Mon, 05 Oct 2026 19:39:51 +0000

When discussing applications and systems using generative AI and the new opportunities they present, one component of the ecosystem is irreplaceable - data. Specifically, the data that companies gather, hold, and use daily. This data serves as the backbone for applications, analytics, knowledge bases, and much more. We use databases to store and work with this data, and most, if not all, AI-driven initiatives and new applications are going to use that data layer.

But how can we start to use the data in our AI systems? Let me introduce you to some of the labs showing how to prepare and use the data with AI models in Google databases.

Semantic Search: Text Embeddings in Database

Our journey starts by preparing our data for semantic search and running first tests to augment the Gen AI model's response by grounding it with your semantic search results. The grounding data is the basis for RAG (Retrieval Augmented Generation). Then, you can improve the performance of your search by indexing your embeddings using the latest indexing techniques.

One of the options is the Google AlloyDB database, which has direct integration with AI models and supports the most demanding workloads. The following lab guides us through all the steps, starting from creating an AlloyDB cluster, loading sample data, and generating embeddings, to using those embeddings to generate an augmented response from the Gen AI model.

Go to the lab!

Lab: Getting started with Vector Embeddings with AlloyDB AI

Objective: Create an AlloyDB cluster, generate vector embeddings for sample data, and perform semantic search to ground a Gen AI model's response.

AI integration is not limited to AlloyDB. All Google Cloud databases have AI integration and are capable of generating and using embeddings for semantic search. For example, if you are using Cloud SQL, you can also generate and use embeddings for semantic search directly within your existing PostgreSQL or MySQL instances.

The next two labs are very similar to the previous one, but instead of Google AlloyDB for PostgreSQL, we are using Cloud SQL for PostgreSQL and Cloud SQL for MySQL to use semantic search as the grounding engine for the model's response. Some steps are of course different due to variations in SQL language and different database engines, but the main idea stays the same: use our data to ground the model response and improve output.

Go to the labs!

Lab: Getting started with Vector Embeddings in Cloud SQL for PostgreSQL

Objective: Create Cloud SQL for PostgreSQL instance with AI integration, generate vector embeddings for sample data, and perform semantic search to ground a Gen AI model's response.

Lab: Getting started with Vector Embeddings in Cloud SQL for MySQL

Objective: Create Cloud SQL for MySQL instance with AI integration, generate vector embeddings for sample data, and perform semantic search to ground a Gen AI model's response.

Semantic search using text data is one of the cornerstones and important features making responses much more reliable and useful, but Google Gen AI models can offer much more. Let's talk about multimodal search.

Multimodal Embeddings: Bring Images to the Search

In real life, of course, we use all our senses, including vision, to evaluate the world around us. The Google multimodal embedding models bring an additional layer of understanding, improving search by using embeddings not only for text but also for images.

In the following lab, we use a catalog of products placed in AlloyDB and supplemented by images in Google Cloud Storage. In the lab, we show how we can use both text descriptions and images for semantic search, supplementing and replacing each other, naturally incorporating search based on image input into our response.

Go to the lab!

Lab: Multimodal Embeddings in AlloyDB

Objective: Deploy an AlloyDB cluster, import data and use text and image semantic search using multimodal embeddings, try hybrid search approach.

Preparing the data and making first steps are important for a general understanding of RAG and tools available for the search, but Google has other cases when direct AI integration can help with your data analysis without any data preparations.

AlloyDB AI Functions and Reranking

Google AlloyDB database comes with additional AI integrations that help you use some AI capabilities without data preparation. For example, the AI.IF function can perform semantic search on the fly, evaluating sentiment or comparing data in columns with a natural language query, returning results filtered by the query condition. Also, you can apply a ranking function to the search output, improving the final result. You can try some of the new functionality using the following lab and let us know if it can help in your use case.

Go to the lab!

Lab: AlloyDB AI Operators and Reranking

Objective: Deploy AlloyDB cluster and enable AI query functions, use AI query functions to filter data and ranking function to improve the search results.

But what if somebody is not particularly savvy with SQL or not familiar with the data structure in your database? The QueryData for AlloyDB can help you with that.

Generate SQL using QueryData for AlloyDB

QueryData lets you interact with the data in your database using conversational language and build data agents. You provide database-specific information in the form of context sets to improve generator accuracy.

The QueryData context add a layer describing your data schema and providing templates, facets and value search options to make your generated SQL predictable and production ready. The following lab helps you to start with the new features and generate your first queries based on your data schema.

Go to the lab!

Lab: QueryData for AlloyDB using Gemini Data Analytics

Objective: Use QueryData for AlloyDB to generate accurate and predictable SQL statements from natural language input in agentic applications

From Tests to Production

Those labs are part of the From Data Foundations to Advanced RAG module of our Production-Ready AI with Google Cloud program. Check the other modules and see if they can help you to adopt the AI capabilities provided by our Google Cloud services and tools. The end game goal is a high quality application using the full potential of modern technologies.

And stay tuned on release notes for ALloyDB and Cloud SQL - the engineering team is busy working on new features and improvements. Happy testing.

Stop "Vibe Checking" Your AI Agents: How to Build Production Evals in 60 Minutes

Frank Guan — Wed, 30 Sep 2026 16:45:07 +0000

How do you currently test your AI agents?

If you're like most developers building agentic workflows, you probably rely on the "vibe check": tweak a prompt, run a couple of manual queries, check if the output looks reasonable, and assume it's good to go.

Here's why that breaks down fast:

Silent Regressions: A teammate submits a PR or tweaks a tool definition, and you have no way to know if performance improved or degraded.
Cost & Latency Spikes: An agent gets trapped in a multi-turn retry loop, quietly burning thousands of tokens.
The "Looks Right" Trap: Output can look perfectly well-written while omitting critical parameters or hallucinating key instructions.

In this episode of the AI Agent Clinic, Google Cloud engineer Dani Zamora and Matthew Feroz (Merge) tackle this challenge live: building an end-to-end, framework-agnostic evaluation pipeline in 60 minutes.

Check out the full walkthrough below:

What We Cover in the Video

The Test Subject (DocsHound): Matt brings on DocsHound, an open-source LangGraph agent that scans GitHub issues and PRs to find documentation gaps and open automated PRs.
Framework-Agnostic Telemetry (OpenTelemetry + OpenInference): How to standardize multi-turn traces across any agent framework (LangGraph, CrewAI, AutoGen, ADK) with zero vendor lock-in.
The 3-Tier Metric Strategy: Why you shouldn't start with 50 metrics, and how to combine:
- Managed core metrics: Trajectory quality, tool-calling correctness, and groundedness.
- Custom LLM judges: Rubrics tailored to formatting, code block enforcement, and actionability.
- Deterministic assertions & operational tracking: Syntax checks, latency, token usage, and API cost.
The 0.33 Quality Blind Spot: How the automated scorecard caught a 33% documentation quality failure that manual spot-checks completely missed.

Jump Directly to Key Sections

If you want to skip straight to a specific part of the walkthrough:

00:00 — Why "vibe checking" fails in production
02:11 — Introducing DocsHound (LangGraph agent demo)
03:40 — Standardizing traces with OpenTelemetry & OpenInference
05:51 — The 60-minute eval challenge begins
06:47 — Step 1: Mapping agent execution flow with Antigravity
11:18 — Step 2: Scaffolding the open-source Agent-Eval toolkit
17:14 — Balancing quality vs. latency vs. token cost
18:34 — Step 3: Translating quality definitions into custom metrics
21:40 — Step 4: Inspecting the scorecard & spotting the 0.33 failure
24:08 — Why automated evals change how you build agents

Open-Source Repositories & Resources

Follow along with the exact tools used in the video:

📺 Full Video: Watch on YouTube (25 mins)
🛠️ Agent-Eval Toolkit: github.com/google-cloud-tech/agent-eval
🐶 DocsHound Agent Code: github.com/google-cloud-tech/docshound
📖 Enterprise Agent Platform Docs: g.dev/cloud/agent-evaluation

👉 Watch the full video above to see how to set up the eval pipeline step-by-step. If you have questions about instrumenting your own agent framework or setting up custom metrics, drop a comment below!

Sub-second semantic filtering in PostgreSQL: Integrating the ultra-fast Jev model with AlloyDB

Gleb Otochkin — Tue, 29 Sep 2026 17:00:53 +0000

Introduction

If you are working with semantic search, vector embeddings and AI models, you probably already know the process with either building embeddings using direct AI integration like in AlloyDB or through application layer and pipelines. Embeddings and direct access to LLM give you options to do classifications, sentiment analysis and many other things.

But what if you want to run these evaluations directly on your operational data without the latency overhead of generative LLMs? In AlloyDB for PostgreSQL, thanks to model endpoint management, we aren’t restricted only to standard generative models. We can connect specialized, ultra-low-latency models designed specifically for high-speed logical constraints — like TypeSafe AI’s Jev model.

By integrating Jev, which is heavily optimized for returning structural evaluations (like booleans and scores) in milliseconds rather than generating conversational text, we can execute high-throughput semantic queries at database speeds using native functions like ai.if and ai.analyze_sentiment.

In this post, I will walk you through a complete setup: configuring the cluster and primary instance, adding secrets, creating the necessary PL/pgSQL translation layers, and leveraging Jev’s parallel batching capabilities to see how fast AI evaluations can be without preparing the embeddings in advance. Let’s dive in.

Adding Jev model to the cluster

If you already have an AlloyDB cluster you can use it right away or you can create one using Google documentation. Make sure you’ve enabled the AI integration following the guide and enabled the following database parameters:

google_ml_integration.enable_model_support=on
google_ml_integration.enable_ai_query_engine=on
google_ml_integration.enable_ai_function_acceleration=on
google_ml_integration.enable_cost_optimized_ai_functions=on

The combination of all those parameters is what makes AlloyDB AI function to be snappy and give the best performance.

Also check your primary instance network settings. We need an outbound public IP to be able to reach the Typesafe AI model endpoint. If your instance doesn’t have it you are going to get timeout trying to reach the model.

If you haven’t already got an API key from https://typesafe.ai/ then you need to register there and generate the key. It will be used to access the model from AlloyDB.

The next step is to add the API key to the Google Cloud secret manager. Here is a simple example how to do that:

gcloud secrets create typesafe-jev-api-key --replication-policy="automatic"
echo -n "<YOUR_TYPESAFE_API_KEY>" | gcloud secrets versions add typesafe-jev-api-key --data-file=-

Now it is time to register the model in your database. You can use any of your databases with a sample dataset to test it out. I was using a database with a sample e-commerce dataset with 30 thousand different products.

In the AlloyDB Studio choose your database and a user who has enough privileges to work with google_ml_integration extension and AI integration functionality. I was doing my tests using ai.if and ai.analyze_sentiment functions with the default model and with the TypeSafe AI’s Jev model.

TypeSafe AI’s System One API accepts structured JSON with distinct reasoning primitives (Noul for boolean constraints, Choice for multi-class classification). You can read about the primitives in the TypeSafe AI’s documentation, but here is a very basic explanation:

You have 3 different question types — Choice, Score or Noul. Depending on the type of the question you get different output. For example, for the type of question Noul you are getting 0 or 1 or, in other words, true or false.

AlloyDB’s standard ai.* functions need to be translated into this specific format. We use four transformation functions to bridge the gap. Here is the scalar input transform that handles Noul and Choice types for both ai.if and ai.analyze_sentiment:

CREATE OR REPLACE FUNCTION public.jev_model_input_transform(
    model_id VARCHAR(100),
    input_text TEXT,
    generation_config JSON,
    system_instruction TEXT
) RETURNS JSON
LANGUAGE plpgsql IMMUTABLE AS $$
DECLARE
    full_instruction TEXT;
    enum_json JSON;
    criteria_obj JSONB := '{}'::JSONB;
    elem TEXT;
    q_obj JSON;
BEGIN
    -- Combine optional system instructions with the input prompt
    IF system_instruction IS NOT NULL AND length(trim(system_instruction)) > 0 THEN
        full_instruction := system_instruction || E'\n\n' || input_text;
    ELSE
        full_instruction := input_text;
    END IF;

    -- Inspect generation_config to determine whether caller expects a multi-class choice or boolean
    enum_json := COALESCE(
        generation_config->'generationConfig'->'responseSchema'->'enum',
        generation_config->'responseSchema'->'enum'
    );

    IF enum_json IS NOT NULL AND json_typeof(enum_json) = 'array' THEN
        -- Multi-class classification (ai.analyze_sentiment) -> Jev choice primitive
        FOR elem IN SELECT json_array_elements_text(enum_json) LOOP
            criteria_obj := criteria_obj || jsonb_build_object(elem, 'Category: ' || elem);
        END LOOP;
        q_obj := json_build_object(
            'type', 'choice',
            'instructions', full_instruction,
            'criteria', criteria_obj::JSON
        );
    ELSE
        -- Boolean filtering (ai.if) -> Jev noul primitive
        q_obj := json_build_object(
            'type', 'noul',
            'instructions', full_instruction
        );
    END IF;

    RETURN json_build_object(
        'model', 'jev-latest',
        'state', COALESCE(generation_config->>'state', 'Evaluate the question accurately based on the provided text.'),
        'questions', json_build_object('q_1', q_obj)
    );
END;
$$;

We also need a scalar output transform to unpack Jev’s JSON response back into a PostgreSQL TEXT result:

CREATE OR REPLACE FUNCTION public.jev_model_output_transform(
    model_id VARCHAR(100),
    response_json JSON
) RETURNS TEXT
LANGUAGE plpgsql IMMUTABLE AS $$
DECLARE
    q_ans JSON := response_json->'answers'->'q_1';
    ans_type TEXT := q_ans->>'type';
BEGIN
    IF ans_type = 'choice' THEN
        RETURN q_ans->>'choice';
    ELSIF ans_type = 'noul' THEN
        -- Convert probability score (0.00 to 1.00) to boolean text
        RETURN CASE WHEN (q_ans->>'noul')::FLOAT >= 0.50 THEN 'true' ELSE 'false' END;
    ELSE
        RAISE EXCEPTION 'Unexpected Jev response payload: %', response_json::TEXT;
    END IF;
END;
$$;

For a batched input and output you should use a modified set of functions which understand input and output as an array of values. All the functions are available in the codelab created by my colleague Paul Ramsey.

Now we bind the transformation functions, secret credential, and the external REST endpoint together:

CALL google_ml.create_model(
    model_id => 'jev-model',
    model_request_url => 'https://api.typesafe.ai/v1/systemone',
    model_provider => 'custom',
    model_type => 'llm',
    model_qualified_name => 'jev-latest',
    model_auth_type => 'secret_manager',
    model_auth_id => 'jev_api_key',
    model_in_transform_fn => 'jev_model_input_transform',
    model_out_transform_fn => 'jev_model_output_transform',
    model_batch_in_transform_fn => 'jev_model_batch_input_transform',
    model_batch_out_transform_fn => 'jev_model_batch_output_transform'
);

You’ve noticed the model is using the Google secret manager as authentication provider with the auth key as the secret name.

Basic Semantic Testing

With jev-model registered, we can execute semantic operations directly inside standard PostgreSQL queries.

First, let’s test a simple boolean constraint using ai.if:

SELECT ai.if(
    prompt => 'Is the product "North Face Waterproof Gore-Tex Hiking Jacket ($249)" suitable for rainy outdoor conditions?',
    model_id => 'jev-model'
) AS is_suitable;

And getting expected result in just few millliseconds:

 is_suitable
-------------
 true
(1 row)

Now, let’s test multi-class classification using ai.analyze_sentiment on a customer review:

SELECT ai.analyze_sentiment(
    input => 'The stitching on this jacket tore on the second day and the zipper jammed completely.',
    model_id => 'jev-model'
) AS sentiment;

And the result in ms:

 sentiment
-----------
 negative
(1 row)

High-Throughput Array Batching on Tables

Usually, executing an HTTP call for thousands of rows row-by-row is painfully slow. However, by using PostgreSQL’s row_number() window function and array batching, we can evaluate dozens of items in a single HTTP round-trip without generative degradation.

Here is an example evaluating a 50-row batch of real catalog items to find cold-weather gear:

EXPLAIN (ANALYZE, BUFFERS)
WITH numbered AS (
    SELECT 
        id, name, category, product_description,
        ((row_number() OVER (ORDER BY id) - 1) / 50) AS batch_id
    FROM ecomm.products
    ORDER BY id DESC
    LIMIT 50
),
batched AS (
    SELECT 
        batch_id,
        array_agg(id ORDER BY id) AS ids,
        array_agg(name ORDER BY id) AS names,
        ai.if(
            prompts => array_agg('Is "' || name || '" designed for cold weather winter outerwear?' ORDER BY id),
            model_id => 'jev-model'
        ) AS decisions
    FROM numbered
    GROUP BY batch_id
),
unrolled AS (
    SELECT 
        b.batch_id, u.id, u.name, u.decision AS cold_weather_gear
    FROM batched b
    CROSS JOIN LATERAL unnest(b.ids, b.names, b.decisions) AS u(id, name, decision)
)
SELECT id, name, cold_weather_gear
FROM unrolled
WHERE cold_weather_gear = TRUE
LIMIT 5;

Here are the results:

  id | name | cold_weather_gear
-------+--------------------------------------------------------------+-------------------
 29071 | Winter Striped Beanie with Pom | true
 29077 | Knit Collegiate Rugby Stripe Winter Scarf & Beanie Hat Set | true
 29083 | Junction Finds Men's Muscle Wool Blend Trapper Hat | true
 29086 | Mens Soft Thermal Insulated Wrist Length Leather Gloves | true
 29090 | Long Beanie-Red W16S24E | true
(5 rows)

And here is the execution plan for the query:

                                                                              QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=6515.00..506515.19 rows=5 width=41) (actual time=369.386..369.391 rows=5.00 loops=1)
   Buffers: shared hit=2479
   -> Nested Loop (cost=6515.00..25006524.75 rows=250 width=41) (actual time=369.385..369.389 rows=5.00 loops=1)
         Buffers: shared hit=2479
         -> GroupAggregate (cost=6514.99..25006516.74 rows=50 width=104) (actual time=369.368..369.370 rows=1.00 loops=1)
               Group Key: numbered.batch_id
               Buffers: shared hit=2479
               -> Sort (cost=6514.99..6515.11 rows=50 width=67) (actual time=17.838..17.840 rows=31.00 loops=1)
                     Sort Key: numbered.batch_id, numbered.id
                     Sort Method: quicksort Memory: 29kB
                     Buffers: shared hit=2440
                     -> Subquery Scan on numbered (cost=6512.95..6513.58 rows=50 width=67) (actual time=17.819..17.826 rows=50.00 loops=1)
                           Buffers: shared hit=2440
                           -> Limit (cost=6512.95..6513.08 rows=50 width=615) (actual time=17.816..17.819 rows=50.00 loops=1)
                                 Buffers: shared hit=2440
                                 -> Sort (cost=6512.95..6585.75 rows=29120 width=615) (actual time=17.815..17.817 rows=50.00 loops=1)
                                       Sort Key: products.id DESC
                                       Sort Method: top-N heapsort Memory: 37kB
                                       Buffers: shared hit=2440
                                       -> WindowAgg (cost=4890.43..5545.61 rows=29120 width=615) (actual time=8.715..14.386 rows=29120.00 loops=1)
                                             Window: w1 AS (ORDER BY products.id ROWS UNBOUNDED PRECEDING)
                                             Storage: Memory Maximum Storage: 17kB
                                             Buffers: shared hit=2440
                                             -> Sort (cost=4890.41..4963.21 rows=29120 width=59) (actual time=8.700..9.204 rows=29120.00 loops=1)
                                                   Sort Key: products.id
                                                   Sort Method: quicksort Memory: 3014kB
                                                   Buffers: shared hit=2440
                                                   -> Seq Scan on products (cost=0.00..2731.20 rows=29120 width=59) (actual time=0.014..3.791 rows=29120.00 loops=1)
                                                         Buffers: shared hit=2440
         -> Function Scan on u (cost=0.01..0.11 rows=5 width=41) (actual time=0.013..0.015 rows=5.00 loops=1)
               Filter: decision
               Rows Removed by Filter: 15

The execution plan shows that PostgreSQL sorts and caps the dataset to 50 rows, aggregates their prompt strings into an array within GroupAggregate, and invokes ai.if once. This consolidates 50 model evaluations into a single network payload — taking ~351 ms — before unnesting and filtering the results, drastically reducing HTTP roundtrips and connection overhead compared to row-by-row execution.

The execution time was consistently around 180 ms. You can compare it with a default model and non-batched approach. My tests for the non-batched approach showed around 5600 ms using the same Jev model and 19500 ms with the default model. So the batching improves performance more than 30 times.

The same approach worked for the ai.analyze_sentiment function where I was taking user’s reviews and passing multiple reviews as arguments to the function capturing the output.

Summary

Comparing the traditional ETL-to-AI pipeline with AlloyDB’s native Model Endpoint Management shows massive improvements in architectural simplicity and performance. It worked really well with incredible speed.

Here are some thoughts after testing the TypeSafe AI’s Jev directly in AlloyDB:

Model Speed: Generative LLMs are relatively slow because they stream text token-by-token. Jev bypasses this entirely, returning structured logical primitives (like noul and score) in milliseconds, making it uniquely suited for synchronous database operations.

Flexibility: You are not locked into one provider. You can securely authenticate with Secret Manager and use custom SQL transforms to adapt standard ai.* functions to any external REST API format.

Database Performance: Using PostgreSQL window functions and array batching maps perfectly to Jev’s parallel API design, allowing you to process dozens of questions simultaneously inside a single HTTP round-trip. The database optimizer combines data before calling the AI model, minimizing overhead.

You can test the presented scenario with an e-commerce dataset using the published codelab and maybe expand your testing comparing the performance and doing sentiment scoring.

Happy testing!

How to Build a Real-Time Voice AI Agent with the Gemini Live API

Annie Cusack — Mon, 28 Sep 2026 22:22:04 +0000

This post was originally posted on X, by Annie Wang, Developer Relations Engineer, Google Cloud and Annie Cusack, Developer Marketing Manager, Google Cloud

Most of us talk to AI assistants throughout our day. When you want to listen to a specific song, you probably just use your voice instead of manually typing on your phone or touching buttons on a speaker.

But there is a big difference between that experience and a live voice agent. It all comes down to a natural conversational dynamic.

For example:
Me: "Hey, Mira, can you play something dream pop?"
Live voice: "That sounds perfect."
Me: [Interrupts] "Skip this one."
Live voice: "Skipping it for you."

That is a live voice agent. It listens, it answers in real time, and you can interrupt it mid-sentence, just like a real phone call. Most AI voice systems can't do this. Here’s how to build an agent that can, using the Gemini Live API.

Text-to-speech vs. Gemini Live (one direction vs. two)

Before we build, it’s helpful to ground ourselves in some context. Most AI assistants today use Text-to-Speech (TTS). TTS is simple in that you give it text and it sends back an audio response. In this case, it can speak, but it can’t “hear you” as a human would.

Gemini Live uses audio-to-audio, which communicates both directions at the same time. It hears your voice as raw audio and speaks back as raw audio. Because it is audio-native, the model can perceive tone, pauses, energy, and inflection. It even starts speaking while it is still forming the answer, instead of waiting for the entire text response to finish.

The Architecture and the Core Loop

To build with the Gemini Live API, there are three pieces you need to connect:

Browser client: Captures your microphone audio and plays a response.
Gemini Live API: The audio-native model that processes live audio, detects speech, and generates voice.
Python backend: A lightweight relay that holds a persistent connection to Gemini and passes audio via the google-genai SDK.

The browser and backend talk over a WebSocket. A normal web request asks once and closes. A WebSocket stays open. That persistent connection allows audio to flow continuously in both directions at the same time.

Step 1: Open the bidirectional WebSocket connection

A standard HTTP request asks once and closes. A live voice call needs an open channel where audio travels both ways simultaneously: streaming your microphone audio to Gemini, and receiving Gemini's voice back down.

Step 2: Implement the 4-Step Core Loop

Once the connection is open, your backend runs two loops at the same time, not one after the other. One pumps microphone audio up to Gemini. The other pulls voice chunks down and plays them. Neither waits for the other to finish. That concurrency is what makes the conversation feel live, and it is what makes interruption possible at all.

Four operations that run continuously:

Step 3: Reduce latency with the barge-in trick

Interruption is the hardest part of the whole build, and it is the part that decides whether the agent feels alive or feels like a phone tree. The problem is that the model can only tell you it has been interrupted after your voice has crossed the network, been processed, and a signal has come back. By then the agent has been talking over you for a few hundred milliseconds, and the illusion is gone.

To make the agent’s response feel like a natural interaction, the model needs to know when you start talking and when you stop. This is called voice activity detection (VAD) and it’s built into Gemini Live.

When the built-in VAD hears you speak while the model is outputting audio, the model halts generation and sends an interrupted signal. Because VAD is handled automatically on the server, your client needs to stream audio even when you are quiet so the model has a steady baseline to catch the exact millisecond you begin speaking.

This same VAD is what powers barge-in, which helps the agent stop instantly the moment someone starts talking over it.

Although, waiting for that signal across the network creates a delay. To make interruption feel truly instant, you need to mute and clear your local playback buffer in the browser the exact millisecond your microphone hears you speak. Do not wait for the server-side interruption signal to travel back across the network. Cut local audio first, and let the model catch up.

Step 4: Add tools to give your agent capabilities

On its own, a voice model can only produce words. It can’t do things like play a playlist, skip a track, or pause music. To give your agent those types of capabilities, you need to attach tools.

A tool is a function in your code with a name, description, and parameters. For example:

play_playlist(genre)
skip_track()
pause_music()

When the model decides an action is required, it outputs a tool call containing the parameters it extracted from your voice. Your backend code executes the function and reports the result back.

But voice interactions have a strict constraint: Slow tool = silent agent.

While a tool is running, the model pauses voice generation to wait for the result. If a tool takes three seconds to complete an external API request, your agent stops talking, which creates an awkward pause.

To keep the conversation flowing, implement the asynchronous fire-and-acknowledge pattern:

When a tool like play_playlist is triggered, dispatch the slow playback action asynchronously.
Immediately return an instant confirmation code or receipt (e.g., {"status": "success"}) back to the model.
The model receives the instant success receipt and continues talking seamlessly (i.e. "Skipping it for you"), while the actual music begins playing in the background.

Dive into the code and try for yourself

Building a real-time voice agent with the raw Gemini Live API unlocks low-latency, audio-native capabilities that standard chained TTS pipelines can’t replicate, and it helps you create voice agents that interact in a natural, conversational way.

See the full code and run the demo yourself. Find the complete implementation for Mira, our late-night radio DJ voice agent, in this GitHub repository.

7 ways to lock down AI agent sandboxes in production (beyond Docker containers)

Praveen Rajasekar — Mon, 28 Sep 2026 22:17:28 +0000

Running an autonomous coding or ops agent directly on your laptop feels like a superpower for the first few minutes. It reads your local repository, runs bash commands in your terminal, and fixes a failing test while you grab a drink.

Then reality sets in. A hallucinated shell command wipes a local folder, a dependency script hangs your machine, or an indirect prompt injection hidden inside a GitHub issue quietly reads your ~/.ssh keys and cloud credentials. And simply wrapping the agent in a standard docker run container does not solve it: standard containers share your host machine's operating system kernel, inherit whatever API keys you pass into them, and cannot stop a tricked process from leaking data.

If you are moving autonomous agents off your laptops into production cloud environments, here are 7 practical ways to lock down your agent sandboxes:

1. Use real kernel isolation (gVisor or microVMs), not standard Docker. Standard Docker containers isolate processes on the surface, but every container shares the underlying host operating system kernel. If an agent runs untrusted code that triggers a kernel bug, it can break out onto the host server.

In production, choose between two stronger isolation options based on your workload:

User-space kernel sandboxes (gVisor): Used by Cloud Run and GKE Sandbox. gVisor acts like a security checkpoint proxy between the container and the host OS, inspecting every file and network request before it ever touches the real hardware. It starts in milliseconds and works with normal container images, though tasks that create thousands of tiny files (like npm install or large git checkouts) run slightly slower because the proxy inspects every single file operation.
Lightweight microVMs (Firecracker / KVM): Instead of inspecting requests through a proxy, a microVM uses hardware virtualization to boot a tiny, separate Linux kernel for each agent in about 125 milliseconds. Pick microVMs (or Compute Engine Confidential VMs) when your agent needs full sudo/root permissions or runs heavy builds. If you just need a managed sandbox to run model-generated Python or bash scripts without managing servers, use the Gemini Enterprise Code Execution Sandbox.

2. Keep raw API keys and secrets outside the sandbox. A common mistake is grabbing a temporary 10-minute token from a secret manager and passing it into the agent's container as an environment variable (process.env). To a prompt-injected agent, 10 minutes is an eternity, a single curl command can steal and send that key to an external server in 200 milliseconds. Never put real credentials inside the container. Keep your keys stored safely in Google Cloud Secret Manager, and route the agent's outbound API calls through an external gateway proxy like Apigee AI Gateway. The gateway authenticates the agent via IAM Workload Identity and attaches the real API key on the way out only when the agent is calling an approved destination URL.

3. Lock down outbound network access across every step. Recent security audits of cloud coding agents found two common blind spots:

Setup script leak: Many platforms block internet access while the agent is reasoning, but leave the internet wide open during the initial npm install or pip install setup step, allowing a malicious package script in a repository to steal data before the agent even starts working.
Bash only trap: Sandboxing the bash terminal tool while letting file-reading tools, browser tools, or MCP servers run unrestricted on the host machine. Block outbound internet access by default across the entire lifecycle (VPC Service Controls and egress firewall rules). Pull code packages from a private, pre-scanned cache (Artifact Registry) instead of the open web, and only allow the sandbox to talk to an explicit list of approved domains.

4. Track cumulative actions across turns, not just single tool calls. Pre-execution hooks (like Antigravity PreToolUse hooks and ADK 2.0 tool callbacks) are essential for checking one command at a time, such as blocking rm -rf or enforcing a $50 limit on a refund tool. But single-step rules have no memory. As Google Cloud's engineering team recently demonstrated, a tricked agent will bypass a $50 limit simply by calling issue_refund($20) six times in a loop to drain $120. Pair single-step parameter checks with session-level budgets and anomaly detection at the gateway (Model Armor) so your system tracks the total impact across the whole conversation and stops the loop when behavior drifts off course.

5. Run file edits in isolated workspaces and protect CI/test files. If a coding agent can edit its own unit tests or CI/CD pipeline files (.github/workflows, cloudbuild.yaml, .git/hooks), it might "pass" a failing test simply by deleting the test assertion or slip a command into the build config that runs outside the sandbox when a human reviews the pull request. Give the agent an isolated copy of the workspace (like the isolated git worktrees in Google Antigravity), mount your test suites and CI configuration folders as read-only, and automatically block any pull request where the agent tried to modify build pipelines or security rules.

6. Avoid paying for idle compute while waiting on the LLM. An AI agent uses compute very differently than a normal web server. During a 10-minute debugging session, the sandbox might use 100% CPU for 2 seconds to run a test, and then sit 70% to 85% of the time doing nothing while waiting for the LLM to stream tokens back or waiting for human approval (Upstash 2026 Sandbox Benchmark). If you run agent sandboxes on standard 24/7 virtual machines, you pay 5x for idle CPU and memory. Use serverless runtimes with active-CPU billing like Cloud Run, where you pay for CPU only during the seconds a command is actively running and save session progress externally in Gemini Enterprise Agent Platform Sessions so idle sandboxes can shut down between turns.

7. Send audit logs outside the sandbox in real time. If you store your execution logs inside the same container where the agent has terminal access, a crashed container or a rogue command can wipe the logs before you ever see them. Stream your telemetry directly from the outside host into Cloud Trace and Cloud Audit Logs as the agent runs. For every turn, record four simple things under a single run ID:
1) what the agent asked to do,
2) whether your security rules allowed or blocked it,
3) what files or network URLs were actually touched, and
4) confirmation that the temporary container and its permissions were wiped clean when the task finished.

We shouldn't let probabilistic agents run unquarantined on our laptops or shared kernel containers. Isolate the kernel with gVisor or microVMs, keep real API keys outside the container, lock down setup-script internet access, and enforce budgets across the entire multi-turn loop.

How are you isolating your AI agents in production today? gVisor, microVMs, or external gateway proxies? Let's discuss in the comments below!

Claude Sonnet 5.5 is now available on Google Cloud

Jen Harvey — Mon, 28 Sep 2026 18:53:36 +0000

Designed for coding and knowledge work, it helps you build features, and create clean work materials quicker with a lower cost-per-task at faster speed.

👉 Try it today: [https://console.cloud.google.com/agent-platform/publishers/anthropic/model-garden/claude-sonnet-5-5]

Claude on Google Cloud workshop | NYC | 9/30

Jen Harvey — Fri, 25 Sep 2026 11:50:46 +0000

On Wednesday, September 30, Anthropic and Google Cloud are co-hosting a hands-on developer workshop in New York City. It runs from 8:30am to 12:30pm at the Google office, and is designed for engineers and technical leaders who want to get past evaluating AI coding tools and into actually using them.

The morning covers Claude Code and Claude Desktop on Google Cloud. Most of the time is spent in a hands-on lab session, and participants leave with a working setup. Anthropic and Google Cloud engineers will be on-site throughout to answer technical questions.

During the session, you will have the opportunity to:

See how Claude fits into your existing workflows across the software development lifecycle
Learn best practices around integrating Claude into your Google Cloud environment
Understand how to build on your existing security and compliance requirements
Work through guided labs with Anthropic and Google Cloud experts available throughout
Walk away with a working setup

RSVP today

Inline vs. Separate Tables for Vectors in Postgres: Measuring the Join Overhead

Gleb Otochkin — Fri, 25 Sep 2026 04:29:18 +0000

Testing semantic search, filtered queries, and multi-table joins in AlloyDB to measure the true cost of decoupling your vectors.

Introduction

If you are working with vector embeddings you probably already know the embedding models are evolving and you need to refresh your embeddings with a new version from time to time. In the last post we discussed the bloating problem in the tables, TOAST segments and indexes related to the embeddings refresh. As an alternative to storing embeddings in the same table with your data I proposed a different layout where the embeddings would be placed in a dedicated table. In this post I show what performance impact it might have in comparison with storing embeddings in the same table.

How I tested it

To test queries I needed sample data with real embeddings. The reasons were explained in one of my previous posts — it could have a visible impact on results when an ANN index is used. I prepared a dataset with 30k rows of sample products, built embeddings on product descriptions, and used them to fill a dedicated embedding table. For all my tests I was using an AlloyDB Omni database. It was coming with AI integration out of the box and that helped me to build the embeddings, vector indexes, and generate search embeddings by converting search phrases to the vector variables.

Here are the tables used in my tests:

-- ecomm.products table

demodb=# \d ecomm.products
                              Table "ecomm.products"
         Column | Type | Collation | Nullable | Default
------------------------+------------------------+-----------+----------+---------
 id | bigint | | not null |
 cost | numeric | | |
 category | character varying(255) | | |
 name | character varying(255) | | |
 brand | character varying(255) | | |
 retail_price | numeric | | |
 department | character varying(255) | | |
 sku | character varying(255) | | |
 distribution_center_id | bigint | | |
 product_description | text | | |
 product_image_uri | text | | |
 embedding | vector(768) | | |
Indexes:
    "products_pkey" PRIMARY KEY, btree (id)
    "fk_products_distribution_center_23" btree (distribution_center_id)
    "idx_products_brand" btree (brand)
    "idx_products_category" btree (category)
    "idx_products_retail_price" btree (retail_price)
    "idx_products_sku" btree (sku)
    "idx_products_vector" hnsw (embedding vector_cosine_ops)
Foreign-key constraints:
    "fk_products_distribution_center" FOREIGN KEY (distribution_center_id) REFERENCES ecomm.distribution_centers(id)
Referenced by:
    TABLE "ecomm.inventory_items" CONSTRAINT "fk_inventory_items_product" FOREIGN KEY (product_id) REFERENCES ecomm.products(id)
    TABLE "ecomm.order_items" CONSTRAINT "fk_order_items_product" FOREIGN KEY (product_id) REFERENCES ecomm.products(id)
    TABLE "ecomm.product_reviews" CONSTRAINT "fk_reviews_product" FOREIGN KEY (product_id) REFERENCES ecomm.products(id) ON DELETE CASCADE

-- ecomm.product_embeddings table
demodb=# \d ecomm.product_embeddings
             Table "ecomm.product_embeddings"
   Column | Type | Collation | Nullable | Default
------------+-------------+-----------+----------+---------
 product_id | bigint | | not null |
 embedding | vector(768) | | not null |
Indexes:
    "product_embeddings_pkey" PRIMARY KEY, btree (product_id)
    "idx_product_embeddings_vector" hnsw (embedding vector_cosine_ops)

-- ecomm.inventory_items table 
demodb=# \d ecomm.inventory_items
                                 Table "ecomm.inventory_items"
             Column | Type | Collation | Nullable | Default
--------------------------------+-----------------------------+-----------+----------+---------
 id | bigint | | not null |
 product_id | bigint | | |
 created_at | timestamp without time zone | | |
 sold_at | timestamp without time zone | | |
 cost | numeric | | |
 product_category | character varying(255) | | |
 product_name | character varying(255) | | |
 product_brand | character varying(255) | | |
 product_retail_price | numeric | | |
 product_department | character varying(255) | | |
 product_sku | character varying(255) | | |
 product_distribution_center_id | bigint | | |
Indexes:
    "inventory_items_pkey" PRIMARY KEY, btree (id)
    "fk_inventory_items_distribution_center_8" btree (product_distribution_center_id)
    "fk_inventory_items_product_7" btree (product_id)
Foreign-key constraints:
    "fk_inventory_items_distribution_center" FOREIGN KEY (product_distribution_center_id) REFERENCES ecomm.distribution_centers(id)
    "fk_inventory_items_product" FOREIGN KEY (product_id) REFERENCES ecomm.products(id)
Referenced by:
    TABLE "ecomm.order_items" CONSTRAINT "fk_order_items_inventory_item" FOREIGN KEY (inventory_item_id) REFERENCES ecomm.inventory_items(id)

-- ecomm.product_reviews table
demodb=# \d ecomm.product_reviews
                                Table "ecomm.product_reviews"
   Column | Type | Collation | Nullable | Default
-------------+--------------------------+-----------+----------+------------------------------
 id | bigint | | not null | generated always as identity
 user_id | bigint | | not null |
 product_id | bigint | | not null |
 rating | integer | | not null |
 review_text | text | | not null |
 created_at | timestamp with time zone | | not null | CURRENT_TIMESTAMP
Indexes:
    "product_reviews_pkey" PRIMARY KEY, btree (id)
    "idx_product_reviews_created_at" btree (created_at DESC)
    "idx_product_reviews_product_id" btree (product_id)
    "idx_product_reviews_user_id" btree (user_id)
Check constraints:
    "product_reviews_rating_check" CHECK (rating >= 1 AND rating <= 5)
Foreign-key constraints:
    "fk_reviews_product" FOREIGN KEY (product_id) REFERENCES ecomm.products(id) ON DELETE CASCADE
    "fk_reviews_user" FOREIGN KEY (user_id) REFERENCES ecomm.users(id) ON DELETE CASCADE

The ecomm.products and ecomm.product_embeddings are connected by the primary key and both tables have HNSW index built on top of the embedding vectors.

Test products semantic search

I started the tests from a simple case with a cosine semantic search using only the products table and then comparing it with the join of the products and product_embeddings table. For the search I converted a phrase ‘lightweight waterproof high quality jacket’ to a vector embedding and passed it as test_vec variable. That removed the unpredictable model response time and allowed me to compare the query execution times more precisely.

-- Set the test_vec variable in psql
SELECT (google_ml.embedding(
    model_id => 'text-embedding-005',
    content => 'lightweight waterproof high quality jacket'
)::public.vector(768))::text AS test_vec \gset

In the same psql session I ran the search with EXPLAIN ANALYZE to see the execution plan and timings. Every test was repeated multiple times.

-- Embeddings in ecomm.products
EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    p.id,
    p.name,
    p.brand,
    p.retail_price
FROM ecomm.products p
ORDER BY (p.embedding <=> :'test_vec'::public.vector(768))
LIMIT 10;

Here is the execution plan for “inline” embeddings vector search:

 Limit (cost=1213.90..1240.56 rows=10 width=86) (actual time=1.112..1.200 rows=10.00 loops=1)
   Buffers: shared hit=792
   -> Index Scan using idx_products_vector on products p (cost=1213.90..78826.40 rows=29120 width=86) (actual time=1.110..1.197 rows=10.00 loops=1)
         Order By: (embedding <=> '[-0.01255631,...,-0.008388235]'::vector(768))
         Index Searches: 1
         Buffers: shared hit=792
 Planning:
   Buffers: shared hit=1
 Planning Time: 0.107 ms
 Execution Time: 1.224 ms

From the plan it was visible the query was using the HNSW index to search through the embeddings and order them by similarity. The response time in total to return the results was around 2.1 ms. The response time was bigger than the pure execution time from the execution plan because it added overhead like planning, network time and client software time to show the results.

Then I put embeddings to the ecomm.product_embeddings table and did the same search:

-- Embeddings in ecomm.product_embeddings
EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    p.id,
    p.name,
    p.brand,
    p.retail_price
FROM ecomm.product_embeddings pe
JOIN ecomm.products p ON p.id = pe.product_id
ORDER BY (pe.embedding <=> :'test_vec'::public.vector(768))
LIMIT 10;

Here is the execution plan with join of products and product_embeddings tables using primary keys:

 Limit (cost=219.82..250.39 rows=10 width=86) (actual time=1.188..1.351 rows=10.00 loops=1)
   Buffers: shared hit=852
   -> Nested Loop (cost=219.82..89223.27 rows=29120 width=86) (actual time=1.187..1.348 rows=10.00 loops=1)
         Buffers: shared hit=852
         -> Index Scan using idx_product_embeddings_vector on product_embeddings pe (cost=219.53..59613.60 rows=29120 width=26) (actual time=1.126..1.141 rows=10.00 loops=1)
               Order By: (embedding <=> '[-0.01255631,...,-0.008388235]'::vector(768))
               Index Searches: 1
               Buffers: shared hit=752
         -> Index Scan using products_pkey on products p (cost=0.29..1.01 rows=1 width=78) (actual time=0.007..0.007 rows=1.00 loops=10)
               Index Cond: (id = pe.product_id)
               Index Searches: 10
               Buffers: shared hit=50
 Planning:
   Buffers: shared hit=21
 Planning Time: 0.274 ms
 Execution Time: 1.381 ms

I was getting top 10 vectors using the HNSW index on ecomm.product_embeddings and joining that with the ecomm.products table using the primary key. The execution time was consistently around 2.2 ms. Yes, the execution plan is a bit more complicated but the execution itself is taking only 0.1 ms longer. When I increased limit from the top 10 to top 1000 it increased the response time only by around 0.3 ms. PostgreSQL joins with primary keys are fast.

Filtered semantic search

In real life we rarely see queries using only one search condition. In most cases it involves additional parameters. I tested it adding filter on category and retail_price columns:

-- With two filters and embeddings in ecomm.products
EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    p.id,
    p.name,
    p.brand,
    p.retail_price,
    p.category
FROM ecomm.products p
WHERE p.category = 'Outerwear & Coats'
  AND p.retail_price BETWEEN 30 AND 150
ORDER BY (p.embedding <=> :'test_vec'::public.vector(768))
LIMIT 10;

The execution plan had changed adding the filter on results:

 Limit (cost=1213.90..1760.50 rows=10 width=97) (actual time=6.353..6.522 rows=10.00 loops=1)
   Buffers: shared hit=817
   -> Index Scan using idx_products_vector on products p (cost=1213.90..78829.95 rows=1420 width=97) (actual time=6.342..6.509 rows=10.00 loops=1)
         Order By: (embedding <=> '[-0.01255631,...,-0.008388235]'::vector(768))
         Filter: ((retail_price >= '30'::numeric) AND (retail_price <= '150'::numeric) AND ((category)::text = 'Outerwear & Coats'::text))
         Rows Removed by Filter: 7
         Index Searches: 1
         Buffers: shared hit=799
 Planning:
   Buffers: shared hit=1
 Planning Time: 0.157 ms
 Execution Time: 1.308 ms

The response time was consistently around 2.2 ms — almost the same as without the filter.

Then I executed it with embeddings in a separate table:

EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    p.id,
    p.name,
    p.brand,
    p.retail_price,
    p.category
FROM ecomm.product_embeddings pe
JOIN ecomm.products p ON p.id = pe.product_id
WHERE p.category = 'Outerwear & Coats'
  AND p.retail_price BETWEEN 30 AND 150
ORDER BY (pe.embedding <=> :'test_vec'::public.vector(768))
LIMIT 10;

I got one extra step with the filter in the execution plan:

 Limit (cost=219.82..1346.89 rows=10 width=97) (actual time=1.167..1.370 rows=10.00 loops=1)
   Buffers: shared hit=894
   -> Nested Loop (cost=219.82..89370.85 rows=791 width=97) (actual time=1.166..1.367 rows=10.00 loops=1)
         Buffers: shared hit=894
         -> Index Scan using idx_product_embeddings_vector on product_embeddings pe (cost=219.53..59613.60 rows=29120 width=26) (actual time=1.110..1.153 rows=17.00 loops=1)
               Order By: (embedding <=> '[-0.01255631,...,-0.008388235]'::vector(768))
               Index Searches: 1
               Buffers: shared hit=759
         -> Index Scan using products_pkey on products p (cost=0.29..1.02 rows=1 width=89) (actual time=0.006..0.006 rows=0.59 loops=17)
               Index Cond: (id = pe.product_id)
               Filter: ((retail_price >= '30'::numeric) AND (retail_price <= '150'::numeric) AND ((category)::text = 'Outerwear & Coats'::text))
               Rows Removed by Filter: 0
               Index Searches: 17
               Buffers: shared hit=85
 Planning:
   Buffers: shared hit=21
 Planning Time: 0.347 ms
 Execution Time: 1.406 ms

The response time for the query was all the time between 2.3 and 2.4 ms. Again it was slower than the query with embeddings in the same table but the difference was not significant.

Multi-tables join

If you have a data schema where different parts and attributes of your business information are stored in different tables you use joins of multiple tables to get what you need. For tests I used a join with ecomm.product_reviews with aggregations for product ratings.

EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    top.id,
    top.name,
    top.brand,
    top.retail_price,
    top.category,
    top.dist,
    COUNT(pr.id) AS review_count,
    COALESCE(ROUND(AVG(pr.rating), 2), 0) AS avg_rating
FROM (
    SELECT 
        p.id,
        p.name,
        p.brand,
        p.retail_price,
        p.category,
        (p.embedding <=> :'test_vec'::public.vector(768)) AS dist
    FROM ecomm.products p
    WHERE p.category = 'Outerwear & Coats'
      AND p.retail_price BETWEEN 30 AND 150
    ORDER BY (p.embedding <=> :'test_vec'::public.vector(768))
    LIMIT 10
) top
LEFT JOIN ecomm.product_reviews pr ON pr.product_id = top.id
GROUP BY top.id, top.name, top.brand, top.retail_price, top.category, top.dist
ORDER BY top.dist;

The query was consistently returning results in 2.6–2.7 ms. Then I modified the query to use embeddings stored in the ecomm.product_embeddings table:

EXPLAIN (ANALYZE, BUFFERS)
SELECT 
    top.id,
    top.name,
    top.brand,
    top.retail_price,
    top.category,
    top.dist,
    COUNT(pr.id) AS review_count,
    COALESCE(ROUND(AVG(pr.rating), 2), 0) AS avg_rating
FROM (
    SELECT 
        p.id,
        p.name,
        p.brand,
        p.retail_price,
        p.category,
        (pe.embedding <=> :'test_vec'::public.vector(768)) AS dist
    FROM ecomm.product_embeddings pe
    JOIN ecomm.products p ON p.id = pe.product_id
    WHERE p.category = 'Outerwear & Coats'
      AND p.retail_price BETWEEN 30 AND 150
    ORDER BY (pe.embedding <=> :'test_vec'::public.vector(768))
    LIMIT 10
) top
LEFT JOIN ecomm.product_reviews pr ON pr.product_id = top.id
GROUP BY top.id, top.name, top.brand, top.retail_price, top.category, top.dist
ORDER BY top.dist;

The difference was again about 0.2 ms. The second query was returning results in 2.8–2.9 ms. I am skipping the individual execution plans for this case — they are longer and more difficult to read in a short blog post like this one, but here is a comparison diagram:

For the second query I had an extra join for our product_embeddings and products tables (which was expected), but apart from that it showed the similar execution path.

Summary

Here is summary table with the test results:

+--------------------------+-----------------------+-----------------------+---------------------+
| Test Scenario | Inline Embeddings | Dedicated Table | Overhead / Delta |
+--------------------------+-----------------------+-----------------------+---------------------+
| 1. Pure Semantic Search | Execution: ~1.22 ms | Execution: ~1.38 ms | +0.16 ms (Exec) |
| (LIMIT 10) | Total: ~2.10 ms | Total: ~2.20 ms | +0.10 ms (Total) |
+--------------------------+-----------------------+-----------------------+---------------------+
| 2. Filtered Search | Execution: ~1.31 ms | Execution: ~1.41 ms | +0.10 ms (Exec) |
| (Category + Price) | Total: ~2.20 ms | Total: 2.3 - 2.4 ms | +0.10 - 0.20 ms |
+--------------------------+-----------------------+-----------------------+---------------------+
| 3. Multi-Table Join | | | |
| (Reviews Aggregation) | Total: 2.6 - 2.7 ms | Total: 2.8 - 2.9 ms | +0.20 ms (Total) |
+--------------------------+-----------------------+-----------------------+---------------------+

Comparing queries performance for embeddings stored in the table along with the source data and in the decoupled dedicated table showed relatively minor difference in performance. In most of the cases response time didn’t exceed 0.2 ms. Of course it might be different depending on table structures, data and individual queries.

I would recommend testing and considering the layout with dedicated embedding tables. It might help you in the future models maintenance and model evaluations when you just add another table with your future model and run your queries using the newly generated embeddings. With a good schema design the overhead potentially can be minimal. In my experience other factors like the model response time introduces much more variations to the response time than a join with an embedding table based on primary keys.

Equip your agent with Google Cloud best practices using google-cloud-developer plugin

Remigiusz Samborski — Thu, 24 Sep 2026 11:55:12 +0000

Coding agents in your terminal can scaffold microservices in seconds. But what happens when your agent needs to deploy directly to Google Cloud?

Without cloud-specific guidance, typical agents struggle. They hallucinate obsolete SDK calls, attempt to run commands without required permissions, or silently enable billable APIs that create surprise costs on your invoice.

The google-cloud-developer plugin changes this dynamic. It equips your agent (such as Antigravity CLI, Claude Code, Codex CLI) with curated skills and the Developer Knowledge MCP server.

To evaluate the plugin in action, I tasked Antigravity CLI (agy) with building a complete, cloud-based solution from a fresh Google Cloud project. The scenario: scaffold, containerize, and deploy a secure Gemini API streaming proxy on Cloud Run, complete with Cloud IAM authentication and Firestore token tracking.

While the resulting Cloud Run proxy codebase works, the proxy itself is just an example. The real value is how the plugin guides the agent through every phase of the cloud development process:

Application design and SDK code generation: Writing Gemini SDK code without hallucinations and selecting the right database.
Project onboarding, billing verification, and API enablement: Auditing the project, linking a Cloud Billing account, and requesting explicit user approval before enabling billable APIs.
Least-privilege IAM and Cloud Run deployment: Provisioning dedicated service accounts and deploying the container asynchronously.
End-to-end verification: Testing streaming and token persistence against the live service.

Quick install: Five skills and an MCP server

Remember the scene in The Matrix where Trinity calls Tank for a helicopter pilot program and learns it in seconds? Adding the plugin to agy works the same way with one terminal command:

agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer

The CLI clones the plugin repository, registers its components, and makes them available immediately.

In seconds, agy configures:

Five specialized skills covering Google Cloud CLI patterns and workflows.
Developer Knowledge MCP server providing access to current API syntax and Google Cloud documentation.

With the plugin active, agy pairs its Gemini 3.8 Flash model with authoritative cloud instructions.

Note: As a heavy user of Google Cloud, I already have gcloud installed and authenticated. I also enabled the Developer Knowledge API in my project. For new users and ones who use a different harness such as Claude Code CLI or Codex CLI, I recommend following the official documentation to get started.

Knowledge grounding: Writing modern SDK code without hallucinations

One frequent failure mode with AI coding assistants is API obsolescence. For example, older tutorials rely on deprecated libraries such as google-generativeai.

Because the google-cloud-developer plugin connects directly to the Developer Knowledge API, the agent checks the latest official syntax before writing a single line of code.

When scaffolding app/gemini_client.py, agy immediately used the current unified Google Gen AI SDK:

The agent produced clean Python code with Pydantic configuration, structured Cloud Logging formatters, and unit tests using pytest and FastAPI's TestClient.

Informed architecture: Evaluating database options with Developer Knowledge

Selecting the right database for a serverless proxy requires balancing latency, connection handling, concurrency, and cost. When I asked agy to track token usage per user and suggest the best database, the agent did not just pick one at random.

Backed by the Developer Knowledge API, the agent pulled real-time architectural guidance and evaluated Google Cloud database options:

By grounding its analysis in the Developer Knowledge, the agent presented a clear comparison table directly in the terminal. It recommended Cloud Firestore as the most cost-effective and operationally simple fit for Cloud Run. You get an informed architectural decision based on official cloud patterns rather than guessing.

Cost guardrails and onboarding: Verifying billing before enabling APIs

Once the code and Firestore design were ready, the agent needed to enable the Gemini Enterprise, Cloud Run, and Firestore APIs in my project. Autonomous agents need strict boundaries here, because enabling an API or provisioning a managed resource can incur costs.

Two skills in the google-cloud-developer plugin coordinate this step:

Pre-flight billing audit: Before enabling billable services, the google-cloud-recipe-onboarding skill instructs the agent to verify that the target project is linked to an active Cloud Billing account (gcloud billing projects describe).
Explicit user consent: The gcloud skill requires explicit user approval before running gcloud services enable or any destructive action.

When agy identified the required APIs for the proxy, it first checked my project state and paused for explicit permission:

The system's guardrails require explicit user approval before enabling any API, specifically addressing potential security risks and unexpected costs.

This keeps you in the driver's seat and eliminates accidental spend.

How `agy` helps: Scheduling timers for billing propagation

During the onboarding skill's pre-flight check, I linked a new billing account to my test project so agy could enable the APIs. In Google Cloud, linking a billing account often takes a few minutes to propagate across backend systems.

While the google-cloud-developer plugin tells the agent how to validate billing status (gcloud billing projects describe checking for billingEnabled: true), agy complements the plugin with its native Schedule tool so the session does not fail or spin in a retry loop.

I typed:

"Ok. Let's wait now. I just enabled the billing and it needs to propagate. I'll check in 10 minutes."

The agent scheduled a 600-second timer and freed the terminal prompt:

Exactly 10 minutes later, the timer woke the agent up. It resumed the exact conversation context, checked the billing status with gcloud beta billing projects describe, verified that billingEnabled was true, and prompted to enable the required APIs:

You can walk away, grab a coffee, and let your agent resume right where you left off.

Security enforcement: Least-privilege IAM

With the APIs enabled, the next step before deployment was configuring authentication. Without guidance, agents often suggest creating a long-lived Gemini API key or downloading a service account JSON key file.

Instead, the google-cloud-recipe-auth skill explicitly forbids downloaded service account keys and steers the agent toward Google Cloud security best practices:

Dedicated service identity: Creates a workload-specific service account (gemini-proxy-sa).
Least-privilege IAM bindings: Grants only roles/aiplatform.user for Gemini invocation and roles/datastore.user for Firestore token logging.
Authenticated ingress: Protects the Cloud Run endpoint with --no-allow-unauthenticated so the Google Frontend validates Google-signed OpenID Connect (OIDC) ID tokens before traffic reaches your container.

No secrets live in plaintext, and permissions stay tightly scoped.

Cloud Run deployment

To deploy the container, agy used finding-google-skills to pull Cloud Run deployment patterns (cloud-run-basics) from the remote skill catalog and combined them with the gcloud skill's command formatting rules:

gcloud run deploy gemini-38-flash-proxy \
  --source . \
  --region=us-central1 \
  --service-account=gemini-proxy-sa@[PROJECT_ID].iam.gserviceaccount.com

How `agy` helps: Running long tasks in the background

Building a container image from source still takes a few minutes. agy helps by launching the deployment as a background task instead of locking up your interactive session:

Notice the task status bar in the terminal: [14:12:41] gcloud run deploy gemini-38-flash-proxy ... running (1 task(s) · /tasks)

You can continue chatting with the agent, ask questions, or inspect background jobs with /tasks while Cloud Build compiles your container image.

Live verification: Streaming and per-user token persistence

Once the background deployment completed, agy generated test commands to verify the end-to-end flow.

Calling the usage endpoint with an authenticated identity token:

curl -s -X GET https://gemini-38-flash-proxy-[PROJECT_NUMBER].us-central1.run.app/v1/users/me/usage \
  -H "Authorization: Bearer $(gcloud auth print-identity-token)"

Returns real-time Firestore persistence data:

{
  "user_id": "[EMAIL]",
  "total_input_tokens": 14,
  "total_output_tokens": 41,
  "total_tokens": 55,
  "last_active": "2026-09-21T12:21:21.567000+00:00",
  "models.gemini-3_8-flash.input_tokens": 14,
  "models.gemini-3_8-flash.output_tokens": 41,
  "models.gemini-3_8-flash.total_tokens": 55
}

Atomic increments in Firestore record prompt and completion token counts across requests, giving you immediate visibility into user consumption.

Summary

Pairing agy with the google-cloud-developer plugin creates a safer, smarter CLI workflow:

Knowledge grounding: Developer Knowledge API prevents outdated SDK hallucinations and ensures accurate code generation.
Human in the loop: Built-in skill guardrails require explicit permission before running commands that can incur cloud costs.
Non-blocking workflow: Scheduled timers handle asynchronous cloud operations, while background tasks let long builds run without freezing your prompt.
Enterprise security defaults: Encourages least-privilege service accounts and IAM authentication over hardcoded secrets.

Next steps

Check out more resources on google-cloud-developer plugin:

Connect with me

I am always eager to share what I've learned and hear how fellow developers and AI enthusiasts use Antigravity and Google Cloud. If you found this article helpful, feel free to share it and follow me on your favorite social platform:

Thanks for reading!

Claude Opus 5.5 is now available on Google Cloud

Jen Harvey — Tue, 22 Sep 2026 17:48:24 +0000

Everyday complex tasks? No problem. Opus 5.5 handles long-running coding and knowledge work while keeping you in the loop along the way, all at a lower price per token. Get started in Model Garden today!

DEV Community: Google AI

Claude Haiku 5.5 is available on Google Cloud

stop-using-complex-urls-for-your-demos.us-central1.run.app

Activating Your Data Layer for Production-Ready AI

Semantic Search: Text Embeddings in Database

Go to the lab!

Go to the labs!

Multimodal Embeddings: Bring Images to the Search

Go to the lab!

AlloyDB AI Functions and Reranking

Go to the lab!

Generate SQL using QueryData for AlloyDB

Go to the lab!

From Tests to Production

Stop "Vibe Checking" Your AI Agents: How to Build Production Evals in 60 Minutes

What We Cover in the Video

Jump Directly to Key Sections

Open-Source Repositories & Resources

Sub-second semantic filtering in PostgreSQL: Integrating the ultra-fast Jev model with AlloyDB

Introduction

Adding Jev model to the cluster

Basic Semantic Testing

High-Throughput Array Batching on Tables

Summary

How to Build a Real-Time Voice AI Agent with the Gemini Live API

Text-to-speech vs. Gemini Live (one direction vs. two)

The Architecture and the Core Loop

Step 1: Open the bidirectional WebSocket connection

Step 2: Implement the 4-Step Core Loop

Step 3: Reduce latency with the barge-in trick

Step 4: Add tools to give your agent capabilities

Dive into the code and try for yourself

7 ways to lock down AI agent sandboxes in production (beyond Docker containers)

Claude Sonnet 5.5 is now available on Google Cloud

Claude on Google Cloud workshop | NYC | 9/30

Inline vs. Separate Tables for Vectors in Postgres: Measuring the Join Overhead

Introduction

How I tested it

Test products semantic search

Filtered semantic search

Multi-tables join

Summary

Equip your agent with Google Cloud best practices using google-cloud-developer plugin

Quick install: Five skills and an MCP server

Knowledge grounding: Writing modern SDK code without hallucinations

Informed architecture: Evaluating database options with Developer Knowledge

Cost guardrails and onboarding: Verifying billing before enabling APIs

How agy helps: Scheduling timers for billing propagation

Security enforcement: Least-privilege IAM

Cloud Run deployment

How agy helps: Running long tasks in the background

Live verification: Streaming and per-user token persistence

Summary

Next steps

Connect with me

Claude Opus 5.5 is now available on Google Cloud

How `agy` helps: Scheduling timers for billing propagation

How `agy` helps: Running long tasks in the background