DEV Community: Google AI

Designing AI Evals: Clarity Now and Visualization Next

Katie McLaughlin — Tue, 18 Aug 2026 07:00:00 +0000

AI evals and analysis

Let's say you're testing out new AI tools. Perhaps you implement and run analytics for an Ad Agency and hope to automate deploying your standard event schema, or are a podcast producer automating generating social copy from your newest ep. While modern, newly trained LLMs can likely one-shot a lot of these tasks – this specificity might necessitate wasting tokens and time repeatedly prompting them with the same resources, descriptions and scripts. With this in mind, you investigate tooling whether that be an MCP server, an agent skill or an agent plugin.

The problem is, how do you know if a skill (whether developed by you or open sourced by someone else) is worth your time or, perhaps more importantly, your tokens and quota? How can one go about designing these (more) objective evaluations of AI tools and, from there, collecting and analyzing relevant metrics? That is exactly the context for using open source eval frameworks, like Inspect AI and Harbor to evaluate agent skills using open source frameworks. But how do you "extend the evaluation", use visualizations to spot trends and collaboratively explore alternative paths forward using Google Sheets and Data Studio?

These questions and more are exactly what I’m hoping to demonstrate for you in this series!

While you are more than welcome to simply read about how and why I conducted my own investigation, you can alternatively follow my lead and run the benchmark scripts.

So, if you’re hoping to play along, take a moment to complete the aforementioned codelab and come back when you’re done. Don’t worry, we’ll still be here when you get back!

Note: This blog series contains AI-generated diagrams
alongside actual screenshots and hand-drawn edits of
both. AI also assisted in minor copy editing.

Level up your evals

In the codelab, we learned how to run evals with Gemini CLI, Inspect and Inspect SWE in an isolated Docker Sandbox to understand how well each skill aids the agent in answering the same question.

For those playing along at home, please additionally install inspect view now before you need it to run the evals below; be prepared to have to wait for a couple minutes for evals to finish depending on your machine and quota usage.

Regarding our new source files while they are heavily commented and hopefully written in a self describing way, I’ll explain further subsequently.

A note on models

For the purpose of my investigation demo, I used three different models: google/gemini-3.5-flash-lite and google/gemini-3.6-flash as "solvers" (the models under evaluation), and google/gemini-3.1-flash-lite as a "grader" (the model rating the runs). The three of them (and models more broadly) differ in many ways but more specifically on problem solving ability, speed and cost.

We intentionally offloaded grading for this demo to a previous-generation model because by changing rubric criteria to strict binary decisions and applying a reduction programmatically, it delivers sufficiently robust evaluations without burning through solver quota. For a production evaluation system, consider investigating using newer and more capable models as graders because they will likely have narrower confidence intervals.

For a full technical breakdown of this decoupled grader architecture and to find out how you could substitute in your own choice of models, see the README section on Decoupled Grader & Multidimensional Rubrics.

Setting up the eval

Reproducibility & Local Setup Note: If you are following along locally, clone the domain skill definitions into google-skills/ before running benchmark sweeps:

git clone https://github.com/google/skills.git google-skills

All evaluations in this series were benchmarked on Python 3.13 using inspect-ai (v0.3.247), inspect-swe (v0.2.66), inspect-viz (v0.4.1), and pandas (v3.0.3). If upstream PyPI releases introduce breaking changes, check the README's Environment & Dependencies specification for exact version pins and instructions on how to reproduce the configuration.

For this investigation I used a new eval script; while the specifics of the script are important for anyone who hopes to make their own evals or run the code as we go, if you're primarily interested in analysis and visualization, feel free to skip to the next section.

The original script ran a small batch of tests on a local machine. While this version can be and was run on a local machine, it prioritizes three architectural dimensions needed for running automated tests as part of a larger scale development flow:

External Configs (providing the evals and solver system prompt as external files for separation of concerns).
Quota Management (for the GenAI API and package management).
Multidimensional Evaluations (expanding to arbitrary fact counts for graders).

For a complete technical breakdown of these architectural pillars—including external configuration schemas (questions.json, thrifty_system_prompt.txt), solver rate-limiting defenses (version="0.51.0" pinning), grader quota decoupling, and score curving math formulas see the README's Evaluation Pipeline Architecture & Technical Reference.

Running the eval

These commands create a matrix of evals subject to model x skill condition x sample x epoch. For a quick visual (that I’ll repeatedly reference throughout this), take a look below.

Caption: Visualization of the eval matrix that will be scored and compared. In Inspect AI, rubric elements, represented here as Facts, are graded Correct (C) or Incorrect (I).

With all that said, it’s finally time for the rubber to meet the road. I ran our evals with the following command

inspect eval skills-eval.py \
  --model google/gemini-3.5-flash-lite,google/gemini-3.6-flash \
  --time-limit 300 \
  --epochs 2 \
  --max-tasks 4 \
  -T web_access=false

This command runs a 4-way parallel sweep across models and skill conditions while enforcing a 300-second task timeout and disabling web search to minimize token spend. See the README for a complete CLI Parameter Reference and details on External Configuration Template Mechanics.

Run and wait

If you intend to and haven't done so already, run the command line. If you're interested in how to read over and interact with the Terminal User Interface, please refer to the previous codelab.

Watch the running command line long enough to determine it hasn’t crashed or hit an obvious error and then maybe take a moment to make some food, grab some water or take a walk around the block. Enjoy the small things in life, okay? Worst case, you get a 20 minute walk out of it, not so bad eh!?

Viewing the evals

With that said and done, reading the terminal output is only the most basic way of understanding the evals. Now that you have the raw eval logs, what do you need to do to begin to use these analytically and, more importantly, persuasively?

To start off, I simply ran

inspect view

and clicked the link to open the browser to the GUI.

For step-by-step diagnostic trace analysis in the browser GUI, see the README section on Local Diagnostic Trace Analysis (inspect view).

Mine came out like this (after a little bit of column drag-and-drop):

While we covered the rudiments of looking over the inspect view GUI in Evaluate agent skills using open source frameworks, there is significantly more that can be done with it. Speaking of which, the TASK ARGS column (not pictured) serves as a quick reference for what arguments were passed to a task.

Macro view: Comparing runs

While LLM’s are inherently stochastic (and given floating point hardware, nondeterministic), when running evals we are trying to use sampling to characterize the average observable metrics (e.g. correctness, latency and token usage) which our particular configuration model x skill scores on relevant questions. As such, the eval tasks were set up to characterize how a change to an independent variable (model or skill) affect dependent variables (the aforementioned metrics).

A. Comparing models head to head

Grouping evaluation runs by model in inspect view allows for a direct "eyeball" inspection of how skill inclusion alters accuracy across baseline controls—given a specific model, what is the impact of adding a skill?

I have added some annotations to make metric change from baseline to skilled a little more apparent:

The above shows that

In all cases, the addition of a skill improved or tied scores relative to the same model’s baseline.
All of these cases also increased duration

Another simple measurement that can be done is to look at the TOKENS column where gemini-api actually led to a decrease in usage relative to its baseline in 3.6-flash.

While the general relationship between tokens and score is difficult to parse visually, one notable result: for 3 out of 4 task x model configurations, gemini-3.6-flash used more tokens than the comparable 3.5-flash-lite run.

B. Comparing skill conditions (skill vs. baseline)

Now to analyze the inverse; in more concrete terms: given a particular skill, what is the effect of changing the underlying model?

What was the effect of the change from 3.5-flash-lite to 3.6-flash?

For 3 out of 4 of these, the changes between the two models amounted to an up to 45% increase in accuracy. For whatever reason, however, changing the gcloud skill from using one model to another led to a slight decrease.

While these are both valuable findings, they warrant further questions:

Are these representative samples?
If these findings are repeatable, how can we characterize the relationship between the existing metrics?

For the first of those, if you want to make more representative samples, know that you should conduct further research using more questions, samples and epochs and compare those metrics with these. For the sake of this blog series though, I’ll leave that for you to do.

For the second though, we can and will endeavor to do so. That said, it might help in designing follow up analysis to think a little bit about common patterns encountered during evals. This is especially true for those running evals themselves (possibly on different skills or rubrics); you are likely to encounter very different metrics than mine, and thus I’ll lay out some common patterns and follow up actions to investigate them further.

Mental models for eval comparison (skill vs. baseline)

When analyzing evaluation runs, comparing skilled execution against baseline controls typically maps to five distinct diagnostic outcomes—ranging from High-Efficiency Capability Lift (best) to Context Overload & Skill Regression (worst).

For a complete breakdown of this diagnostic taxonomy and actionable audit steps for each outcome, see the README breakdown of Diagnostic Mental Models for Eval Comparison.

Micro view: Sample-level diagnostics

While high-level metric summaries alert you to outcomes like cost bloat or skill regression, opening an individual sample surfaces the Sample Details panel for granular trace analysis:

Transcript tab: How to read the LLM's conversation as it happened

This tab shows the exact multi-turn conversation between the solver agent, the sandbox shell, and external tools. Use it to diagnose model reasoning versus environment noise:

System Prompt Verification: Confirm that web search rules (-T web_access=false) and automated time limits (300 seconds) were correctly injected into the container environment.

Skill Ingestion Check: Verify whether the agent activated the skill. If activation didn’t occur, your eval is mostly testing baseline model knowledge rather than skill utility.

Here is an example of one case where the skill was activated.

This means: The agent actually ingested gemini-api instead of relying on baseline pre-training memory.

Of note though, some of the tasks where skills were made available did NOT activate the skill. If you’re a skill author, you may want to rewrite the “activation criteria” (aka what situation calls for using the skill) such that it's more applicable to the specifics of relevant tasks.

Errors and reasoning loops

Auditing transcript details allows you to distinguish model reasoning loops (e.g., repeated redundant tool calls) from sandbox environment noise (e.g., container timeouts or missing binary dependencies). For step-by-step diagnostic trace auditing procedures, see the README reference on Sandbox Noise vs. Model Reasoning.

Scoring tab: Multi-fact verification breakdown

Clicking the Scoring Tab displays the empirical breakdown of our custom multi_scorer on a sample:

The multi_scorer aggregates the results of checking the sample’s answer against individual binary yes/no Facts using model_graded_qa. The generated list of scores in the range [0.0, 1.0] is supplied to our custom_reducer which calculates their arithmetic mean. From there, it applies quadratic score curving ( $mean^{2}$ ) to ensure that the further from correct the mean of the supplied answers are, the lower the score is pulled. This allows the most correct answers to stand out immediately. In the Scoring Tab, this downward curve maps a raw 5/6 fact score ( $\approx 0.8333$ ) down to a normalized 0.65 sample score. For complete formulas and math derivations, see the README section on Atomic Fact Verification & Quadratic Curving.

Visual milestone: The transition to cohort analytics

While inspect view provides outstanding deep-dive diagnostics for individual sample traces, evaluating dozens of models across multiple skill domains gets confusing fast (as you may have seen above). Weighing the correlations between skill inclusion vs exclusion and model changes against each other can be confounding and more art than science if we don’t find better ways to reason over them; it requires a structured matrix overview.

Remember that mess of sectors of a 3d space I showed you earlier representing all the configs? Well, unless we find numeric ways to collapse that or quantify deeper comparison, you won’t get the granular information you need to choose between two similarly capable alternatives. Worse yet, you won’t be able to communicate this to the people with their hands at the purse strings (unless of course, that's you too).

To make this easier, next time we’ll start down the road of understanding and displaying these things visually: As visualized in the cohort matrix linked above, understanding agent capability factor-by-factor requires cohort slicing across multi-dimensional metrics.

In Part 2, we scale our analysis from single log UI inspection to aggregate scoreboards with inspect viz!

How I Planned an Italy Trip with an Agentic Workflow

Karl Weinmeister — Mon, 17 Aug 2026 16:12:46 +0000

The stunning village of Positano in the Amalfi Coast of Italy

I’ve been known to use tech everywhere, even where it’s not really needed. But I have to say, AI agents really came in handy for my last trip. I want to share my story, and the playbook I used for an unforgettable trip.

This summer, my wife and I celebrated an anniversary milestone in Italy. The trip was 10 days long, spread across 3 cities: Positano in the Amalfi Coast, Naples, and Rome. We had a wonderful time, and the planning certainly helped!

Let’s break down the agentic workflow I used. I’ll cover the initial brainstorming phase, travel logistics, itinerary planning, and finally the checklist for feeling confident about it all.

Getting started with Deep Research

Before drafting a single day on a calendar, every great trip begins with an exploratory phase. Before I even touched an agent, I had fun scrolling through plenty of Reddit threads (r/ItalyTravel) and reading articles.

At a certain point, you’re going to run into information overload. How can you distill all of these great ideas into what you need to do? Enter Gemini Notebook.

The first thing I did was use Deep Research to scour across data sources. I now had a chat interface where I could ask all kinds of questions.

One of the features that made Gemini Notebook famous was the Audio Overview (or podcast) feature. You can tune into two hosts discussing your favorite topic at convenience. But there’s much more you can create, like flashcards, quizzes, and reports. It even can create infographics like this:

Architecting the itinerary

With a base of understanding in place, our next step was to shape our trip. What were the key places to see? How many days should we spend in each city?

A great trip should be looked at as just a checklist of sights. The flow needs to take into account the timing, geography, and your energy levels. August is generally a hot season in Italy, and Italy’s major cities were on the highest heat alert in 2026.

We asked Gemini to consider these nuances:

Act as an expert travel logistics architect. Design a 10-day itinerary for 2 adults starting at Rome FCO, traveling to Positano, Naples, and Rome. Group activities by neighborhood, factor in August heat, and minimize backtracking.

The model surfaced tactical adjustments that generic guides might overlook For example, it recommended Herculaneum over Pompeii for a blistering hot day: both world-class sites nearby Naples, but Herculaneum would fit better with some mobility challenges we were working through. Gemini sequenced the days around key events, filling in with a full itinerary:

From there, Antigravity integrated with Google Calendar, so I had everything I needed at a glance on my phone. Gemini flagged that some of the attractions sold out quickly, so I added reminders such as signing up for the Colosseum 30 days before.

Transit Logistics

One of the most stressful parts of international travel is stitching together connections. On arrival day, our route required landing at Rome FCO, taking an express airport train, catching high-speed rail, and meeting a driver.

Instead of guessing connection times, I asked Gemini to calculate realistic buffers and analyze ticket flexibility rules:

Analyze transit options from Rome FCO Airport to Positano on a Tuesday morning. Calculate conservative buffers for passport control, baggage claim, and station transfers. Provide fallback options for flight delays.

One of the great features in Antigravity is the Browser agent, which can open up Chrome and operate it for you. Antigravity accessed the Trenitalia website to search for connections:

It made a sensible set of recommendations. It even went deep into the policies of the tickets to uncover that the tickets are valid for a 4-hour window. That helped us pick an earlier ticket just in case we arrived early, without being worried about missing our connection.

On our way back from Amalfi to Naples, we took a ferry. Aggregator websites like Ferryhopper can make finding the right ferry easier. Even then, it wasn’t totally clear why some ferries might take an hour vs others that would take two hours. Gemini was very helpful in researching what extra stops were being made.

Feeling confident

The ultimate test of travel planning is stepping onto the plane feeling fully prepared and organized. Gemini helped with a checklist to ensure we had everything in order: power adapters, international phone coverage, and much more.

The checklist, along with all of our travel information, was stored in a structured markdown file. I could access it at any time from a Google doc, due to its Google Docs Markdown support.

To enable this feature, turn on Markdown under Tools > Preferences in Google Docs, then upload your .md file or right-click to paste formatted text.

Also, once you created this doc in the Google Docs mobile app, tap the document options menu and select “Make available offline”.

This creates a clean, clickable travel hub that stays fully responsive on your phone, even in airplane mode or underground metro tunnels.

A panoramic shot of the ancient Colosseum in Rome

Your travel planning playbook

AI agents are most useful when they work for you, going beyond surface-level recommendations in a prompt.

To recap this workflow for your next journey, follow this four-part playbook:

Perform deep research and ingest docs into Gemini Notebook to brainstorm on your plan.
Personalize your journey with your unique preferences and any constraints.
Direct Antigravity to make travel arrangements using its Browser agent, synced to your calendar.
Export your main Markdown file into an offline Google Doc that is accessible anywhere.

Do you have any stories to tell about travel planning with AI? I’d love to hear about them on X, LinkedIn, or Bluesky.

Behind the scenes: How we build, test, and scale Google Agent Skills

Remigiusz Samborski — Mon, 03 Aug 2026 14:33:20 +0000

AI agents are only as good as the instructions and context you give them. When we launched Google Agent Skills, our goal was simple: encode Google Cloud domain knowledge into structured, open-source instructions that make AI coding agents significantly smarter, safer, and more accurate.

Today, I want to take you behind the scenes of Google Agent Skills. As a team member working directly on these skills, I will share how we started, how we maintain quality at scale, and how we handle governance for public and internal skills.

How it started: The Next'26 kickoff swarm

The Google Agent Skills project didn't start in a vacuum. It kicked off as a fast-paced "swarm" effort leading up to Google Cloud Next 2026.

A cross-functional task force led by Developer Advocates and Technical Writers came together with a clear goal: package Google Cloud domain knowledge into structured, agent-readable instructions.

The launch was announced in the official Google Agent Skills launch post. The initial community reception exceeded our expectations with over 15,000 GitHub stars!

Once developers and engineering teams inside and outside Google saw how effectively skills guided AI agents (reducing hallucinations and enforcing best practices), many wanted in. Soon, a wave of product teams wanted to contribute skills for their own Google services (not limited to Cloud, i.e. Ads).

The challenge: Scaling without losing quality

Popularity brings a major challenge: quality control.

When different teams contribute skills, keeping a consistent standard becomes tough. A poorly written skill with vague instructions, broken links, or missing edge cases degrades the entire agent experience.

To enable teams to publish skills while protecting the developer experience, we had to set a very high bar.

This meant the process was critical. Without clear standards and automated governance, an open-source skills repository quickly becomes chaotic.

So let's dive into details of how we maintain quality as we scale.

The anatomy of an Agent Skill

To keep skills consistent across many Google services, every skill follows a standardized repository layout:

{skill-name}/
├── SKILL.md                 # Required: Main instructions & frontmatter metadata
├── OWNERS                   # Required: Skill maintainers (kept internal)
├── EVAL.yaml                # Required: Evaluation prompt suites & rubrics (kept internal)
├── reference/               # Optional: In-depth technical docs & schemas
├── scripts/                 # Optional: Executable helper scripts
├── assets/                  # Optional: Static resources & diagrams
└── _internal/               # Optional: Test mocks & internal data (kept internal)

Architectural best practice: Prefer remote MCP tools

When designing skills, our guiding principle is: Reference remote Model Context Protocol (MCP) tools whenever possible, falling back to CLI or API calls only when necessary. Remote MCP servers are best suited for Agentic workloads by providing tools, while also offering built-in auth and IAM governance.

Public export

We build and evaluate our skills internally first to make sure they work and are properly validated. Once ready to go public, we use automated export rules to publish to GitHub. This keeps public repos clean while stripping out internal assets, ownership information, and evaluation suites.

Automated checks on check-in

Before any skill enters the repository, it must pass an automated CI/CD pipeline:

Linters: We validate frontmatter metadata, line counts, directory layout, and strict naming conventions.
Link Checkers: We test every URL using link-checking tools to eliminate 404s and hallucinated links before merge. Hint: if you're building a similar solution I recommend trying out lychee.
AI-Assisted Checklists: We use automated validation checks to verify that instructions follow required structural patterns and guardrails.

Example GitHub Action for skill linting

While our development relies on Google's internal tooling, public open-source skill repositories can use standard GitHub Actions for CI/CD.

If you are maintaining your own skill library on GitHub, linting is part of a larger check suite to keep a high quality bar. The following GitHub Action configuration demonstrates how to automatically run skill validation in your repository using skills-ref:

name: 'Validate Skills'

on:
  push:
    branches: ['main']
  pull_request:
    branches: ['main']
  workflow_dispatch:

defaults:
  run:
    shell: 'bash'

jobs:
  validate:
    runs-on: 'ubuntu-latest'
    permissions:
      contents: 'read'
    steps:
      - name: 'Checkout repository'
        uses: 'actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5' # ratchet:actions/checkout@v4

      - name: 'Set up Python'
        uses: 'actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065' # ratchet:actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: 'Install skills-ref'
        run: |
          python3 -m pip install skills-ref
          echo "$HOME/.local/bin" >> $GITHUB_PATH

      - name: 'Validate skills'
        run: |
          shopt -s nullglob
          for skill_dir in skills/*/; do
            echo "Validating skill: $skill_dir"
            agentskills validate "$skill_dir"
          done

Continuous evals (on submit & weekly)

Documentation and APIs evolve, and so do LLM models and agent harnesses. A skill that works today might break tomorrow if an underlying API, model, or agent harness changes.

To set an initial quality bar and prevent degradation, we run continuous evaluations:

On-submit evaluations: Authors must provide explicit evaluation prompt suites and scoring rubrics. Every new skill that we launch is first evaluated internally to ensure its accuracy and efficiency.
Weekly quality checks: We run continuous, scheduled evaluation jobs against the full skill library to catch regressions early.

Skill authors must supply multiple evaluation test cases, each containing a prompt and a set of expectations. With each evaluation suite, we compare the performance of agents with and without each skill.

And look at two main dimensions:

Accuracy - response quality and task completion rate
Efficiency - number of consumed tokens and time for completion

Moreover we run our evals multiple times against different agent frameworks to obtain statistically significant results.

Finally the 2x2 matrix proves whether a skill delivers a measurable accuracy and efficiency uplift.

Skills are products, not snippets

A key lesson learned from our work is that a skill is a living product, not a one-off document.

To ensure long-term reliability, we established strict ownership rules:

Repo maintainers oversee repository health, CI pipelines, and architectural standards.
Skill owners are responsible for maintaining their skills long-term. For example, if a product API changes, the skill owner updates the skill. The same applies to quality degradation found during evaluation runs.

Supporting authors: Tools and agentic workflows

Writing effective instructions and evaluation suites requires practice and we don't expect skill authors to craft everything from scratch.

To support our contributors, we built several tools and agentic workflows:

Internal skills designed specifically to assist authors building new skills and writing robust evaluations.
Agentic tools built with the ADK that run multi-agent loops for authoring and self-critique, with an easy export path to the main repository.

I will dive deeper into these authoring tools and agentic workflows in future articles.

Internal efficiency with "DevRel Skills"

While Google Agent Skills hosts public skills for external developers, we also launched a parallel internal initiative called DevRel Skills.

DevRel Skills focus on building agent skills specifically for internal team workflows. By encoding internal processes — such as content transformation, SEO optimization, internal reporting, etc. - into dedicated skills, we help our team work more effectively and consistently every day.

Wrap-up and over to you

Building quality agent skills at scale requires combining clear standards, rigorous evaluation, automated CI/CD, and long-term ownership.

As agentic development grows, we'd love to hear from you:

How are you building and testing agent skills in your workflow?
What checks or evals do you use to verify agent responses?

Let us know in the comments or reach out on socials!

Links and further reading

To get started with Google Agent Skills, check out:

Google Agent Skills Repo: github.com/google/skills
Part 1: Introduction: What Are Google Cloud Agent Skills?
Part 2: Practical Guide: Intermediate Agent Skills in Action

What's next?

If you found this post helpful:

Add reactions to this post by pressing the heart ❤️ button.
Share this post with your friends on socials.
Connect with me via LinkedIn, X or Bluesky.

Thanks for reading!

Skills vs MCP: How AI tools have evolved

Tilde A. Thurium — Thu, 30 Jul 2026 17:50:23 +0000

Eighteen months ago, MCP was the thing. Every demo and chatbot connector was running on MCP under the hood. When I started seeing everyone talk about Skills, I got curious. How are MCP and Skills connected? Are they different lenses on the same problem?

I brought these questions to @greggyb again in our latest video.

What's in the video

What MCP actually does: giving a model programmatic access to APIs and the file system through natural language
Downsides of MCP: context bloat from loading hundreds of lines of tool definitions for tools you're not even using
What a Skill actually is (spoiler: pretty much a markdown file containing a reusable prompt)
Progressive disclosure: why an agent can "know about" 20 skills without loading the full instructions for all of them
Why MCP and Skills aren't competitors, and how Skills can even teach your agent how to use MCP tools

My favorite line from this one: the hottest programming language right now is English. Skills let non-developers write, iterate on, and share instructions that make an entire team's agents faster, no code required.

Are you using Skills yet? Curious where everyone's at.

7 Times Faster and Cheaper? Gemini 3.5 Flash Lite and Gemini 3.6 Flash in Google Cloud Databases

Gleb Otochkin — Sun, 26 Jul 2026 06:11:17 +0000

Only a couple of months ago, I wrote a blog post describing how to enable the latest (at the time) Gemini 3.5 Flash in Google Cloud databases. Now, it is time to introduce the newest model: Gemini 3.6 Flash. This model is fresher, with a knowledge cutoff date around the end of March this year, and it costs less. Let’s look at how it performs at first glance. I am particularly curious about its response times and how it compares to the previous model.

Cloud SQL

For Cloud SQL for Postgres, don’t forget to enable full AI integration via the google_ml extension to call modelsdirectly from a SQL query. If you are reading this AI integration overview right after the model announcement, you might need to register the model first. It wasn’t available by default when I tested it.

Here is the SQL statement to register the model. Don’t forget to replace the PROJECT_ID placeholder in the code with your actual Google Cloud project ID:

CALL google_ml.create_model(
    model_id => 'gemini-3.6-flash',
    model_request_url => 'https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent',
    model_provider => 'google',
    model_type => 'generic',
    model_auth_type => 'cloudsql_service_agent_iam'
);

After that, your model is ready to be used:

SELECT google_ml.predict_row(
    model_id => 'gemini-3.6-flash',
    request_body => json_build_object(
        'contents', json_build_array(
            json_build_object(
                'role', 'user',
                'parts', json_build_array(
                    json_build_object('text', 'Explain MCP server for a relational database in 50 words or less.')
                )
            )
        )
    )
) ->'candidates' -> 0 -> 'content' -> 'parts' -> 0 -> 'text' AS ai_response;

To measure the latency, I’ve asked Google Antigravity to prepare a PL/pgSQL function to run that query a certain number of times and aggregate the results. It did a decent job, I needed only a few polishing and adjustments to make it working. Here are my benchmarking results for Gemini 3.6 Flash and Gemini 3.5 Flash:

quickstart_db=> SELECT * FROM benchmark_model_predictions('gemini-3.6-flash', 10);
 total_runs | avg_latency_ms | median_latency_ms | min_latency_ms | max_latency_ms 
------------+----------------+-------------------+----------------+----------------
         10 | 3694.53 | 3725.52 | 3313.01 | 4213.40
(1 row)

Time: 36947.554 ms (00:36.948)
quickstart_db=> SELECT * FROM benchmark_model_predictions('gemini-3.5-flash', 10);
 total_runs | avg_latency_ms | median_latency_ms | min_latency_ms | max_latency_ms 
------------+----------------+-------------------+----------------+----------------
         10 | 4918.86 | 5136.67 | 3936.69 | 5722.01
(1 row)

Time: 49190.861 ms (00:49.191)

It looks like, all other conditions being equal, Gemini 3.6 Flash was slightly faster than the previous model. Of course, this is a very crude measurement, and your results may vary. Since we are using a global endpoint, the routing might theoretically hit different regional endpoints. Furthermore, public model endpoints are shared services.

Next, I created a function to evaluate the quality of the responses and ran it for both models. The function uses the same query, receives the response, and sends the result to a more advanced model for evaluation. In this case, I used gemini-3.1-pro-preview as the judge:

quickstart_db=> SELECT * FROM benchmark_model_quality('gemini-3.6-flash', 'gemini-3.1-pro-preview', 5);
 total_runs | avg_quality_score | median_quality_score | min_quality_score | max_quality_score 
------------+-------------------+----------------------+-------------------+-------------------
          5 | 10.00 | 10.00 | 10 | 10
(1 row)

quickstart_db=> SELECT * FROM benchmark_model_quality('gemini-3.5-flash', 'gemini-3.1-pro-preview', 5);
 total_runs | avg_quality_score | median_quality_score | min_quality_score | max_quality_score 
------------+-------------------+----------------------+-------------------+-------------------
          5 | 9.80 | 10.00 | 9 | 10
(1 row)

quickstart_db=>

Both models delivered excellent results, but Gemini 3.6 Flash provided slightly better responses than its predecessor — at least according to the gemini-3.1-pro-preview judge.

What about AlloyDB? Let’s run the same performance benchmark on AlloyDB to see if the response times match our Cloud SQL results.

AlloyDB

Registering the new model in AlloyDB follows almost the same process, with the only difference being the ‘model_type’ parameter. In AlloyDB, we register it with the model type ‘llm’. Again, don’t forget to replace the PROJECT_ID placeholder with your actual project:

CALL google_ml.create_model(
model_id => 'gemini-3.6-flash',
model_request_url => 'https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent',
model_provider => 'google',
model_type => 'llm'
);

For these tests, I used the exact same query and function as we did for Cloud SQL. AlloyDB is fully compatible with PostgreSQL and shares the same AI integration extension.

quickstart_db=> SELECT * FROM benchmark_model_predictions('gemini-3.5-flash', 10);
 total_runs | avg_latency_ms | median_latency_ms | min_latency_ms | max_latency_ms
------------+----------------+-------------------+----------------+----------------
         10 | 4899.00 | 4910.05 | 3631.22 | 5798.40
(1 row)

Time: 48992.149 ms (00:48.992)
quickstart_db=> SELECT * FROM benchmark_model_predictions('gemini-3.6-flash', 10);
 total_runs | avg_latency_ms | median_latency_ms | min_latency_ms | max_latency_ms
------------+----------------+-------------------+----------------+----------------
         10 | 4364.76 | 4368.65 | 3664.24 | 5008.42
(1 row)

Time: 43649.384 ms (00:43.649)
quickstart_db=>

This time, the results were much closer, and the response times were almost identical. It is hard to draw definitive conclusions here, considering we are using a shared service with global routing; there is no guarantee that consecutive requests are hitting the same physical endpoint. However, it appears that performance and response times are roughly equivalent for both models. Naturally, the quality of the responses remained consistent with our previous test, as quality depends directly on the models themselves.

Gemini 3.5 Flash Lite

But do you always need a “Pro” or “Flash” model for your queries? In many cases, you can get highly acceptable results from a “Lite” model like the newly released gemini-3.5-flash-lite. I tested its performance using the same benchmarking approach:

quickstart_db=> SELECT * FROM benchmark_model_predictions('gemini-3.5-flash-lite', 10);
 total_runs | avg_latency_ms | median_latency_ms | min_latency_ms | max_latency_ms
------------+----------------+-------------------+----------------+----------------
         10 | 827.08 | 882.05 | 499.95 | 1034.92
(1 row)

Time: 8272.929 ms (00:08.273)

It was about seven times faster than Gemini 3.6 Flash. But what about response quality?

quickstart_db=> SELECT * FROM benchmark_model_quality('gemini-3.5-flash-lite', 'gemini-3.1-pro-preview', 5);
 total_runs | avg_quality_score | median_quality_score | min_quality_score | max_quality_score
------------+-------------------+----------------------+-------------------+-------------------
          5 | 10.00 | 10.00 | 10 | 10
(1 row)

Time: 42923.480 ms (00:42.923)
quickstart_db=> SELECT * FROM benchmark_model_quality('gemini-3.5-flash-lite', 'gemini-3.1-pro-preview', 5);
 total_runs | avg_quality_score | median_quality_score | min_quality_score | max_quality_score
------------+-------------------+----------------------+-------------------+-------------------
          5 | 9.60 | 10.00 | 8 | 10
(1 row)

Time: 51722.997 ms (00:51.723)
quickstart_db=> SELECT * FROM benchmark_model_quality('gemini-3.5-flash-lite', 'gemini-3.1-pro-preview', 5);
 total_runs | avg_quality_score | median_quality_score | min_quality_score | max_quality_score
------------+-------------------+----------------------+-------------------+-------------------
          5 | 9.80 | 10.00 | 9 | 10
(1 row)

Time: 53252.325 ms (00:53.252)

I ran the same benchmark three times, and even the worst-performing run was highly scored. The average scores ranged from 9.6 to 10 (with 10 being a perfect score). I was impressed by both the quality and the speed.

Summary

The new Gemini 3.6 Flash model is less expensive than Gemini 3.5 Flash. Considering it offers comparable or better quality and the same or faster response times, it is definitely a win.

However, Gemini 3.5 Flash Lite is maybe even more impressive, delivering excellent quality while running seven times faster at a very attractive price. This means that many simpler, everyday tasks can be delegated to the Lite model to keep costs down, reserving more advanced models for complex problems that require deep reasoning and multi-step iterations.

AI builder essentials: tokens, context windows and RAG 101

Tilde A. Thurium — Fri, 24 Jul 2026 19:16:22 +0000

Tokens are an important foundational concept that underlie how we interact with LLMs. @greggyb and myself recorded a quick video to demystify what a token actually is and unpack several other related concepts.

What's in the video

What is a token? Tokens are the basic unit of input and output that LLMs operate on.
What is retrieval-augmented generation (AKA RAG)? Providing a model with extra data that isn't already in the model's training dataset, and is relevant to a specific query.
What are context windows? Context windows are how many tokens a model can use for input and output. Context window size varies from model to model, but it has increased a lot in recent years.
What is tokenmaxxing? Does using more tokens really mean you're being more productive? (Spoiler alert: no.)

To paint a bigger picture: more context you give a large language model, the better your responses are likely to be. The design patterns for providing that context have evolved at a rapid pace, and are likely to continue doing so.

What AI terms should we demystify next? Let us know!

Claude Opus 5 is Live on Agent Platform 🚀

Jen Harvey — Fri, 24 Jul 2026 17:37:35 +0000

Claude 5 Opus is officially available in the Model Garden on Agent Platform!

Built for highly complex, long-running agentic workflows, Claude 5 Opus brings advanced capabilities in coding, vision, and deep reasoning - allowing businesses to deploy next-generation AI agents with minimal oversight.

Using Claude 5 Opus on Agent Platform keeps your data inside your private Google Cloud network, controls access with IAM, and ensures your data is never used for model training. Built with high-security enterprise environments in mind, it is alsoZero Data Retention (ZDR) compatible.

Find it in the Agent Platform Model Garden 🌱

Investing in multi-agent AI safety research

Gemini Team — Fri, 24 Jul 2026 14:35:41 +0000

Scaling AI Safety Research for a Multi-Agent World

For the past decade, we've focused on making individual AI models more capable, helpful and safe. Now, Google DeepMind — together with Schmidt Sciences, the Cooperative AI Foundation, the Advanced Research and Invention Agency, and supported by Google.org — has announced a new technical research funding call of up to $10M for researchers worldwide.

As AI technology scales, we're entering a new era. Soon, millions of AI agents — built by different organizations — will interact across digital environments, communicating, negotiating and transacting with one another.

When these systems interact, they must do so safely and predictably. This shift creates a vital opportunity: we can strengthen the safety and stability of the entire AI ecosystem from the very beginning.

The funding call focuses on the study of how large-scale multi-agent AI systems behave as a group, and how we can provide frameworks to understand and mitigate against potential risks. By empowering researchers globally, we aim to solve the "invisible" safety risks that arise when independent systems interact across different networks.

Why the agent ecosystem matters

When large groups of AI agents interact, new collective behaviors and capabilities can emerge suddenly. Currently, we lack the tools to predict, measure and monitor these transitions. Most safety evaluations analyze models in isolation. However, as we and others have previously argued, interacting autonomous agents can produce complex, "emergent" behaviors that are difficult to anticipate.

Because this is a new area of research, it is critical to understand how these shifts occur. For example, could they cause an unpredictable flurry of economic activity or lead to new security challenges? Understanding how to manage these system-wide behaviors is our core objective.

Scaling the frontier of multi-agent safety research

Although foundational frameworks for multi-agent safety exist, the rapid evolution of these systems requires an immediate, large-scale expansion of research.

Our 2025 research established a framework for understanding these interactions, while our recent work on AI Agent Traps explores vulnerabilities agents face in adversarial environments. Now, we must move faster. We are at a critical juncture where the complexity of multi-agent interactions is outpacing existing safety models.

This funding call aims to accelerate progress by supporting a global network of independent researchers. A diverse community is essential to ensure safety standards are transparent and robust for everyone.

This effort also advances the mission of Schmidt Sciences' Science of Trustworthy AI and AI Agents programs, which support foundational work on understanding and mitigating risks from frontier AI systems, as well as ARIA's Scaling Trust programme, which seeks to unlock new forms of cyber-physical multi-agent coordination.

A collaborative call to action

No single lab can solve multi-agent safety alone. We invite academic and independent researchers to submit proposals in four priority areas:

Sandboxes and testbeds: Building realistic, reproducible environments to evaluate, compare and accelerate progress across all areas of multi-agent safety. This includes virtual marketplaces, simulated ecosystems and multi-organisation workflows.
The science of agent networks: Understanding the safety-relevant properties of interacting agent populations, including investigating how collective capabilities emerge and scale, how networks fail or become volatile and how to detect dangerous, unexpected population-level properties.
Strengthening agent infrastructure: Stress-testing the protocols for identity, reputation and commitment that are secure cross-platform agent interactions.
Oversight and control: Developing methods to monitor deployed agent populations and mitigate collective harms at scale.

How to participate

We invite researchers to review our call for proposals and join us in building a safe foundation for a multi-agent future.

The deadline to apply is August 8, 2026, with awardees expected to be announced in Autumn 2026.

For more details on technical requirements and the application process, visit our application portal.

Google Cloud Skills Tutorial — Part 2 : Intermediate Skills in Action

Romin Irani — Fri, 24 Jul 2026 00:57:29 +0000

Welcome to the definitive guide on Google Cloud Agent Skills.

The Series:

- Part 1 : What are Google Cloud Skills

- Part 2 : Intermediate Skills in Action (BigQuery and Cloud Run) (this blog)

_- Part 3 : Advanced Ops (WAF Security, Architecture, Custom Skills)

Part 4 : More Use Cases_

Before your agent or code can interact with any Google Cloud service, it needs permission to do so. Authentication is the very first step in the Google Cloud Agent Skills workflow because without it, every subsequent operation will fail with a 401 Unauthorized or 403 Forbidden error.

Setting up authentication correctly ensures a smooth, secure experience whether you are building locally, deploying to the cloud, or using agents.

Prerequisites: Manual Setup

While our agent will do most of the heavy lifting, authentication requires an initial manual login to establish your identity on your machine.

Run the following commands in your terminal:

# Set your active project
gcloud config set project YOUR_PROJECT_ID

# Login to the gcloud CLI
gcloud auth login

# Set up Application Default Credentials (ADC)
gcloud auth application-default login

Once this is done, you are ready to use the agent for everything else!

Confirming Skill Installation

For this step, we will use the google-cloud-recipe-auth skill. Confirm it's installed:

npx skills list

Prompt-Driven Authentication Checks

Instead of manually running diagnostic scripts or consulting complex decision trees, you can just ask your agent. The agent uses the google-cloud-recipe-auth skill to evaluate your environment and provide tailored guidance.

The responses given below are from running them in Antigravity CLI.

1. Verifying Authentication

You prompt: Check if my Google Cloud authentication is set up correctly for project YOUR_PROJECT_ID

Agent response:

Yes, your Google Cloud authentication is set up correctly for project PROJECT_ID.                                                       

  ### Verification Details:                                                                                                                           

  1. Active Account (gcloud CLI)                                                                                                                      
      • Account: YOUR_ACCOUNT                                                                                                                    
      • Status: Authenticated & Active                                                                                                                
  2. Project Configuration                                                                                                                            
      • Active Project: PROJECT_ID                                                                                                        
      • Quota Project: PROJECT_ID                                                                                                         
      • Compute Region: us-central1                                                                                                                   
  3. Project Access & Status                                                                                                                          
      • Project Name: PROJECT_ID                                                                                                                 
      • Project Number: PROJECT_NUMBER                                                                                                                  
      • Lifecycle State: ACTIVE                                                                                                                       
      • Permissions: Verified (able to retrieve project metadata via Resource Manager API).                                                           
  4. Application Default Credentials (ADC)                                                                                                            
      • Status: Active & Valid (client SDKs and application libraries can successfully authenticate to Google Cloud APIs).

2. Architectural Auth Decisions

You prompt: What authentication method should I use for a Cloud Run service that needs to access BigQuery?

Agent response: (Which skill did it use? Answer comes a bit later)

For a Cloud Run service accessing BigQuery, the recommended Google Cloud best practice is Service-to-Service Authentication via attached Service    
  Accounts.                                                                                                                                           
  ──────                                                                                                                                              
  ### Recommended Setup                                                                                                                               

  #### 1. Authentication (Identity)                                                                                                                   

  Attach a Custom User-Managed Service Account to your Cloud Run service instead of using default accounts or static JSON key files.                  

  • Create a custom service account (e.g., cloud-run-bq-sa@<project-id>.iam.gserviceaccount.com).                                                     
  • Attach it to Cloud Run during deployment:                                                                                                         
    gcloud run deploy SERVICE_NAME \                                                                                                                  
      --image IMAGE_URL \                                                                                                                             
      --service-account cloud-run-bq-sa@PROJECT_ID.iam.gserviceaccount.com                                                                            


  │ ⚠️ Avoid using static Service Account Keys (JSON files). Cloud Run provides a secure local metadata server that handles token issuance dynamically.
  ──────                                                                                                                                              
  #### 2. Authorization (IAM Roles)                                                                                                                   

  Grant your service account the least-privilege IAM roles required for BigQuery:                                                                     

  • roles/bigquery.jobUser: Required to run query jobs in the project.                                                                                
  • roles/bigquery.dataViewer (or roles/bigquery.dataEditor): Required to read (or write) data in the specific dataset or tables.                     

    # Grant permission to run jobs in the project                                                                                                     
    gcloud projects add-iam-policy-binding PROJECT_ID \                                                                                               
      --member="serviceAccount:cloud-run-bq-sa@PROJECT_ID.iam.gserviceaccount.com" \                                                                  
      --role="roles/bigquery.jobUser"                                                                                                                 

    # Grant permission on the dataset                                                                                                                 
    gcloud bigquery datasets add-iam-policy-binding DATASET_NAME \                                                                                    
      --member="serviceAccount:cloud-run-bq-sa@PROJECT_ID.iam.gserviceaccount.com" \                                                                  
      --role="roles/bigquery.dataViewer"                                                                                                              
    ──────                                                                                                                                            
  #### 3. In-Code Access (Application Default Credentials)                                                                                            

  In your application code, initialize the official Google Cloud BigQuery client library without passing explicit credentials. The library            
  automatically retrieves tokens via Application Default Credentials (ADC) from the Cloud Run metadata server.                                        

  Python Example:                                                                                                                                     

    from google.cloud import bigquery                                                                                                                 

    # Automatically authenticates using the attached service account                                                                                  
    client = bigquery.Client(project="PROJECT_ID")                                                                                        

    query_job = client.query("SELECT 1 AS test")                                                                                                      
    results = query_job.result()

I asked Antigravity CLI the following question: how did you answer the above question?

And here is the response. Check how it used the other skill:

I answered the question by drawing on Google Cloud's Security Best Practices (documented in the SKILL.md skill):                                    

  1. Authentication Framework (Identity)                                                                                                              
      • Google Cloud recommends using managed service identities for production workloads rather than static credentials (like JSON key files).       
      • In Cloud Run, attaching a custom service account allows the instance metadata server to issue short-lived access tokens dynamically.          
  2. IAM Authorization Model (Permissions)                                                                                                            
      • Google Cloud IAM enforces the principle of least privilege.                                                                                   
      • Accessing BigQuery requires separating job execution rights (roles/bigquery.jobUser) from data access rights (roles/bigquery.dataViewer or    
      dataEditor).                                                                                                                                    
  3. Application Default Credentials (ADC)                                                                                                            
      • Standard Google Cloud Client Libraries automatically search for credentials in a predefined hierarchy.                                        
      • On Cloud Run, ADC automatically retrieves tokens from the attached service account via the internal metadata server (http://169.254.169.254), 
      making hardcoded credentials unnecessary.

3. Setting up a Service Account

Try out things like this Help me set up a service account for my Cloud Run application with minimal permissions to access BigQuery

BigQuery Skills

In this step, we’ll explore how to use Agent Skills to interact with Google BigQuery. Instead of manually writing bash scripts, SQL queries, or Python clients, we will rely entirely on our AI agent.

Confirming Skill Installation

For this step, we will use the bigquery-basics skill. Confirm it's installed:

npx skills list

Prompt-Driven BigQuery Operations

With the bigquery-basics skill, the agent understands how to manage datasets, create tables, insert data, and run analytical queries.

1. Creating a Dataset

You prompt: Create a new BigQuery dataset called skills_tutorial in my project PROJECT_ID

Agent response:

The BigQuery dataset skills_tutorial has been successfully created in project PROJECT_ID.                                               

  ### Dataset Details:                                                                                                                                

  • Dataset ID: PROJECT_ID:skills_tutorial                                                                                                
  • Location: US                                                                                                                                      
  • Type: DEFAULT                                                                                                                                     
  • Status: Active (Verified)

Creating a Table

You prompt: Now create a table called web_analytics in that dataset with columns for: event_timestamp (TIMESTAMP), page_url (STRING), user_id (STRING), session_duration_seconds (FLOAT64), country (STRING)

Agent response:

The BigQuery table web_analytics has been successfully created in dataset skills_tutorial.                                                          

  ### Table Details:                                                                                                                                  

  • Table ID: PROJECT_ID:skills_tutorial.web_analytics                                                                                    

  ### Schema:                                                                                                                                         

   Column Name │ Type │ Mode
  ─────────────────────────────────────────────────┼─────────────────────────────────────────────────┼────────────────────────────────────────────────
   event_timestamp │ TIMESTAMP │ NULLABLE
   page_url │ STRING │ NULLABLE
   user_id │ STRING │ NULLABLE
   session_duration_seconds │ FLOAT64 │ NULLABLE
   country │ STRING │ NULLABLE

3. Inserting Sample Data

You prompt: Insert 10 rows of realistic sample web analytics data into the web_analytics table

Agent response:

10 realistic sample rows have been inserted into PROJECT_ID:skills_tutorial.web_analytics.                                              

  ### Inserted Data Preview:                                                                                                                          

   event_timestamp │ page_url │ user_id │ session_duration_seconds │ country
  ───────────────────────────┼─────────────────────────────────────┼───────────────────────────┼───────────────────────────┼──────────────────────────
   2026-07-23 10:15:30 UTC │ https://example.com/home │ usr_1001 │ 45.2 │ US
   2026-07-23 10:18:12 UTC │ https://example.com/products/laptop │ usr_1002 │ 120.8 │ CA
   2026-07-23 11:02:45 UTC │ https://example.com/blog/ai-trends │ usr_1003 │ 310.5 │ GB
   2026-07-23 11:45:00 UTC │ https://example.com/cart │ usr_1001 │ 88.0 │ US
   2026-07-23 12:30:15 UTC │ https://example.com/checkout │ usr_1004 │ 215.3 │ DE
   2026-07-23 13:10:05 UTC │ https://example.com/home │ usr_1005 │ 15.6 │ IN
   2026-07-23 14:05:22 UTC │ https://example.com/pricing │ usr_1006 │ 175.4 │ JP
   2026-07-23 14:22:10 UTC │ https://example.com/docs/api │ usr_1007 │ 450.0 │ US
   2026-07-23 15:00:50 UTC │ https://example.com/about │ usr_1008 │ 62.1 │ FR
   2026-07-23 15:40:18 UTC │ https://example.com/contact │ usr_1009 │ 95.7 │ AU

4. Running Analytical Queries

You prompt: Query the web_analytics table to show me the top 5 countries by average session duration

Agent response:

Here are the top 5 countries by average session duration from the web_analytics table:                                                              

  ### Query Results:                                                                                                                                  

                  Rank │ Country │ Average Session Duration (seconds) │ Total Sessions
  ─────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────
                    1 │ United Kingdom (GB) │ 310.50 s │ 1
                    2 │ Germany (DE) │ 215.30 s │ 1
                    3 │ United States (US) │ 194.40 s │ 3
                    4 │ Japan (JP) │ 175.40 s │ 1
                    5 │ Canada (CA) │ 120.80 s │ 1
  ──────                                                                                                                                              
  ### Executed SQL Query:                                                                                                                             

    SELECT                                                                                                                                            
      country,                                                                                                                                        
      ROUND(AVG(session_duration_seconds), 2) AS avg_session_duration_seconds,                                                                        
      COUNT(*) AS total_sessions                                                                                                                      
    FROM `PROJECT_ID.skills_tutorial.web_analytics`                                                                                       
    GROUP BY country                                                                                                                                  
    ORDER BY avg_session_duration_seconds DESC                                                                                                        
    LIMIT 5;

5. Complex Aggregations

You prompt: Show me a query that calculates daily page view counts grouped by URL

Agent response:

Here is the SQL query to calculate daily page view counts grouped by URL, along with unique visitor metrics:                                        

  ### SQL Query:                                                                                                                                      

    SELECT                                                                                                                                            
      DATE(event_timestamp) AS event_date,                                                                                                            
      page_url,                                                                                                                                       
      COUNT(*) AS page_views,                                                                                                                         
      COUNT(DISTINCT user_id) AS unique_visitors                                                                                                      
    FROM `PROJECT_ID.skills_tutorial.web_analytics`                                                                                       
    GROUP BY                                                                                                                                          
      event_date,                                                                                                                                     
      page_url                                                                                                                                        
    ORDER BY                                                                                                                                          
      event_date DESC,                                                                                                                                
      page_views DESC;                                                                                                                                
    ──────                                                                                                                                            
  ### Execution Results:                                                                                                                              

   Event Date │ Page URL │ Page Views │ Unique Visitors
  ────────────────────────────────────┼─────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────
   2026-07-23 │ https://example.com/home │ 2 │ 2
   2026-07-23 │ https://example.com/products/laptop │ 1 │ 1
   2026-07-23 │ https://example.com/blog/ai-trends │ 1 │ 1
   2026-07-23 │ https://example.com/cart │ 1 │ 1
   2026-07-23 │ https://example.com/checkout │ 1 │ 1
   2026-07-23 │ https://example.com/pricing │ 1 │ 1
   2026-07-23 │ https://example.com/docs/api │ 1 │ 1
   2026-07-23 │ https://example.com/about │ 1 │ 1
   2026-07-23 │ https://example.com/contact │ 1 │ 1

6. Cleanup

You prompt: Clean up i.e. delete the skills_tutorial dataset

Agent response:

The dataset skills_tutorial (and its contained web_analytics table) has been successfully deleted from project PROJECT_ID.              

  ### Clean-Up Summary:                                                                                                                               

  • Deleted Dataset: PROJECT_ID:skills_tutorial                                                                                           
  • Verification Status: Confirmed deleted (Not found).

Notice how you never had to write SQL or learn the bq CLI. The agent did it all.

Cloud Run Deployment

In this step, we’ll deploy a Python application to Google Cloud Run, a fully managed compute platform that automatically scales your stateless containers. Instead of writing the code, containerizing it, and deploying it manually, we’ll let the AI agent handle the entire process.

Confirming Skill Installation

For this step, we will use the cloud-run-basics skill. Confirm it's installed:

npx skills list

Prompt-Driven Application Deployment

With the cloud-run-basics skill, the agent knows how to write application code, create optimized Dockerfiles, and deploy to Cloud Run using best practices.

1. Generating the Application Code

You prompt: Create a simple Flask web API with three endpoints: GET / (returns service info), GET /health (returns OK), and POST /analyze (accepts JSON with a text field and returns word count and character count)

Agent response:

The Flask Web API has been created in app.py and verified with tests in test_app.py.                                                                

  ### API Endpoints Summary                                                                                                                           

  1. GET /                                                                                                                                            
      • Description: Returns service information and endpoints metadata.                                                                              
      • Response:                                                                                                                                     
        {                                                                                                                                             
          "service": "Text Analysis Web API",                                                                                                         
          "version": "1.0.0",                                                                                                                         
          "status": "running",                                                                                                                        
          "endpoints": [...]                                                                                                                          
        }                                                                                                                                             

  2. GET /health                                                                                                                                      
      • Description: Health check endpoint.                                                                                                           
      • Response: {"status": "OK"} (HTTP 200)                                                                                                         
  3. POST /analyze                                                                                                                                    
      • Description: Accepts a JSON body containing a text string field and returns word count and character count.                                   
      • Sample Request:                                                                                                                               
        curl -X POST http://localhost:8080/analyze \                                                                                                  
          -H "Content-Type: application/json" \                                                                                                       
          -d '{"text": "Hello world from Flask API!"}'                                                                                                

      • Sample Response:                                                                                                                              
        {                                                                                                                                             
          "text": "Hello world from Flask API!",                                                                                                      
          "word_count": 5,                                                                                                                            
          "character_count": 27                                                                                                                       
        }                                                                                                                                             


  ──────                                                                                                                                              
  ### How to Run locally                                                                                                                              

    ./.venv/bin/python3 app.py

2. Containerizing the App

You prompt: Create a Dockerfile for this Flask application

Agent response:

The Dockerfile, .dockerignore, and requirements.txt have been created.                                                                              

  ### Dockerfile Contents:                                                                                                                            

    # Use official lightweight Python image                                                                                                           
    FROM python:3.11-slim                                                                                                                             

    # Prevent Python from writing .pyc files and buffer stdout/stderr                                                                                 
    ENV PYTHONUNBUFFERED=1 \                                                                                                                          
        PYTHONDONTWRITEBYTECODE=1 \                                                                                                                   
        PORT=8080                                                                                                                                     

    # Set working directory                                                                                                                           
    WORKDIR /app                                                                                                                                      

    # Install dependencies                                                                                                                            
    COPY requirements.txt .                                                                                                                           
    RUN pip install --no-cache-dir -r requirements.txt                                                                                                

    # Copy application source code                                                                                                                    
    COPY app.py .                                                                                                                                     

    # Expose port                                                                                                                                     
    EXPOSE 8080                                                                                                                                       

    # Run the web service using Gunicorn                                                                                                              
    CMD exec gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 app:app                                                                
    ──────                                                                                                                                            
  ### Key Highlights:                                                                                                                                 

  • Production WSGI: Configured with gunicorn for high performance and concurrency.                                                                   
  • Cloud Run Compatible: Listens on dynamic $PORT (defaulting to 8080).                                                                              
  • Optimized Build: .dockerignore created to exclude virtual environments, cache files, and unnecessary repository metadata.

Deploying to Cloud Run

You prompt: Deploy this application to Cloud Run in us-central1 region as a service called skills-tutorial-analyzer

Agent response:

The deployment command for skills-tutorial-analyzer to Cloud Run in us-central1 has been launched in the background. I will wait for it to complete 
  before proceeding.....

The Flask application has been successfully built and deployed to Cloud Run!                                                                        

  ### Deployment Details:                                                                                                                             

  • Service Name: skills-tutorial-analyzer                                                                                                            
  • Region: us-central1                                                                                                                               
  • Project: PROJECT_ID                                                                                                                   
  • Service URL: [https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app](https://skills-tutorial-analyzer-415458962931.us-central1.run.app)                                                                    
  ──────                                                                                                                                              
  ### Verified Endpoints:                                                                                                                             

  #### 1. Service Information (GET /)                                                                                                                 

    curl https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app/                                                                           

  Response:                                                                                                                                           

    {                                                                                                                                                 
      "service": "Text Analysis Web API",                                                                                                             
      "version": "1.0.0",                                                                                                                             
      "status": "running",                                                                                                                            
      "endpoints": [...]                                                                                                                              
    }                                                                                                                                                 

  #### 2. Health Check (GET /health)                                                                                                                  

    curl https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app/health                                                                     

  Response:                                                                                                                                           

    {                                                                                                                                                 
      "status": "OK"                                                                                                                                  
    }                                                                                                                                                 

  #### 3. Text Analysis (POST /analyze)                                                                                                               

    curl -X POST https://skills-tutorial-analyzer-<PROJECT_NUMBER>.us-central1.run.app/analyze \                                                          
      -H "Content-Type: application/json" \                                                                                                           
      -d '{"text": "Hello world from deployed Cloud Run service!"}'                                                                                   

  Response:                                                                                                                                           

    {                                                                                                                                                 
      "text": "Hello world from deployed Cloud Run service!",                                                                                         
      "word_count": 7,                                                                                                                                
      "character_count": 44                                                                                                                           
    }

4. Testing the Health Endpoint

You prompt: What’s the URL of my deployed service? Test it by hitting the health endpoint

Agent response:

The URL of your deployed Cloud Run service is:                                                                                                      

  🔗 https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app                                                                                
  ──────                                                                                                                                              
  ### Health Endpoint Test (GET /health)                                                                                                              

    curl -i https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app/health                                                                  

  #### Response:                                                                                                                                      

    HTTP/2 200                                                                                                                                        
    content-type: application/json                                                                                                                    
    date: Thu, 23 Jul 2026 10:43:31 GMT                                                                                                               
    server: Google Frontend                                                                                                                           

    {"status":"OK"}

5. Testing the Analyze Endpoint

You prompt: Send a POST request to the /analyze endpoint with the text ‘Google Cloud Skills make AI agents powerful’

Agent response:

Here is the response from sending the POST request to the /analyze endpoint:                                                                        

  ### Request:                                                                                                                                        

    curl -X POST https://skills-tutorial-analyzer-<PROJECT-NUMBER>.us-central1.run.app/analyze \                                                          
      -H "Content-Type: application/json" \                                                                                                           
      -d '{"text": "Google Cloud Skills make AI agents powerful"}'                                                                                    
    ──────                                                                                                                                            
  ### Response (HTTP 200 OK):                                                                                                                         

    {                                                                                                                                                 
      "text": "Google Cloud Skills make AI agents powerful",                                                                                          
      "word_count": 7,                                                                                                                                
      "character_count": 43                                                                                                                           
    }

6. Cleanup

You prompt: Delete the skills-tutorial-analyzer Cloud Run service to clean up

Agent response:

The deletion command for Cloud Run service skills-tutorial-analyzer has been launched in the background. I will wait for it to complete before      
  proceeding.                                                                                                                                         

....
....

  The Cloud Run service skills-tutorial-analyzer has been successfully deleted from region us-central1 in project PROJECT_ID.             

  ### Clean-Up Verification:                                                                                                                          

  • Service Name: skills-tutorial-analyzer                                                                                                            
  • Region: us-central1                                                                                                                               
  • Status: Deleted (Verified via gcloud run services describe)

The agent wrote the code, containerized it, deployed it, and tested it — all from natural language.

To summarize

You have seen how to use Google Cloud Agent Skills now. The next part of the series will cover a few advanced skills around Architecture, Security and even writing your own Custom Skill. Stay tuned.

Google Cloud Skills Tutorial: The Complete Guide to AI-Powered Cloud Operations

Romin Irani — Thu, 23 Jul 2026 11:11:46 +0000

Welcome to the definitive guide on Google Cloud Agent Skills. As the landscape of software engineering evolves, AI coding agents are increasingly being given tasks to becoming autonomous and capable of executing complex, multi-step cloud operations.

The goal of this series is to take a look at the current set of official skills being made available by Google Cloud, right from the basics and applying it to a few use cases like performing security audits, deploy serverless applications, or optimize BigQuery pipelines.

At the end of this series, you should be able to assess their readiness and be able to leverage a few of these Agents Skills to get the job done accurately and securely.

Generated by Gemini Notebook

The Series:

- Part 1 : What are Google Cloud Skills (this blog)

_- Part 2 : Intermediate Skills in Action (BigQuery and Cloud Run)

Part 3 : Advanced Ops (WAF Security, Architecture, Custom Skills)

Part 4 : More Use Cases_

What Are Google Cloud Skills?

Agent Skills act as the essential bridge between raw AI capabilities and structured cloud expertise. They are portable instruction sets that teach AI coding agents exactly how to work with specific technologies safely and efficiently.

Instead of an agent blindly guessing a gcloud command and breaking a production cluster, a skill provides:

Verified Workflows : Step-by-step logic approved by experts.
Safety Gates : Clear distinctions between read-only audits and mutating actions that require your explicit human-in-the-loop approval.
Contextual Awareness : Instructions on what environmental variables, IAM permissions, and authentication states to check before beginning a task.

That is our understanding and expectations. At the end of the day, results will vary, depending on the quality of the Skills. Hence an important area like Cloud Operations , if using with Agent Skills, will have to be evaluated carefully.

The google/skills Repository

The official google/skills repository is an open-source collection of these instruction sets. Built on the open standard defined at agentskills.io, it currently houses (at the time of writing) nearly 70+ skills spanning 8 distinct categories:

How Skills Work: The Progressive Disclosure Model

If you were to load all 70 odd instructions/details that are present in these skills into an AI agent’s context window simultaneously, the agent would become confused, slow, and expensive to run. To solve this, when it comes to Skills, Agents will use a progressive disclosure model.

Enough has been written on this topic, so we will not iterate much on that here.

Getting Started

This section summarizes the foundational setup required to start using Google Skills. We will explore how to get your agent environment set up with these powerful instruction sets.

Prerequisites

Before we install anything, ensure you have the following installed on your machine:

Node.js (v18+): Required for running the skills CLI.
npm : Comes with Node.js.
Google Cloud SDK (gcloud CLI): To authenticate and interact with Google Cloud. You should setup gcloud with a specific Google Cloud Project, so that all the experiments that you do with these Agent Skills will be executed across that project.
An AI coding agent : E.g., Google Antigravity / Antigravity CLI or any other agent that supports the agentskills.io standard.

Installing Skills

Getting the skills onto your machine is straightforward. Ensure you have Node.js (v18+) and your AI coding agent installed. You could install specific skills that you need via the npx skills add google/skills command. But here are some ways to install the skills.

Option A: Install Only What This Tutorial Needs (Recommended)

For this tutorial, we use 9 specific skills across the steps and use cases. Installing only these keeps your environment focused and is a best practice, you should install what you need, not everything.

You can use the interactive CLI to install skills:

# Core setup skills 
npx skills add google/skills --skill google-cloud-recipe-onboarding
npx skills add google/skills --skill google-cloud-recipe-auth

# Intermediate skills
npx skills add google/skills --skill bigquery-basics
npx skills add google/skills --skill cloud-run-basics

# Advanced skills 
npx skills add google/skills --skill google-cloud-waf-security
npx skills add google/skills --skill google-cloud-solution-architecture

# Use Case skills
npx skills add google/skills --skill google-cloud-waf-cost-optimization
npx skills add google/skills --skill google-cloud-solution-build-deploy-agents
npx skills add google/skills --skill gemini-api

Starting with just these 9 skills is ideal for learning. You can always add more later as you explore.

For example, when I run the first command , I get the following interactive display:

$ npx skills add google/skills --skill google-cloud-recipe-onboarding

███████╗██╗ ██╗██╗██╗ ██╗ ███████╗
██╔════╝██║ ██╔╝██║██║ ██║ ██╔════╝
███████╗█████╔╝ ██║██║ ██║ ███████╗
╚════██║██╔═██╗ ██║██║ ██║ ╚════██║
███████║██║ ██╗██║███████╗███████╗███████║
╚══════╝╚═╝ ╚═╝╚═╝╚══════╝╚══════╝╚══════╝

┌ skills 
│
◇ Source: https://github.com/google/skills.git
│
◇ Repository cloned
│
◇ Found 84 skills
│
● Selected 1 skill: google-cloud-recipe-onboarding
│
◇ 75 agents
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ── always included ────────────
│ • Amp
│ • Antigravity
│ • Antigravity CLI
│ • Cline
│ • Codex
│ • Cursor
│ • Deep Agents
│ • Gemini CLI
│ • GitHub Copilot
│ • Kimi Code CLI
│ • OpenCode
│ • Warp
│ • Zed
│ …and 4 more
│
│ ── Additional agents ─────────────────────────────
│ Search:  
│ ↑↓ move, space select, enter confirm
│
│ ❯ ○ AiderDesk (.aider-desk/skills)
│ ○ AstrBot (data/skills)
│ ○ Autohand Code CLI (.autohand/skills)
│ ○ Augment (.augment/skills)
│ ○ IBM Bob (.bob/skills)
│ ○ Claude Code (.claude/skills)
│ ○ OpenClaw (skills)
│ ○ CodeArts Agent (.codeartsdoer/skills)
│ ↓ 47 more
│
│ Selected: Amp, Antigravity, Antigravity CLI +10 more

It then asks you for Global or Project scope. It is advisable to go ahead with the current folder i.e. Project scope. This will create a .agents/skills folder and the skills will be placed in that.

Finally, you should see an overall report on the installation:

◇ Installation scope
│ Project

│
◇ Installation Summary ─────────────────────────────────────────────────────────────────╮
│ │
│ ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-recipe-onboarding │
│ copy → Amp, Antigravity, Antigravity CLI, Cline, Codex +8 more │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Security Risk Assessments ────────────────────────────────────────────────────╮
│ │
│ Gen Socket Snyk │
│ google-cloud-recipe-onboarding Safe 0 alerts Low Risk │
│ │
│ Details: https://skills.sh/google/skills │
│ │
├────────────────────────────────────────────────────────────────────────────────╯
│
◇ Proceed with installation?
│ Yes
│
◇ Installation complete

│
◇ Installed 1 skill ────────────────────────────────────────────────────────────────────────╮
│ │
│ ✓ google-cloud-recipe-onboarding (copied) │
│ → ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-recipe-onboarding │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯

│
└ Done! Review skills before use; they run with full agent permissions.

Here ~/agy2-projects/google-skills-tutorial/ is my folder in which I am running this tutorial. This could be something different on your machine.

Option B : Install Additional Skills (Later)

If you want the full catalogue and prefer to explore on your own, use the interactive installer: If you want the full catalogue and prefer to explore on your own, use the interactive installer:

npx skills add google/skills

When you run this command, an interactive selector will appear in your terminal. Choose the specific skills that you are interested to install and try out.

Option C : Installing a Single Skill Later (npx command based)

If you discover you need an additional skill later, you can add it individually at any time:

npx skills add google/skills --skill bigquery-basics

Manual Installation

If you prefer full control, you can clone the repository or manually place skill folders in your environment. Skills can be installed in two locations depending on their intended scope:

Workspace-specific : Place the skill folder inside .agents/skills/ at the root of your current project.
Global (User level): Place the skill folder inside ~/.gemini/config/skills/ to make it available across all your projects.

Where Skills get installed

When your agent starts up, it looks for skills across several locations. It resolves them using a specific hierarchy. If a skill with the same name exists in multiple places, the one closest to the workspace takes precedence.

Verification

After installation, it is good practice to verify that everything is in order.

You can list all currently installed and active skills using:

npx skills list

You should see something similar to this:

$ npx skills list
Project Skills

bigquery-basics ~/agy2-projects/google-skills-tutorial/.agents/skills/bigquery-basics                          
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
cloud-run-basics ~/agy2-projects/google-skills-tutorial/.agents/skills/cloud-run-basics                         
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
gemini-api ~/agy2-projects/google-skills-tutorial/.agents/skills/gemini-api                               
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-recipe-auth ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-recipe-auth                 
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-recipe-onboarding ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-recipe-onboarding           
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-solution-architecture ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-solution-architecture       
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-solution-build-deploy-agents ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-solution-build-deploy-agents
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-waf-cost-optimization ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-waf-cost-optimization       
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills
google-cloud-waf-security ~/agy2-projects/google-skills-tutorial/.agents/skills/google-cloud-waf-security                
  Agents: Antigravity, Antigravity CLI, Gemini CLI Source: google/skills

Alternatively, you can just peek into your directory structure to ensure the SKILL.md files are present:

ls -la .agents/skills/

If you are using Antigravity CLI, you can launch Antigravity CLI ( agy ) from the terminal. Give it the /skills command and you should see the skills listed in the workspace.

Workspace skills · Workspace config
  bigquery-basics: Manages datasets, tables, and jobs in BigQuery. Use when you need to interact with BigQuery, run SQL queries, manage BigQuery resour...
  cloud-run-basics: Manages Cloud Run services, jobs, and worker pools. Use when you need to deploy applications responding to HTTP requests (services)...
  gemini-api: Use when the user asks about using Gemini in an enterprise environment or explicitly mentions Vertex AI, Google Cloud, or Agent Platform....
  google-cloud-recipe-auth: Provides expert guidance on authenticating and authorizing to Google Cloud services and APIs, covering human users, service...
  google-cloud-recipe-onboarding: Guides a developer's first steps on Google Cloud, covering account creation, billing setup, project management, and d...
  google-cloud-solution-architecture: Interactively discovers requirements for a specific cloud workload and generates design recommendations and archi...
  google-cloud-solution-build-deploy-agents: Designs, builds, and deploys AI agents or multi-agent systems on Google Cloud. Provides an interactive wor...
  google-cloud-waf-cost-optimization: Generates cost optimization guidance for Google Cloud workloads based on the Google Cloud Well-Architected Framew...
  google-cloud-waf-security: Generates security-focused guidance for Google Cloud workloads based on the design principles and recommendations in the G...

Managing Skills

The CLI provides simple commands for managing your installed skills over time:

Update skills : npx skills update
Remove a skill : npx skills remove google-cloud-recipe-onboarding
Find skills : npx skills find "cloud run"

Understanding Skill Anatomy

Once a skill is installed, what does it actually look like? In this step, we break down the structure of a skill following the agentskills.io standard.

The SKILL.md File

The heart of every skill is the SKILL.md file. This isn't just documentation, it is executable instruction code for AI coding agents. When an agent reads this file, it learns exactly how to perform tasks, what commands to run, and what safety checks to enforce.

Let’s look at the full contents of our sample-skill/SKILL.md and break down what each section does.

---
name: cloud-storage-lifecycle-manager
metadata:
  category: Storage
description: Use this skill when the user asks to manage, configure, or optimize Google Cloud Storage (GCS) bucket lifecycle policies and data retention rules.
---

> **Tutorial Note:** The frontmatter above is scanned by the agent on startup. The `description` acts as the trigger.

# Cloud Storage Lifecycle Manager

## Overview
This skill guides the agent in analyzing existing GCS buckets and applying XML or JSON lifecycle policies to transition objects to colder storage classes (Nearline, Coldline, Archive) or delete them to optimize costs.

> **Tutorial Note:** The overview sets the stage for the agent, clarifying its persona and objective.

## Prerequisites
Before executing any mutating commands, verify:
1. User is authenticated (`gcloud auth list`).
2. Current project is set to `PROJECT_ID` or the user-specified project.

## Workflow
1. **Assess:** List the target bucket's current policies using `gcloud storage buckets describe gs://<BUCKET_NAME> --format="json"`.
2. **Design:** Draft a lifecycle policy rule based on the user's requirements (e.g., transition to Coldline after 90 days).
3. **Confirm:** Present the proposed policy to the user for approval.
4. **Apply:** Apply the policy using `gcloud storage buckets update gs://<BUCKET_NAME> --lifecycle-file=<FILE.json>`.

> **Tutorial Note:** The workflow provides step-by-step instructions. Agents are highly capable of following numbered lists.

## Safety & Confirmation Tiers

- **Tier R (Read-only):** `gcloud storage ls`, `gcloud storage buckets describe`. You may run these without asking.
- **Tier M (Mutating):** Applying a new lifecycle policy. **MUST ASK FOR EXPLICIT CONFIRMATION.**
- **Tier D (Destructive):** Deleting objects or removing buckets. Refuse to do this unless explicitly mandated by the user.

> **Tutorial Note:** Safety tiers ensure the agent doesn't autonomously delete infrastructure.

## Workload Assessment Questions
If the user's request is vague, ask ONE of these questions at a time to clarify:
- "What is the name of the GCS bucket you want to apply the lifecycle rule to?"
- "After how many days should the objects transition to a colder storage class?"

## Validation
After applying the rule, verify success by running:
`gcloud storage buckets describe gs://<BUCKET_NAME> --format="value(lifecycle)"`
Ensure the output matches the applied rule.

YAML Frontmatter

Every SKILL.md begins with a YAML frontmatter block. This metadata is crucial for the agent's startup phase.

---
name: my-cloud-skill
metadata:
  category: Serverless
description: Use this skill when the user asks to deploy serverless applications.
---

name : A unique identifier for the skill (usually matches the folder name).
metadata.category : Groups skills logically.
description : This is the activation trigger. The agent uses semantic matching against this description to decide when to activate the skill based on the user's prompt.

Markdown Body Sections

The markdown body dictates the agent’s behavior. While highly flexible, Google Cloud skills typically follow a common pattern:

Overview / Quick Start : A brief explanation of the skill’s purpose.
Prerequisites : Tools or API access required before execution.
Workflow / Decision Trees : Step-by-step instructions the agent must follow.
Safety & Confirmation Tiers : Guidelines on what needs user approval:

Tier R (Read-only): Agent can run these without asking (e.g., gcloud compute instances list).
Tier M (Mutating): Agent must ask before applying changes.
Tier D (Destructive): Highly restrictive actions requiring extra confirmation (e.g., deleting buckets).

Workload Assessment Questions : Clarifying questions the agent should ask the user before beginning.
Validation Checklists : Steps to verify the task succeeded.

Optional Supporting Files

A skill folder isn’t limited to just SKILL.md. It can contain supporting directories:

references/: Detailed documentation, IaC patterns (Terraform), IAM policies, or MCP integration configs that the agent can read for deep context.
scripts/: Executable Bash/Python scripts for setup automation or verification.
assets/: Templates for outputs, configuration files, or architecture diagrams.

Skill Structure and Processing

The diagram below is a good way to visualize how the Agent at startup scans the Skills YAML frontmatter and then handles the loading of the skill accordingly.

Skill Categories Table

Google Cloud skills are broadly organized into 8 distinct categories, at the time of writing.

Your First Interaction

Now that you have skills installed and understand their anatomy, it’s time to see them in action.

How Skill Activation Works

AI coding agents use a progressive disclosure model to manage skills efficiently:

Startup : The agent rapidly scans only the YAML frontmatter of all installed skills. It builds an internal registry of description triggers.
Prompting : When you type a prompt, the agent evaluates it against the registry.
Activation : If a match is found, it loads the full SKILL.md into its context window and executes the defined workflow.

This prevents the agent’s context window from being overwhelmed with instructions for tools it doesn’t need for the current task.

Walkthrough: The Onboarding Skill

Let’s trace what happens when you trigger the google-cloud-recipe-onboarding skill.

User : “Help me get started with Google Cloud in my new project.”

Agent Matches Prompt : The agent determines this matches the onboarding skill.
Agent Reads SKILL.md : It loads the instructions.
Agent Asks Questions : Following the “Single-question policy” often defined in skills, it asks: “What is your target Google Cloud Project ID?”
User Answers : “Use MY_PROJECT_ID."
Agent Audits : The agent runs Tier R (read-only) commands like gcloud config list to check current authentication and project setup.
Agent Presents Confirmation Table : Before enabling billing or APIs, it presents a structured markdown table detailing what it plans to do.
Agent Waits : It halts execution and waits for your explicit “Yes” before proceeding with mutating actions.

Key Concepts

Safety Gates : Points in the workflow where the agent is explicitly instructed to stop and ask for permission.
Consent Tables : A structured format agents use to explain What they will do, Command they will run, and the Impact.
The Single-Question Policy : Best practice for skills dictating that agents should only ask the user one clarifying question at a time to prevent cognitive overload.

Example Prompts to Try

Ensure that you have launched your favourite Agent (Antigravity, Antigravity CLI or any other) from the folder in which the .agents/skills folder is present.

I suggest that you don’t run these prompts at the moment and just observe the kind of natural language prompts that you can use to work with Google Cloud Platform via these Google Agent Skills.

Category: Foundations

1. Trigger google-cloud-recipe-onboarding

Prompt: “I want to set up my first Google Cloud project from scratch.”

Explanation: The agent will guide you through project creation, billing linking, and initial IAM setup.

2. Trigger google-cloud-recipe-auth

Prompt: “How do I authenticate my local environment to Google Cloud?”

Explanation: The agent will walk you through gcloud auth login and Application Default Credentials (ADC).

Category: Serverless

3. Trigger cloud-run-basics

Prompt: “I have a Dockerfile here. Can you help me deploy a containerized app to Google Cloud?”

Explanation: The agent will ask for the service name and region, build the image, and run gcloud run deploy.

4. Trigger functions-basics

Prompt: “Help me deploy a Node.js function that triggers on Pub/Sub messages.”

Explanation: The agent will scaffold the function code and construct the deployment command with the correct trigger flags.

Category: Storage

5. Trigger cloud-storage-lifecycle-manager (Our custom skill!)

Prompt: “I need to automatically move objects in my GCS bucket to Archive storage after 1 year.”

Explanation: The agent will generate a JSON lifecycle policy and apply it after your confirmation.

Category: Databases

6. Trigger cloud-sql-basics

Prompt: “Spin up a PostgreSQL database on Cloud SQL and show me how to connect.”

Explanation: The agent will draft a gcloud sql instances create command and explain Cloud SQL Auth Proxy.

7. Trigger firestore-basics

Prompt: “Initialize a Firestore database in native mode for my web app.”

Explanation: The agent will set up the database and perhaps show you how to write basic security rules.

Category: Big Data & Analytics

8. Trigger bigquery-basics

Prompt: “Load this local CSV file into a new BigQuery table.”

Explanation: The agent will use the bq load command and verify the schema.

Category: Networking

9. Trigger vpc-networking

Prompt: “Create a custom VPC network with two subnets in us-central1 and us-east1.”

Explanation: The agent will map out the subnets, verify IP ranges, and execute the creation commands.

Category: Well Architected Framework

10. Trigger waf-security

Prompt: “Can you audit my current Google Cloud architecture to see if it is secure?”

Explanation: The agent will adopt an auditor persona, ask clarifying questions about your workloads, and check for public buckets, overly permissive IAM, etc.

The Series goes on

Stay tuned, as in Part 2, we will cover a couple of Skills in Action (BigQuery and Cloud Run).

Gemini 3.6 Flash & 3.5 Flash-Lite: Developer guide

Patrick Loeber — Thu, 23 Jul 2026 09:25:08 +0000

Gemini 3.6 Flash (gemini-3.6-flash) and Gemini 3.5 Flash-Lite (gemini-3.5-flash-lite) are generally available (GA) and ready for production use.

Gemini 3.6 Flash: Stronger performance on complex agentic and multimodal tasks while reducing token usage, at a lower price point than 3.5 Flash.
Gemini 3.5 Flash-Lite: The fastest, lowest-cost model in the 3.5 family. Outperforms prior Flash-Lite generations for high-throughput execution.

This guide explains what's new in each model, what API changes affect your code, and how to migrate.

Tip: You can automate this migration with a coding agent that supports skills (like Antigravity). Run /gemini-interactions-api migrate my app to Gemini 3.6 Flash

New models

Model	Model ID	Default thinking level	Pricing	Description
Gemini 3.6 Flash	`gemini-3.6-flash`	`medium`	$1.50/1M input tokens and $7.50/1M output tokens	Balances speed with intelligence for agentic and multimodal tasks.
Gemini 3.5 Flash-Lite	`gemini-3.5-flash-lite`	`minimal`	$0.30/1M input tokens and $2.50/1M output tokens	The fastest, lowest-cost 3.5 model for high-throughput execution.

Both models support the 1M token context window, 64k max output tokens, thinking, and the full suite of built-in tools including Computer Use.

For complete specs, see the model pages:

For detailed pricing, see the pricing page.

Quickstart

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="Write a three.js script that renders an interactive 3D robot."
)

print(interaction.output_text)

What's new in Gemini 3.6 Flash

Token and turn reduction: Completes multi-step workflows with fewer reasoning steps, conversational turns, and tool calls than Gemini 3.5. It also reduces execution loop spiraling.
Improved code generation: Produces higher quality production-ready code with fewer unwanted edits and fewer debugging loops.
Better instruction following: Reduces unwanted file changes during diagnostic tasks.
Strong multimodal and spatial reasoning: Improved performance on chart interpretation, visual blueprint conversion, and multi-element web layout generation.
Upfront programmatic inspection: Prefers running diagnostic code scripts before making changes more frequently than Gemini 3.5 Flash. This improves accuracy on complex tasks, but can add extra exploratory steps on simple frontend work.
Computer Use support: Supported as native tool for agentic UI automation.
UI styling preference: Better at creating functional code, though human evaluators preferred earlier models for visual layout and styling. You can mitigate this by providing explicit design guidelines.
Default thinking effort (medium): Uses the same medium default thinking level as Gemini 3.5 Flash.
Reduced pricing: Lower output token costs ($7.50/1M vs. $9.00/1M for 3.5 Flash). Input tokens remain at $1.50/1M.

What's new in Gemini 3.5 Flash-Lite

Reduced task execution latency: Highest throughput in the 3.5 family for high-volume data parsing and document extraction.
Enhanced reasoning and multimodal performance: Strong migration path from Gemini 2.5 Flash, with higher scores on reasoning tasks like HLE (18.0% vs. 11.0%) and multimodal benchmarks like CharXIV (74.5% vs. 63.7%).
Subagent orchestration and tool reliability: Improves tool execution reliability for code execution, search, and MCP workflows. Increase the thinking level for autonomous planning and complex subagent tasks.
Improved document understanding: Improves accuracy on document parsing and structured data extraction. Experiment with both minimal and high thinking levels depending on document complexity.
Interactive web coding and tabular data processing: Performs strongly on frontend JavaScript and tabular data processing by planning via lightweight code execution.
Chatbot and persona persistence: Stronger multi-turn instruction following and persona consistency over Gemini 3.1 Flash-Lite.
Computer Use support: Supported as native tool for agentic UI automation.

Choosing the right Flash or Flash-Lite model

Use this table to select the right model and migration path for your workloads.

Both models require removing deprecated sampling parameters (temperature, top_p, top_k) and prefilled model turns. See API changes for details.

Model	Primary use cases	Recommended migration target
Gemini 3.6 Flash `gemini-3.6-flash`	Code generation, spatial/multimodal reasoning, multi-step agentic workflows	Gemini 3.5 Flash, Gemini 3 Flash (Preview), or Gemini 3.1 Pro
Gemini 3.5 Flash-Lite `gemini-3.5-flash-lite`	Autonomous subagent execution, high-volume data analysis and document extraction, structured JSON parsing	Gemini 3.1 Flash-Lite or Gemini 2.5 Flash

Updated Antigravity agent

Due to its improved performance, Gemini 3.6 Flash is now the new default model powering the Antigravity agent in Gemini Managed Agents. This can be changed by setting a new field on the API.

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Read Hacker News, summarize the top 10 stories, and save the results as a PDF.",
    environment="remote",
)

print(interaction.output_text)

API changes and parameter updates

Starting with Gemini 3.6 Flash and Gemini 3.5 Flash-Lite, the following API changes apply to these models and all future Gemini model releases.

Sampling parameter deprecation: temperature, top_p, and top_k are deprecated. The API ignores these parameters and returns an error in future model generations.
Prefilled model turn validation: Prefilling model turns is no longer supported. If the last non-empty turn in the request is a model turn, the API returns a 400 error.

Below are detailed explanations and code samples for each API change.

1. Sampling parameter deprecation (`temperature`, `top_p`, `top_k`)

temperature, top_p, and top_k are deprecated and ignored. In future model generations, supplying these parameters returns an HTTP 400 error. Remove these parameters from all requests.

# ⚠️ Remove these parameters (deprecated)
generation_config = {
     "temperature": 0.7,
     "top_p": 0.9,
     "top_k": 40,
}

To improve determinism, define a system instruction with explicit rules for your
specific use case.

2. Prefilled model turn validation {:#prefilled-model-turn-validation}

API requests ending with a non-empty model role turn are disallowed and return an HTTP 400 Error.

⚠️ Avoid

In legacy generateContent or raw REST payloads, ending with a model role turn
is now disallowed:

/* ❌ DO NOT: End payload contents with a 'model' role turn */
{
  "contents": [
    {"role": "user", "parts": [{"text": "Translate 'Hello world' to Spanish."}]},
    {"role": "model", "parts": [{"text": "Translation:"}]}  /* ❌ Returns error */
  ]
}

✅ Recommended Migration (Interactions API)

In the Interactions API, model turns are not manually prefilled. If your application previously prefilled a model turn to suppress preambles or force JSON formatting, use system_instruction or Structured outputs instead.

# ✅ RECOMMENDED: Use system_instruction in the Interactions API to specify output format
interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="Translate 'Hello world' to Spanish.",
    system_instruction="Output only the translation without introductory text.",
)

Migration checklist

Tip: You can automate this migration with a coding agent that supports skills (like Antigravity). Run /gemini-interactions-api migrate my app to Gemini 3.6 Flash

Migrate to gemini-3.6-flash

Update Model ID: Change your target model string to gemini-3.6-flash.
Remove deprecated sampling parameters:
- Strip temperature, top_p, and top_k from generation configs.
- Replace thinking_budget with the string enum thinking_level set to "medium" or "high".
- Remove candidate_count (unsupported in Gemini 3.x).
Enforce turn validation rules:
- Standardize multi-turn conversations on server-side previous_interaction_id.
- Remove prefilled model turns.
Audit function calling:
- Place multimodal assets inside the response payload.
- Format inline instructions using \n\n.
- If you see Malformed_Function_Call errors tied to pre-tool text, see Workarounds for pre-tool text requirements.
- Only if using generateContent API: Ensure all FunctionResponse objects include call_id and name.
Baseline Gemini 3.x requirements: For SDK updates and thought signature preservation, see the Gemini 3.5 Migration Checklist.

Migrate to gemini-3.5-flash-lite

Update Model ID: Change your target model string to gemini-3.5-flash-lite.
Configure thinking effort level:
- For high-volume extraction, routing, or classification: leave thinking_level at "minimal" (default) for maximum throughput.
- For autonomous subagents with tool calls, code execution, or multi-step reasoning: set thinking_level to "medium" or "high" to prevent premature tool termination.
Remove deprecated parameters and validate function calling: Apply the same rules as for 3.6 Flash above.
Baseline Gemini 3.x requirements: Refer to the Gemini 3.5 Migration Checklist.

Next steps

Review API specs on the Models Overview.
Explore multi-agent orchestration in the Interactions API Guide.
Test and refine prompts in Google AI Studio.
Read the blog post, including info on the new Gemini 3.5 Flash Cyber model

Why AI Apps Fail in Production (And How Google Solved It)

Stephanie Wong — Wed, 22 Jul 2026 17:36:07 +0000

We are living in the golden age of the weekend AI side project. Thanks to vibe coding and LLMs, you can take a wild idea from a blank screen to a working app over a cup of coffee.

But the second you try to bring that casual prototype into a big enterprise environment, you hit a brick wall. Rigid infrastructure, strict compliance rules, and a leadership team terrified of breaking things will kill your momentum.

The numbers are pretty brutal: Only 5% of AI prototypes ever make it to production. The other 95% vanish into corporate purgatory.

Watching people on social media ship lightning-fast AI features while you're stuck in endless corporate review loops can be maddening. To figure out how to bridge that gap, I looked into the engineering trenches at YouTube to see how they handle this exact speed-vs-risk paradox.

The Speed-vs-Risk Paradox

When you're building solo, failure is cheap. If your AI agent acts up, you just tweak the prompt and hit restart.

But inside a company, letting unconstrained AI agents run loose creates a massive blast radius. On our premiere episode of Emergent, AI engineering leader Addy Osmani talked about running ten parallel agents on a personal project. Because the changes weren't properly isolated, technical debt piled up instantly and catastrophically broke two of his apps.

Now imagine that risk at YouTube’s scale, where you're handling billions of users on a 20-year-old codebase. You can't just let experimental code run wild. But traditional compliance pipelines take months, and by the time your demo actually gets approved, the AI models have already evolved, leaving your feature obsolete.

Enter YouTube’s AI Prototyping Stack

Benji Bear, Google Deepmind and former YouTube engineer, solved this problem by changing the infrastructure philosophy entirely. Instead of trying to speed up manual reviews, his team decoupled experimentation from mainline production servers.

They built a Prototyping Stack that tackles the two biggest bottlenecks for developers:

A Safe, Live Data Layer: Instead of testing in a vacuum with fake data, developers bootstrap ideas using Google AI Studio templates. These hook into a secure Google Cloud proxy server that grants pre-authenticated, read-only API access to live components - like playlists, videos, and channels. You get technical accuracy without any risk of polluting or crashing core databases.

Live UI Injection: To see how features actually feel to a real user, developers use client-side extension wrappers to inject experimental UI directly into their local browser. It's completely isolated from production code, meaning updates can be safely staged and tested in minutes.

By shifting to this setup, YouTube went from taking quarters to vet a single feature to launching several successful prototypes (like YouTube Recap) straight to user research studies in a matter of weeks.

Embrace Throw-Away Code

Making this work requires a pretty massive psychological shift: You have to embrace throw-away code.

As engineers, we are trained to write pristine, permanent infrastructure. But prototype code should be messy. Its only goal is to validate whether users actually care about the feature. Trying to clean up and force a chaotic, AI-generated script directly into an enterprise codebase is an architectural trap.

Instead, you can use Google AI Studio to establish a highly accurate baseline on day one. Run your user tests, look at the data, and if the idea wins, discard the messy script. Because you already proved the baseline parameters work, rewriting a clean version for production becomes significantly faster, cheaper, and safer.

Moving Fast Without Breaking Things

A 95% failure rate shouldn't be viewed as a mistake—it should be the strategy. AI has made generating code incredibly cheap, shifting our roles from syntax gatekeepers to System Architects.

Our job now is to design the read-only sandboxes and isolated pipelines that let our teams fail safely at hyper-speed. The biggest risk isn't breaking a server with messy AI code; it's missing the technological wave because your validation loops are too slow.

To see the full technical breakdown, developer interviews, and a deep dive into the AI Prototyping Stack, check out our premiere episode of Emergent on YouTube.