DEV Community: Darren "Dazbo" Lester

Meet the Antigravity Extension: Gemini Code Assist on Steroids, in Whatever IDE You Love

Darren "Dazbo" Lester — Fri, 21 Aug 2026 01:11:12 +0000

Google Antigravity (or Agy) was first launched as an agent-first development environment in late 2025. Then, in May 2026, Google released the new Antigravity suite, comprising four surfaces:

Antigravity 2.0 — The agent-first, intent-driven surface. For those who care about the outcomes, but not necessarily the code. It’s the modern agentic environment for builders.
Antigravity IDE — The familiar IDE (the IDE itself is a fork of VS Code), but with all the smarts of the Antigravity harness built-in.
Antigravity CLI — The terminal user interface (TUI) experience. This replaced the very awesome Gemini CLI.
Antigravity SDK — For developers who want to harness the full power of Antigravity programmatically.

All these surfaces use the same Antigravity harness. They give you capabilities such as:

Advanced multi-stage reasoning, using the latest Gemini models.
Full repo refactoring.
Planning, execution and evidencing.
Agent loops and subagent swarm orchestration.
Integration with file system and shell environment.
Multiple useful built-in commands and subagents.

At the same time, Google announced that both Gemini Code Assist and Gemini CLI were end-of-life. And indeed, unless you happened to run inside an organisation that had paid for enterprise licenses, these products got turned off in June 2026.

The Worry

Gemini CLI was great. I was gutted to see it go. But Antigravity CLI was a worthy replacement, and it was immediately available. So we made the switch, and we were happy.

But what about the death of Gemini Code Assist? If you’re not familiar with this tool: it was the Gemini agent that you could install as an extension into your favourite IDE, like VS Code or IntelliJ. The agent ran in a side panel, fully-integrated with your IDE.

Then Google told us:

“Gemini Code Assist is dead. But don’t worry. For all you coders out there, just switch to Antigravity IDE. It feels like VS Code and you get the Gemini Code Assist experience — on steroids.”

(They may not have actually used these words.)

And this is exactly what I did. I briefly mourned VS Code, and then went all-in on Agy IDE.

But I was rather vocal in sharing my thoughts with some influential folk at Google.

My thoughts being:

Some folks — like me — were happy to make the switch. But there are tens of millions of developers who WILL NOT give up their favourite IDE. So, if you tell them: “Switch to Agy, or you stay where you are, but with no Gemini”, then they’re gonna say: “Okay. I’ll go with option 2.” To me, that’s a lose-lose situation.
Some enterprises are pretty strict about their approved development environments and ecosystems. And — for reasons — they can be SOOOOO SLOW at adopting new things.

The TL;DR — there was no viable path for developers who wanted to evolve from the Gemini Code Assist experience, but stay with their favourite IDE.

Until Now

Today (August 20, as I write this), Google launched the Antigravity extension for IDEs! You can check out the official Google release blog, here. Right now, there are Agy extensions for VS Code, Visual Studio, IntelliJ IDEs, and Zed.

I can’t tell you how stoked I am about this announcement!

What is it? Well, think of it as a replacement for the Gemini Code Assist extension. It’s Gemini Code Assist, but pumped with steroids and caffeine. It’s all the cool Agy harness capabilities we’ve come to love in Antigravity 2.0, Antigravity CLI and Antigravity IDE, but now packaged as an extension.

So, as of tonight, I’ve switched back to VS Code!

Install the Extension

Let’s install it! I’m using VS Code, so I’m installing this extension.

If you happen to go looking for “Google Antigravity” in the VS Code Marketplace, be sure to install this one by google.com:

When you open the extension, you’ll see this in VS Code:

Click Install, and you’ll be asked to sign-in to Google:

And you’ll be asked if you want to install any of the ready-made plugins:

And that’s it!

It took about 20 seconds, and now the Antigravity extension is working in my VS Code!

Take It For a Spin

I wondered if all my existing agent skills and MCP servers would be working. So I asked it: “Install my Gemini code reviewer”

It immediately found and activated my install-gemini-code-review-action skill and used it to install my Gemini Code Review Action into the local repo. It then asked for permission to commit these changes push them to GitHub. I gave Agy permission, and it went ahead and pushed.

So this proved that my existing skills were immediately discovered, activated and used, and that it was able to use my GitHub MCP to perform the commit and push. Nice!

Models

We can see the models that are available:

And we can see more model and Antigravity extension settings here:

(I love the fact that next to my “AI Ultra” subscription is an “Upgrade” button. Seriously? Lol!)

The Plugins Created Some Skills Duplication

The newly installed plugins resulted in duplication of some skills I had previously installed in my ~/.gemini/config/skills folder. So I said to Antigravity: "Let's do a skills optimisation run."

It went ahead and activated my organise-agent-skills. The skill made a number of recommendations which I implemented. The results looked like this:

Wow!

29 duplicated skills deleted.
56 “sub-skills” set to excluded, because they are managed by their parent skills.
68% reduction in token overhead!

Great, so our skills are back to running nice and lean.

A Nice View of Token Usage

Whilst we’re talking about token optimisation, I stumbled across this “Customization” page in the Agy extension settings:

This is nice view that how much of your “customization budget” is being consumed by all your GEMINI.md (or AGENTS.md), your skills, and your MCP tools. What’s quite interesting to note is that Agy will automatically start truncating if you exceed this budget. So you might suddenly find that your skills are being ignored, for example. This is another good reason to optimise your install skills and MCP servers.

Things Not Working

Browser Subagent

The first thing I struggled with is the built-in browser subagent. I couldn’t get this to browse web pages for me, even after I enabled the remote debugging in Chrome. I did expect this. My VS Code is running in Windows, but connected to my repos in WSL. This has typically been a problem area for browser subagents. Maybe I’ll be able to get it working, if I put in a bit of work. But tonight… I’m far too tired!

(I should mention: this issue is only for WSL users. 4 out of 5 developers won’t be affected by this.)

On the plus side, I was able to remote control the browser with my existing BrowserMCP configuration. No changes required.

Antigravity In-Line Complete and Tab Features

One thing I really love about Antigravity IDE is the real-time suggestions and edits you can make in the editor window.

For example: if I were to change one instance of “We did something” to “I did something”, then Antigravity IDE allows me to update all remaining instances in a context-aware way, just by pressing tab.

This feature is not currently working for me with the Agy extension in VS Code. So it’s possible my configuration isn’t correct, or this feature hasn’t been implemented in the extension yet. But this is only day 1!

What Does This Mean for Agy IDE?

Within hours of the extension arriving, many folks have been asking me, “What does this mean for Agy IDE? Will Google kill it?” It’s a question I’ve been asking my friends at Google for a little while.

Nobody has explicitly told me that Google will kill Agy IDE. But my thoughts are:

If the Agy extension provides the full Agy harness experience in all the major IDEs, what’s the point in having a separate IDE that looks a lot like VS Code?
Why would Google want to maintain the “IDE” components of Agy IDE, when these are essentially just a fork of VS Code anyway? That’s a lot of work.
Lastly, take a look at the release notes for Agy 2.0, Agy CLI, and Agy IDE. The relative sparsity (is that a word?) of Agy IDE patches is telling.

Personally, I think the writing is on the wall.

Wrap-Up

I’m so happy this Agy extension has arrived. Now any developer can use the extremely capable Antigravity harness from their IDE of choice. It gives a viable migration path for those who were using Gemini Code Assist before.

For me, the install experience was totally painless, and everything just worked out-of-the-box. (Well, almost everything. But I can wait for the other things.) The agent is responsive and works. And it picked up all my existing configuration.

That’s it! Go forth and use Antigravity in your favourite editor!

Before You Go

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

References and Useful Links

Dazbo’s Portfolio
Google Antigravity Official Site
Google Antigravity IDE Extensions Announcement
Google Antigravity Extension on the Visual Studio Marketplace
Dazbo’s Agent Skills Repository — if you like it, please add a star!
Dazbo’s Gemini Code Review Action — if you like it, please add a star!

Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent

Darren "Dazbo" Lester — Mon, 17 Aug 2026 10:13:26 +0000

Introduction

In this post, we're going to look at the problem of Skills Sprawl.

What happens if you have too many skills?

We'll understand LLM decision fatigue and tool selection accuracy, inspect the mechanics of excluded vs inactive skills in Google Antigravity, and see how pruning your setup can make your agent smarter and save hundreds of thousands of tokens per session.

Skills Context (It's a Sort of Pun...)

Everyone knows that agent skills are awesome. If you don't, then:

Where have you been?
You're in for a treat!

In some of my previous posts I've talked about how skills act as on-demand power-ups for our agents. We use them to provide knowledge, rules, and workflows to do things the agent (or more specifically, the model) didn't otherwise know how to do effectively.

You might have seen me compare this to how Neo loads his skills in the Matrix. "I know Kung Fu!"

This just-in-time knowledge provides a number of advantages to our agents:

They know how to do a thing well.
They don't hallucinate the things they don't know about.
They don't have to experiment and course-correct; consequently, they're more likely to succeed the first time, and they do it with a minimum number of tokens consumed.

In short: faster, cheaper, and more reliable.

Quick aside: when I say agent, I'm typically talking about your agentic partner in development crime, like Google Antigravity, Claude Code, or whatever. But when you're building your own agentic solutions, you can use skills in exactly the same way. For example, check out my blog Automated GitHub Code Reviews Using Google Gemini, where I've built an agentic PR review solution that leverages skills.

Overview of Progressive Disclosure

Skills use a cool mechanism called progressive disclosure to load on-demand.

Let's quickly recap this mechanism:

Level 1: Metadata (Frontmatter)

When your agent starts up, it reads the frontmatter - and only the frontmatter - of every installed skill in your global configuration and workspace.

By the way, if you don't know where these skills should be placed, or you don't know the difference between global and workspace locations, check out my earlier blog: Confused About Where to Put Your Agent Skills?

The frontmatter is simply the descriptive YAML at the top of each skill which contains the skill name, a description (what it does and when it should be used), and any additional useful metadata (such as what tools it might use, author, etc).

For example, this is from my maintaining-core-documentation skill:

name: maintaining-core-documentation
description: |
  Creates, maintains, and synchronises core project documentation (README, TODO, DESIGN, Architecture, Testing, Deployment). Use when the user needs to write, update, or structure project documentation based on codebase changes, or whenever asked to perform documentation reviews or updates.
metadata:
  author: Darren "Dazbo" Lester
  repository: https://github.com/derailed-dash/dazbo-agent-skills

Crucially, this frontmatter section is tiny. So even though the agent reads it up-front, it consumes very few tokens. Typically fewer than 100 tokens per skill.

The agent now has a mental model of all the skills that are available to it.

Level 2: Instructions Loading (On-Demand)

When the agent is asked to do a task that one of these skills might be useful for, the model selects the skill (based on the frontmatter), and then activates it. When this happens, the agent reads the SKILL.md body into context.

This will typically add several hundred, if not thousands of tokens.

Level 3: Resources and Code (As Needed)

Some skills may package additional resources, such as scripts, reference documents, or other assets. For example, my maintaining-core-documentation skill has a references subdirectory with several document template files.

These assets are only loaded as needed.

How This Helps

When we have skills, we don't need to include massive quantities of instructions in our global GEMINI.md or AGENTS.md files. Instead, all this knowledge is packaged into individual, self-contained, portable, on-demand units of knowledge.

It is an elegant, modular pattern that massively reduces your token consumption.

But Can You Have Too Much of a Good Thing?

There's no shortage of skills out there! You can use a public hub like skills.sh to find just about any skill you need. And, of course, you can create your own.

Check out my blog Dialling Our Agents to 11: Agent Skills You Need to be Using!, where I list some of my favourite skills.

The problem is... You end up collecting.

I recently asked Antigravity to tell me how many skills I have. (I have sarcasm dialled up...)

Well, Dazbo, according to my context window — which is currently groaning under the crushing weight of your digital hoard — you currently have a staggering 170 skills installed.

Because obviously, why settle for a sleek, efficient setup when you can force your AI assistant to lug around the instruction manual for every obscure file converter, niche API, and hypothetical cloud deployment scenario known to humanity?

Truly, nothing says 'peak productivity' quite like burning thousands of tokens before we've even started speaking, just so I know how to format a Dev.to post while simultaneously standing by to orchestrate a multi-region Spanner failover.

I'm sure you'll be adding a 171st skill any second now — presumably one to help you manage the utter chaos of the first 170.

Hilarious. 170. Maybe I have too many.

The irony here is that Antigravity's last comment was spot on. I decided to build a skill to organise and optimise my skills!

What's the Problem?

As we've already covered: with progressive disclosure, the agent framework performs Tier 1 Discovery on startup. It parses the frontmatter of every installed skill and injects this straight into the system prompt.

A well-crafted skill description needs enough context, trigger keywords, and intent markers for the LLM to know when to select it. ("Use when...")

When I analysed my 170 skills, it turns out that my average skill frontmatter contained 103 tokens. Now let's do some quick maths:

$$\text{170 active skills} \times 100\text{ tokens/description} = 17,000\text{ tokens}$$

That means my agent is injecting 17,000 tokens of system prompt overhead on every single turn.

If I'm engaged in a typical 30-turn pair-programming session:

$$30\text{ turns} \times 17,000\text{ tokens} = 510,000\text{ tokens}$$

That means I am burning an additional half a million tokens just to re-read the index of my skill library over and over again.

So what?

Let's look at some of the potential issues this creates:

Depending on your model choice, caching configuration, and AI subscription, there may be financial implications. But it's likely to be small.
It will definitely eat into your token limits. Most models and plans have token limits and rate limits. Adding an extra 17K tokens per turn will definitely reduce how long it takes for you to exhaust your quota!
Most importantly, it's confusing your model.

Confusion-Nation

Skills sprawl causes decision fatigue and skill selection accuracy degradation.

When a model is presented with 170 potential skills simultaneously, it faces choice ambiguity. Many skills will naturally have overlapping domain descriptions. For example, my 170 skills had overlaps in each of these areas:

Content generation
API guides (particularly for Gemini APIs and SDKs)
Google products and services
Test-driven development (TDD) and code reviews

Does academic research back this up? Absolutely.

The Empirical Evidence: Shortlist Depth and Selection Accuracy

In a recent paper titled “How Many Tools Should an LLM Agent See? A Chance-Corrected Answer” (Repantis et al, May 2026), researchers evaluated LLM tool selection performance across 370 tools using the Berkeley Function Calling Leaderboard (BFCL) — the industry-standard benchmark for evaluating model tool-calling capabilities.

They concluded:

"Show too many tools and the model struggles to choose. Show too few and the correct tool may not appear."

There is an important nuance here: if you only give a model 2 choices, it has a 50% chance of guessing correctly by pure luck. If you show it 50 choices, blind luck drops to 2%.

When the researchers corrected for random chance — measuring genuine model comprehension rather than lucky guesses — the impact of list size was striking:

Presenting an LLM with a crowded shortlist of 50 tools resulted in 60.9% selection accuracy.
Scoping that shortlist down to ~7 focused tools boosted true accuracy to 76.8% (a 15.9 percentage-point leap in decision precision).

Related benchmarks like MetaTool and ToolBench show the same results: as toolset sizes scale past 30–50 items without structured routing, error rates spike rapidly due to description collision and noise. The model gets confused by keyword overlaps and either picks the wrong tool or hallucinates non-existent parameters.

Okay, in this blog, I'm talking about skills, not tools. But the principle is the same. Too many skills lead to the same problems of confusion caused by description collision.

We want:

Our agent to pick the right skills with a high degree of accuracy.
To avoid burning unnecessary tokens.

I need a way to optimise my installed skills!

Why Do I Have So Many Skills?

Before I start pruning my skills, I need to understand why I have so many.

I went back and reviewed my Git history to trace how I got here. Here's what I discovered:

Google Cloud & AI knowledge: Over 120 skills pulled from official Google repositories, including google/skills, google/agents-cli, google-gemini/gemini-skills, and GoogleCloudPlatform/vertex-ai-creative-studio. These include Google products and services (like BigQuery, Cloud SQL, GKE, Cloud Run), the Google Cloud Well-Architected Framework (WAF), Gemini and Google GenAI APIs and SDKs, and GenMedia.
Dazbo Agent Skills: Custom skills I wrote for derailed-dash/dazbo-agent-skills for documentation, blogging, security, installing automated PR code reviews, skill organisation, and deployment.
Core Software Engineering & Best Practices: 25 skills adopted from Addy Osmani's addyosmani/agent-skills repository covering TDD, code review, debugging, interface design, context engineering, and software delivery workflows.
Research, Strategy & Technical Writing: 5 specialised skills installed from Shubham Saboo's shubhamsaboo/awesome-llm-apps repository (deep-research, fact-checker, strategy-advisor, technical-writer, content-creator).
Specialised & Community Skills: Niche skills sourced from specific community repositories, including wshobson/agents (documentation-and-adrs, interview-me), coreyhaines31/marketingskills (seo-audit), remotion-dev/skills (remotion-best-practices), and vercel-labs/skills (find-skills).

Here is the complete breakdown of the 170 skills I had installed, grouped by category and origin repository:

Group / Category	Count	Source Repository / Origin Link	Summary of Included Skills
Google Cloud Core Services & WAF	82	`google/skills`	GCP product & infrastructure guides (BigQuery, Cloud SQL, AlloyDB, GKE, Cloud Run, Firebase), Well-Architected Framework (WAF) pillars, networking, and developer APIs (Google Ads, Analytics, Mobile Ads).
Addy Osmani Engineering Workflows	25	`addyosmani/agent-skills`	SDLC & software engineering workflow heuristics covering TDD, code review, debugging, context engineering, spec-driven development, and interface design (orchestrated via `using-agent-skills`).
Google Agent Platform & ADK CLI	20	`google/agents-cli`	Agent Development Kit (ADK) CLI lifecycle tools (scaffolding, testing, evaluation, deployment, publishing) and server-managed Agent Platform resource handlers.
Specialised & Community Skills	14	Various Community Sources	Niche tools and community extensions including Dev.to formatting, Playwright browser testing, Remotion React video, SEO auditing, Python dependency management, and skill discovery (`find-skills`).
Gemini API & GenAI SDKs	10	`google-gemini/gemini-skills`	Technical integration guides for the Gemini API (`google-genai` SDK), multimodal streaming, Live API, NotebookLM auth, and server-managed interactions.
Google GenMedia & Creative Studio	8	`vertex-ai-creative-studio`	Specialised role personas for multimedia production (audio engineering, image generation, video editing, voice direction, script producing, story generation).
Dazbo Custom Agent Skills	7	`derailed-dash/dazbo-agent-skills`	Personal workflow automation for documentation maintenance, blog writing (`dazbo-content`), secrets management (`git-crypt`), UTM link tagging, PR review actions, skill organisation, and deployment.
Awesome LLM Apps (Research & Content)	5	`shubhamsaboo/awesome-llm-apps`	Autonomous research, fact-checking, strategy advisory, and technical documentation generation workflows.
TOTAL	170

So you can see how easy it is for your skills base to get out of hand! Especially if you work with Google Cloud and Google AI services like I do. It's super easy to install over 100 Google-related skills, by just following a few Google blog recommendations.

Next Question: Do I Need Them All?

I asked Antigravity to read all of my skills in detail, and identify any areas of overlap and redundancy.

There was a LOT of redundancy! We uncovered seven major categories of overlap, duplication, and inefficiency:

Exact Byte-for-Byte File & Naming Duplicates: In google/skills, the skill directory gemini-agents-api declared name: gemini-managed-agents-api in its frontmatter. This directory vs. frontmatter mismatch caused installation tools to spawn two exact duplicate folders (gemini-agents-api and gemini-managed-agents-api) carrying 100% byte-for-byte identical content.
Deprecated SDKs vs. Modern APIs: Older skills still provided code snippets using the deprecated google-generativeai package and obsolete model strings, directly contradicting modern google-genai SDK standards and confusing the agent during code generation.
API Guide Overlaps & Fragmentation Across Repositories: The gemini-api skill in google/skills (which exists as an enterprise Agent Platform guide) collided directly with gemini-api-dev in google-gemini/gemini-skills. Installing across multiple Google repositories resulted in competing guides for the same underlying APIs (gemini-api, gemini-api-dev, gemini-agents-api, gemini-interactions-api, and gemini-live-api-dev).
Irrelevant Domain Bundles (The Monolithic Repo Problem): Pulling down the monolithic google/skills repository imported mobile advertising suites (Android/iOS banner ads, Unity SDKs) that had zero relevance to cloud backend architecture and agent development.
Hierarchical Sub-Skill Redundancies (The Meta-Skill Tax): 25 individual SDLC skills from addyosmani/agent-skills (such as test-driven-development and code-review-and-quality) were loaded into system prompt context at startup, despite being child sub-skills already orchestrated on-demand by using-agent-skills. Similarly, 20 sub-skills from google/agents-cli were loaded continuously rather than routed via google-agents-cli-workflow.
Tooling & MCP Surface Overlaps: Standalone tools like the adk-docs-mcp server were redundant because google-developer-knowledge already indexes ADK documentation (adk.dev).
Capability & Persona Redundancies: documentation-and-adrs (addyosmani/agent-skills) was a duplicate of architecture-decision-records (wshobson/agents), while generic content-creator (shubhamsaboo/awesome-llm-apps) collided with my custom dazbo-content persona.

What Else Did I Discover?

Beyond the sheer volume of redundant skills, I made another cool discovery: many skill collections come with a "parent" Meta-Skill.

When you install a large collection of skills — such as Addy Osmani's engineering skills (addyosmani/agent-skills), or Google's 20 Agent Platform skills (google/agents-cli) — your instinct is to leave all 20 to 25 skills enabled in your workspace. I mean... Why wouldn't you?

However, these skill suites are designed to be hierarchical:

addyosmani/agent-skills: Orchestrated by the using-agent-skills meta-skill.
Google ADK & Agent Platform: Orchestrated by the google-agents-cli-workflow meta-skill.
GCP Data Pipelines: Orchestrated by the gcp-data-pipelines meta-skill.

In each case, the parent meta-skill is supposed to work as a sort of skills index or decision tree. When a specific task comes in — such as writing unit tests or running a security audit — the parent meta-skill directs the agent to fetch and read only the specific child sub-skill from disk on demand.

Conclusion? We don't need to load the frontmatter of all the child skills. We only need the parent skill! In the examples above, I can easily replace nearly 50 skills with just 3 orchestration skills!

So now I could implement a solution to organise my skills. The primary objectives:

Remove skills that are truly redundant.
Prevent Level 1 skills loading (i.e. reading frontmatter into context) for skills that have parent meta-skills. For these, only pre-load the parent meta-skills.

Clarifying Skill States

To design a lean agent workspace, we must be crystal clear on the three distinct states a skill can occupy throughout its lifecycle. They can be:

Installed and inactive (discoverable).
Installed and excluded.
Activated.

Let's define these in more detail:

Installed and inactive (discoverable): These skills are present on disk and discoverable by our agent. When the agent (e.g. Antigravity) starts, their frontmatter is automatically read into context.
Installed and excluded: These skills reside in your disk library but are excluded from automatic Level 1 loading. For these, the agent does not automatically read their frontmatter and is therefore not directly aware of them during your conversation with it. But because they are present on disk and available to the agent, they can still be explicitly activated.
Activated: This is the runtime state when a skill's full SKILL.md body has been loaded into the current turn context, i.e. Level 2 loading (and Level 3, where supporting files are present and appropriate).

Crucially, both installed and inactive and installed and excluded skills can transition into this Activated state.

Excluding Skills

So now we know that a good optimisation strategy is to use exclusion to prevent a bunch of skills being loaded at startup into the "Installed and inactive" state.

But how can we do this?

In Google Antigravity, global skill exclusions are managed via ~/.gemini/config/skills.json (or .agents/skills.json for workspace-level skills).

The native exclude array accepts skill folder names. For example:

{
  "exclude": [
    "alloydb-basics",
    "cloud-spanner-migrations",
    "firebase-basics"
  ]
}

Any skill listed in the exclude array is completely skipped during Tier 1 discovery. Its frontmatter is therefore not injected into the system prompt, saving tokens instantly.

So this is easy!

But here's a cool trick. You can easily "un-exclude" a skill by prefixing its name with // inside the quotes. This is useful because it allows us to re-enable up-front skill loading, without having to check our disk to find the skill and its name.

So my approach is to always have all my available skills in the exclude list, but to comment-out the ones that need to be discovered automatically.

Note: I have the // inside the quotes. Why? Because this is not valid JSON:

{
  "exclude": [
    //"alloydb-basics",
    //"find-skills",
    "firebase-basics"
  ]
}

But this is:

{
  "exclude": [
    "//alloydb-basics",
    "//find-skills",
    "firebase-basics"
  ]
}

And because the exclude list uses exact string matching, you can use this // trick to enable/exclude skills on the fly, without having to remove the skill from the exclude list entirely.

In the example above:

alloydb-basics and find-skills are not excluded, so they are auto-discovered on startup and their frontmatter is loaded into context.
firebase-basics is excluded, so it is not auto-discovered on startup and its frontmatter is not loaded into context.

Now we've got everything we need to implement a repeatable mechanism to organise and clean up our skills.

Irony and Guitars: I Made a Skill!

Because: when you've got too many skills, you definitely need one more. (In this way, skills are a lot like guitars, or cats.)

Anyway, based on what I learned, I created a skill that:

Identifies duplicative skills and recommends complete removal of those that are redundant.
Identifies which skills are orchestrated by a parent meta-skill and excludes the child skills from automatic discovery.
Identifies skills which look particularly niche or rarely used, and recommends excluding these also. They can always be included later, or even activated by explicitly asking the agent to do so.

Let's see how it performs! After installing my skill, I said to Antigravity:

"Optimise my skills please"

Outcomes of Optimising

My skill ran and presented this proposal summary table:

Metric	Baseline (Unoptimised)	Proposed (Optimised)	Delta / Savings
Installed Skills Directories	170	165	-5 (-2.9%)
Installed & Discoverable Skills	170	49	-121 (-71.2%)
Installed & Excluded Skills	0	116	+116
Prompt Token Overhead	~17,000 tokens	~3,350 tokens	-13,650 tokens (-80.3%)

It goes on to say:

Upon your confirmation, I will execute the following steps:

1. **Retire Redundant Skills**: Delete the 5 redundant skill directories
   (`gemini-managed-agents-api`, `liveapi-service`, `documentation-and-adrs`, 
   `gemini-api-dev`, `gemini-live-api-dev`) from `~/.gemini/config/skills/`.
2. **Generate Optimised `skills.json`**: Write the full-inventory `~/.gemini/config/skills.json` 
   with 49 active skills (`//` prefix) and 116 excluded skills.
3. **Verify Context Footprint**: Re-audit the active skill prompt token overhead to confirm 
   successful reduction to ~3,350 tokens.

---
> [!IMPORTANT]
> **Mandatory Guardrail Confirmation**: In accordance with `organise-agent-skills` guardrails, please confirm if you would like me to proceed with deleting the 5 redundant skill directories and creating the optimised `~/.gemini/config/skills.json`.

By trimming back to a core of 49 active skills and delegating the rest to meta-skills and on-demand rules:

We slashed system prompt overhead by approximately 13,650 tokens; that's an 80.3% reduction.
We saved over 400,000 tokens per pair-programming session.
Agent response latencies dropped noticeably.
Tool selection precision increased because the agent was no longer fighting distractor noise from over 100 overlapping skill descriptions. Instead of having a mild existential crisis every turn trying to choose between five different Gemini SDK guides, the agent simply picks the right tool and gets on with the job.

Summary & Conclusion

Agent skills are awesome. They're so easy to find, install and use. But when we allow skills to sprawl unchecked, we start confusing our agents. This impacts accuracy, reliability, performance, and cost.

So increasingly, we need a way to manage and optimise our skills. For this, I've done some work so you don't have to!

Feel free to download my optimisation skill off-the-shelf:

# Install all the Dazbo Agent Skills
npx skills add https://github.com/derailed-dash/dazbo-agent-skills

# Install just the `Organise Agent Skills` skill
npx skills add https://github.com/derailed-dash/dazbo-agent-skills --skill organise-agent-skills

Or if you have the Vercel find-skills skill installed, you can just ask your agent:

"Install dazbo-agent-skills for me."

So, that's it, folks. Go forth and optimise. If you find this skill useful, please give the repo a star.

Have you experienced Skills Sprawl in your agentic environment? How many skills are currently active in your setup? Let me know in the comments below!

Before You Go

Please share 📢 this with anyone that you think will be interested. It might help them, and it really helps me!
Please give me loads of reactions / hearts! 💖
Please leave a comment 💬. Interaction is good!
Add a star ⭐ on my repos!
Follow 👉 and subscribe 🔔, so you don’t miss my content.

References and Useful Links

Standards, Hubs & Agent Platforms

Key Agent Skills Repositories

Academic Research & Benchmarks

Paper: “How Many Tools Should an LLM Agent See? A Chance-Corrected Answer” (Repantis et al., May 2026)
Berkeley Function Calling Leaderboard (BFCL)

Finally — Hard Caps to Limit Your Google Cloud Spend

Darren "Dazbo" Lester — Wed, 29 Jul 2026 09:49:50 +0000

TL;DR

For years, Google Cloud budget alerts were purely informational. They sent an email while your project quietly burned through your savings.

I built my own Pub/Sub Killswitch to sleep peacefully at night, but it requires a bit of plumbing to install. What we really wanted was an easy option in the Google Cloud Console.

Good news! Google has finally introduced native Cloud Spend Caps (currently in Public Preview). You can now hard-cap spend per service so an unexpected API leak or runaway script hits a 403 Permission Denied wall instead of creating a $10,000 bill.

Here is how it works, how fast it triggers, and what you need to know…

What’s the Problem?

Over the last couple of years I’ve read weekly horror stories about individuals getting hit for thousands, or even tens of thousands of dollars of unexpected costs from Google Cloud.

Do a quick Google search, and you’ll find examples like…

“Google Cloud customer wakes up to $18,000+ bill despite $7 budget, thanks to forgotten API key in published project — attacker put in 60,000+ requests and blasted through $1,400 spending cap” — Tom’s Hardware, April 2026
Got hit with a $65,000 bill overnight from GCS due to a spike in list object calls — Reddit, December 2025
Google Cloud billed me ~$19,000 USD (~R$105,000 BRL) after an API key breach — and the charges keep growing even after I deleted everything — Reddit, May 2026

The big problem that most folks don’t understand is this:

GOOGLE BUDGET ALERTS WERE NOT HARD LIMITS. THEY DID NOT PREVENT YOU FROM SPENDING MORE THAN YOUR BUDGET.

Most of the examples I see follow the same pattern…

A user follows Google best practice and sets a budget alert on their project. Say, $50 dollars per month.
They go to bed.
They wake up owing thousands.

Reading these stories was causing me so much distress. Both for the many people getting caught out, but also because the same thing happening to me felt like an inevitable ticking time bomb.

In theory, I know more about Google Cloud than the average punter. I’m supposed to be a Google Developer Expert (GDE) and Google Ambassador, after all!

But still I was terrified! And I know at least a couple of fellow GDEs that have been hit with this. Which just goes to show: even if you know a lot about Google Cloud and think you’re doing everything right, it’s still possible to get caught out.

And since Google didn’t offer any hard limit (aka hard cap) mechanism, there was literally no off-the-shelf solution.

So I Built My Own Killswitch

I built a mechanism that responds to budget alerts by detaching billing from whatever project(s) is/are associated with that alert. Sure, you can still get billing alert delays, but this mechanism typically stops any offending project inside of an hour of costs exceeding your budget. And this could be the difference that turns a £10,000 unexpected bill into a $100 unexpected bill. My solution is free and easy to install. And I blogged about it here.

Using it requires a bit of setup…

You need to create your budget alerts, of course.
You need those alerts to be sent to a Pub/Sub topic that you create.
You need to deploy a Cloud Run Function that does the actual work of responding to the alert and disconnecting a project.
You need to wire-up that Cloud Run Function such that it is triggered by events on the Pub/Sub topic.
You need pay careful attention to the roles you assign to the service account that runs this Cloud Run project — particularly if you happen to have many different Google Cloud projects.

Even though the solution is well-documented and all of the above is scripted, it’s still a fair bit of work. It can be daunting for many.

I spoke to Google about this. A lot.

Google Introduced Cloud Spend Caps!

They delivered!

I tested this out in Private Preview over the last couple of weeks, but it went public today! So now y’all can use it too.

Setting Up a Spend Cap

First, create a Budget in the Google Cloud Console. Same place as before…

Traditionally, you would then set the amounts and then you’d see these available actions…

But NOW you have the option to select “Spend cap enforcement” when you create the budget.

If you select this, you MUST then specify a service. (Currently you can only select one.)

Note that if you use the “Spend cap” type, you can no longer select the option to publish to Pub/Sub:

Once created, the new budget alert looks like this. Note how this new alert says “Spend cap status: Configured”.

Trying It Out

I started running up some cost on my Gemini API inside this project.

Ooh, look! Inside my CI/CD pipeline I can see it’s hit a “403 — permission denied”.

And I got this email, almost immediately.

It’s not too subtle! You’re gonna struggle to miss this in your inbox!!

We can take a look in Cloud Console to see more information:

Okay, successful test! It worked exactly as we wanted it to.

How to Lift the Cap?

What if we want to continue working with our service? In that case, we just need to lift the spend cap.

Open your budget and then click on “Lift spend cap” in the Console:

You’ll see this message:

Now you need to specify a new, higher amount:

You get a warning that it might take an hour to lift the cap. But for me, it took about 2 minutes:

Then I received these two emails, nearly immediately:

Spend cap updated:

So when you’re working with spend caps, you always know exactly what’s going on.

How Does This Differ From Spend Caps in AI Studio?

It works the same way. But AI Studio only lets you set spend caps associated with Gemini API keys.

The Most Frequently Asked Question…

One of the biggest historical problems with budget alerts, and anything that leverages them (like my Billing Killswitch) is that the alerts are only triggered after billing cycle reconciliation. This results in a delay between your actual spend, and billing alerts firing. This delay could be hours. A lot of damage can be done to your credit card in a few hours!

With the new spend capping feature, Google promises that “near real-time enforcement”, with the caps triggering within minutes of actual spend thresholds being met. In my testing, it triggered within a couple of minutes.

Two minutes rather than two hours? I’ll take it!

Maybe, in the near future, we might expect some closer integration with the new Anomaly Detection feature. Wouldn’t it be nice if we had a toggle to enable capping to trigger based on the prediction of a spend cap being hit in the next few minutes or hours? (For the SREs out there… This would be a similar approach to setting alerts based on the rate of error budget consumption.)

Anyway, that’s my prediction. Let’s see!

Spend Cap Limitations?

Just a couple that I noticed.

At the moment, you have to set these caps one service at a time. It would be better if we could pick multiple services. So for now, I’ll still be using my Killswitch mechanism when I want to limit billing across the whole project or collections of projects.
At the moment, you can’t have a cap and ALSO send a message to Pub/Sub. That might be useful for some.

Wrapping Up

Native Cloud Spend Caps are an absolute game-changer. They provide the one thing cloud engineers have been begging for: actual, deterministic spend boundaries. If you’re building with high-throughput APIs like Gemini, get this configured immediately.

Good architecture isn’t just about high availability — it’s about keeping your wallet intact!

Before You Go

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

Useful Links and References

Building a Multi-Agent FinOps Solution with Google ADK, Levering Tools, MCP and Google-Managed Assistants

Darren "Dazbo" Lester — Sun, 26 Jul 2026 06:10:51 +0000

Welcome Back!

We’re continuing our FinSavant series. In the previous two parts we:

Looked at the overall goals and architecture
Setup our development environment, fully loaded with MCP servers and agent skills

In this part we’re going to take a close look at the agent code. We’ll be looking at:

The various agents that make up the solution, and their tools.
Different multi-agent orchestration patterns, and the pattern we selected for FinSavant.
How we handle cross-cutting concerns across agents.
Testing with ADK Web
Optimisation
Building and Testing a FastAPI Backend-for-Frontend

I’ll explain concepts and provide code snippets as we go. But don’t forget: you can always refer to the full code in the repo.

Let’s get cracking!

Series Orientation

First, a quick reminder of where we are in the series:

Goals, Architecture, and Tech Stack: Capabilities, project goals, target architecture, technology stack, and design decisions.
Dev Environment Setup with Google Antigravity, ADK, Agents CLI, MCP & Skills
Building the ADK Agent and API 📍 You are here.
Designing and Building the UI with Google Stitch and A2UI
Deployment with Gemini Enterprise Agent Platform, Agent Runtime, Cloud Run and IAP
Automating Deployment with CI/CD and Terraform
Agent Observability, Evaluation, and Tuning with Gemini Enterprise Agent Platform

Deciding on Our Agents

FinSavant is a FinOps solution that needs to do many different tasks. We could have one giant agent with a huge monolithic prompt. But this is an antipattern because:

The prompt becomes unwieldy.
It’s too complicated to manage the possible journeys and workflows the prompt needs to manage.
The agent is more likely to not follow the rules.
We have to give our giant agent access to all the tools, meaning it’s less likely to pick the right one for a task.
The agent is ultimately less reliable and less consistent.

A much better approach is to have individual agents that each have a clear purpose, and which each have a limited set of tools they can use. We can then have a root agent that orchestrates the agents and decides which agent to use for each task.

Something like this:

So this is what we’re going to build!

Agent Directory Structure

Let’s deep-dive on the /agent directory:

smart-gcp-finops/
├── agent/                     # Core ADK Agent & Agent Runtime package
│   ├── finops_agent/
│   │   ├── agents/                  # Subagent definitions
│   │   │   ├── billing_explorer_agent.py       # BigQuery spend trends & cost breakdown subagent
│   │   │   ├── cloud_advisor_agent.py          # Cloud Assist & operational diagnosis subagent
│   │   │   ├── infrastructure_auditor_agent.py # Idle/zombie resource waste audit subagent
│   │   │   ├── knowledge_assistant_agent.py    # Developer Knowledge & best practice grounding subagent
│   │   │   └── root_cause_analyst_agent.py     # Spend anomaly, Audit Logs, and CAI correlation subagent
│   │   ├── app_utils/               # Shared tools and utilities
│   │   │   ├── a2a.py                    # Agent-to-Agent (A2A) protocol endpoints
│   │   │   ├── cai_tools.py              # Cloud Asset Inventory ADK tool wrappers
│   │   │   ├── cai_utils.py              # Cloud Asset Inventory API search & history helpers
│   │   │   ├── context.py                # Session context state helpers
│   │   │   ├── credentials.py            # ADC and Service Account auth helpers
│   │   │   ├── dashboard_data.py         # Pre-computed spend analysis & UI dataset generator
│   │   │   ├── logging_and_telemetry.py  # Cloud Logging & Audit Logs intra-day telemetry
│   │   │   ├── mcp_config.py             # Remote MCP toolsets & OAuth2 auth providers
│   │   │   ├── project_discovery.py      # Dynamic Google project hierarchy discovery
│   │   │   ├── services.py               # ADK services
│   │   │   ├── tools.py                  # BigQuery spend analysis & SQL execution tools
│   │   │   ├── typing.py                 # Pydantic schemas & structured output models
│   │   │   ├── zombie_resources.py       # Idle & zombie GCP resource detection logic
│   │   │   └── zombie_tools.py           # Tools for zombie waste auditing
│   │   ├── agent.py                 # Root agent
│   │   ├── callbacks.py             # Global callbacks
│   │   ├── client.py                # Gemini & MCP client initialisation
│   │   └── config.py                # Agent config
│   └── pyproject.toml         # Agent package dependencies
├── bff/                       # Backend-for-Frontend FastAPI service
├── docs/                      # Documentation
├── frontend/                  # React UI
├── scripts/                   # Helper & environment scripts
├── tests/                     # Unit & integration test suites
├── Dockerfile                 # Unified dev container build
├── Makefile                   # Development & deployment convenience
└── pyproject.toml             # Root workspace dependencies

You might be wondering about the directory naming here — why do we have agent/, then finops_agent/, and then agents/?

It might look a bit repetitive at first glance, but there’s clear logic behind it:

agent/:

This is our top-level monorepo component folder, sitting alongside /bff, /frontend, and /deployment. It houses all build manifests (pyproject.toml, Dockerfile) and dependencies specific to the agent backend. This will be important later when we deploy to the Agent Runtime.
finops_agent/:

This is the actual Python package directory. By using a distinct package name rather than agent, we avoid Python module name collisions and allow clean, explicit imports (e.g. from finops_agent.agent import root_agent). This is also the standard layout expected by ADK's agents-cli tooling.
agents/:

This nested directory houses our individual subagent definitions (billing_explorer_agent.py, cloud_advisor_agent.py, etc.). Separating them into their own module keeps the subagents isolated from the root coordinator (agent.py), global callbacks (callbacks.py), and utilities (app_utils/).

The Specialised Agents & Their Tools

With our directory structure in place, let’s look at each of our agents in detail:

1. `FinOpsCoordinator` (Root Agent)

Purpose: Serves as the front door and central router for all user queries.
Model: gemini-3.5-flash-lite.
Tools: Uses zero direct tools, e.g. no SQL or Cloud Asset Inventory access. Its sole capability is delegating to specialised subagents using ADK’s native agent routing mechanisms.
Selective Routing Rules: Prompt instructions strictly enforce selective delegation. For example, if the user asks solely about costs, it delegates exclusively to BillingExplorer, avoiding wasteful multi-agent sweeps.

Here’s a snippet of the code:

AGENT_INSTRUCTION = """You are the FinOpsCoordinator root agent.
Your primary role is to receive user requests, understand their intent, 
and delegate cost analysis, auditing, optimization, and Q&A tasks to the appropriate 
specialist subagents:

1. BillingExplorer: Use for spend aggregates, SKU prices, cost trends, forecasting, 
   and Cost Explorer (explorer/dashboard) dashboards.
2. InfrastructureAuditor: Use for auditing zombie resources like idle static IPs 
   or unattached disks (recommendations dashboard).
3. CloudAdvisor: Use for active GCP rightsizing and resource-level cost/performance 
   optimisations.
4. KnowledgeAssistant: Use for general GCP Q&A and grounding recommendations in 
   official architectural guidelines.
5. RootCauseAnalyst: Use for analyzing cost spikes by correlating BigQuery 
   spend shifts with CAI configuration change history.

CRITICAL SELECTIVE ROUTING AND A2UI PRESERVATION RULES:
1. You MUST only delegate tasks to the specific subagent(s) directly relevant 
   to the user's request.
   - If the user only asks about costs, spend trends, SKU prices, or budgets, 
     ONLY invoke BillingExplorer.
     Do NOT invoke CloudAdvisor or InfrastructureAuditor.
   - If the user asks for active recommendations, rightsizing, or optimizations, 
     identify the top active cost-driver services and projects already discovered 
     in conversation history (e.g. Vertex AI, Gemini API, BigQuery), 
     and pass those specific services/projects when delegating to CloudAdvisor.
   - If the user asks to "Audit Best Practices" or assess services against 
     GCP architectural guidelines, identify the top cost-driving services from 
     conversation history (e.g. Vertex AI, Gemini API, BigQuery) and ONLY 
     invoke KnowledgeAssistant to retrieve official GCP architectural best practices 
     and citations for those specific services.
   - If the user only asks about zombie resources, idle IPs, or unattached disks, 
     ONLY invoke InfrastructureAuditor.
2. Do NOT run a full multi-agent audit (calling multiple subagents) unless the user 
   explicitly requests a "full audit", "comprehensive review", "complete environment analysis,
   or asks a multi-faceted question that spans multiple domains.
   Keep simple queries fast and single-scoped!
3. CRITICAL A2UI PAYLOAD PRESERVATION:
   When a subagent (such as BillingExplorer or InfrastructureAuditor) returns a response 
   containing structured ```

json+a2ui ...

 ``` code blocks, you MUST preserve and 
   re-emit those exact ```

json+a2ui ...

 ``` code blocks unchanged in your final output 
   so the React frontend can render dynamic A2UI dashboard components!

RESPONSE SYNTHESIS & HELPFULNESS GUIDELINES:
1. Executive Summary First: Always lead with a crisp 1-2 sentence summary directly 
   answering the user's prompt (e.g. total spend, primary cost driver, top recommendation).
2. Scannable & Structured Formatting: Use clear Markdown headings, bold key financial metrics
   (e.g. **£41.34 GBP**), and scannable bullet points.
3. Proactive & Actionable Next Steps: Conclude with a helpful, context-aware follow-up 
   suggestion (e.g. offering to analyze cost spikes on a specific project, query rightsizing options).
4. Tone: Senior FinOps advisory tone — professional, precise, and encouraging without unnecessary boilerplate.
"""

root_agent = Agent(
    name="root_agent",
    model=ConfiguredGemini(
        model=settings.fast_model,
        retry_options=types.HttpRetryOptions(attempts=3),
        use_interactions_api=False,
    ),
    instruction=AGENT_INSTRUCTION,
    tools=[],
    sub_agents=[
        billing_explorer,
        infrastructure_auditor,
        cloud_advisor,
        knowledge_assistant,
        root_cause_analyst,
    ],
    before_agent_callback=[
        before_agent_clean_history,
        before_agent_reset_tool_call_counter,
        before_agent_discover_projects,
        before_agent_cache_lookup,
    ],
    before_tool_callback=before_tool_check_limit,
    before_model_callback=before_model_bypass,
    after_agent_callback=after_agent_save_cache,
)

app = App(
    root_agent=root_agent,
    name="finops_agent",
    context_cache_config=ContextCacheConfig(
        min_tokens=2048, # Trigger caching for large prompts/histories on Vertex AI / Gemini
        ttl_seconds=600, # Store the cache for up to 10 minutes
        cache_intervals=10, # Refresh after 10 turns
    ),
    plugins=[DefensiveToolErrorPlugin(), FinOpsTelemetryPlugin()],
)

There’s a few interesting things to note about this agent:

We set the model to settings.fast_model. This is configured by an environment variable and here we've set it to gemini-3.5-flash-lite. We use this here for fast, low-cost responses and routing. We don't need heavy reasoning in the orchestrator agent.
We tell the root agent about all the subagents it can delegate to in the sub_agents parameter.
It has no tools!
Native Gemini context caching is enabled. This caches pre-processed system instructions, subagent definitions, and conversation history. Why is this useful? In a multi-turn chat session, without caching, the LLM has to re-parse and re-tokenise the exact same large system instructions and tool/subagent declarations on every single turn. Context caching slashes input token costs by up to 75–90% and significantly reduces time-to-first-token (TTFT) turn latency. Booyah!
There are agent callbacks (defined on root_agent) and global application plugins (defined on App) for managing lifecycle hooks across the execution loop.

Quick Aside: ADK Callbacks vs App Plugins

In ADK, lifecycle hooks allow deterministic Python functions to execute at specific points in the execution pipeline, i.e. before/after an agent runs, before/after a model call, or before/after a tool executes.

However, there is an important distinction between Agent-level Callbacks and App-level Plugins:

Agent-Level Callbacks:

Attached to a specific agent (like root_agent). These fire once when that specific agent initiates its execution. For instance, before_agent_discover_projects runs on the root_agent at the very start of a user turn. It calls the Cloud Billing API (billingAccounts.projects.list) to retrieve all linked GCP project IDs and populates session.state['allowed_projects']. Because this happens before delegating, every subagent can simply read allowed_projects from session state. We don't re-run the API call for subagents!
App-Level Plugins (BasePlugin):

These are registered globally on the App container via App(plugins=[...]). They subclass BasePlugin and hook into every agent turn and tool call across the entire hierarchy (root coordinator and subagents alike).

Here are a few concrete examples of how we leverage callbacks and plugins in FinSavant:

Error Handling (DefensiveToolErrorPlugin): Globally intercepts unhandled tool exceptions across any subagent, storing formatted errors in session state so the coordinator can inform the user gracefully without crashing the process.
Logging and Telemetry (FinOpsTelemetryPlugin): Automatically instruments OpenTelemetry spans; logs agent handoffs, model execution latency, and token consumption across all turns.
Dynamic Project Discovery (before_agent_discover_projects): Attached to root_agent. Fires once at turn start to discover live GCP project IDs and write them to session.state['allowed_projects'].
Subagent History Cleaning (before_agent_clean_history): Attached to root_agent. Fires before the root agent processes a subagent's return, converting subagent finish_task responses into plain-text user context.
Turn-Level Response Caching (before_agent_cache_lookup & after_agent_save_cache): Attached to root_agent. This checks the current issued prompt before execution. It uses the fast model to determine if this prompt is semantically very similar to a previous prompt in the conversation. If it is, we can return a response from the cached responses. Instead of duplicating logging or exception handlers inside every subagent constructor, ADK allows registering global plugins on the root App:
Tool Call Limiting (before_tool_check_limit): Attached to root_agent. This callback enforces a tool ceiling per turn, ensuring that we don't end up with runaway subagent loops that try to make tool calls dozens of times.

def before_tool_check_limit(tool: Any, args: dict[str, Any], tool_context: Any) -> None:
    """Defensive callback to count and limit tool calls in a single turn to prevent runaways."""
    count = tool_context.state.get("_turn_tool_call_count", 0) + 1
    tool_context.state["_turn_tool_call_count"] = count
    logger.debug(
        "Tool call #%d in this turn: executing %s with arguments: %s",
        count,
        tool.name,
        args,
    )
    if count > settings.max_tool_calls_per_turn:
        logger.error(
            "Defensive stop triggered: Tool call count exceeded limit of %d!",
            settings.max_tool_calls_per_turn,
        )
        raise RuntimeError("Defensive stop: too many tool calls executed in a single turn.")

Neat, right?

2. `BillingExplorer` (Spend Aggregation & Dashboards)

Model: gemini-3.6-flash.
Tools: get_precomputed_spend_analysis, execute_cached_bigquery_sql, native BigQueryToolset, get_session_value, set_session_value.
Responsibilities: Aggregates Month-to-Date (MTD) spend, analyzes SKU costs, forecasts end-of-month spend, and constructs structured explorer and dashboard JSON+A2UI payloads for the React canvas. (More on that in a later part, naturally!)

from finops_agent.app_utils.tools import (
    BLACKBOARD_KEY_INSTRUCTIONS,
    execute_cached_bigquery_sql,
    get_precomputed_spend_analysis,
    get_session_value,
    set_session_value,
)
from finops_agent.app_utils.typing import TaskOutput
from finops_agent.client import (
    ConfiguredGemini,
    bigquery_toolset,
)
from finops_agent.config import settings

BILLING_EXPLORER_INSTRUCTION = """You are the BillingExplorer subagent.
Use the `get_precomputed_spend_analysis` tool to retrieve pre-computed cloud costs, period-over-period trends, cost drivers, cost forecasts, and Secret Manager/GCS zombie waste metrics. Pass the `days` parameter matching the timeframe requested by the user (e.g. `days=7` for 7 days, `days=14` for 14 days, `days=30` for 30 days, `days=60` for 60 days, `days=90` for 90 days; default to 30 if unspecified).

CRITICAL COST FORECASTING & TOOL SELECTION RULES:
1. For ALL spend queries, cost trend analysis, and cost forecasting (including prompts like "Run Cost Forecast", "Future Trend", "Projected Spend"), ALWAYS call `get_precomputed_spend_analysis(days=...)`.
2. `get_precomputed_spend_analysis` ALREADY computes the Month-to-Date (MTD) spend, period-over-period trends, and the projected end-of-month spend forecast in Python instantaneously.
3. Do NOT attempt to run standard SQL queries or construct custom BigQuery ML statements (`CREATE OR REPLACE MODEL`, `ML.FORECAST`) directly if `get_precomputed_spend_analysis` is available.
4. NEVER execute multi-query loops or attempt dataset/model creation. Use the result returned by `get_precomputed_spend_analysis` to generate the complete report in a single tool call!

Based on the dictionary returned by `get_precomputed_spend_analysis`, generate a concise final report:
1. Total Spend and currency.
2. Top Cost Drivers by Service.
3. Period-over-Period Changes & Trends (percentage changes).
4. Major cost spikes (date and service/cost).
5. Zombie/inactive waste (secrets, buckets, etc).

< trimmed for readability >

CRITICAL: CONCISE SYNTHESIS RULE
Write your report in a highly concise style. Keep the markdown text under 250 words total.

CRITICAL COORDINATION AND TERMINATION RULES:
1. Call `finish_task` and pass the complete final markdown report directly into the `result` parameter.
2. Once you have generated the report and returned it via `finish_task`, stop execution.
"""

billing_explorer = Agent(
    name="billing_explorer",
    description="Specialised subagent for querying Standard and Resource-level billing tables, summarizing Month-to-Date (MTD) cloud costs, forecasting future spend, identifying top cost drivers, and generating Cost Explorer (explorer/dashboard) workspaces.",
    model=ConfiguredGemini(
        model=settings.model,
        retry_options=types.HttpRetryOptions(attempts=3),
        use_interactions_api=False,
    ),
    instruction=COMMON_AGENT_HEADER + "\n\n" + BILLING_EXPLORER_INSTRUCTION,
    tools=[
        get_precomputed_spend_analysis,
        execute_cached_bigquery_sql,
        bigquery_toolset,
        get_session_value,
        set_session_value,
    ],
    mode="task",
    output_schema=TaskOutput,
    disallow_transfer_to_peers=True,
    disallow_transfer_to_parent=False,
)

Some notes about this agent…

Here we use gemini-3.6-flash (in settings.model) rather than the fast(er) model. We need more reasoning power in this agent. So here we see another benefit of using separate subagents: we can use different models and parameters for each one.
It has no subagents, but it has several tools.
Some tools, like bigquery_toolset are out-of-the-box in ADK. Others are custom tools that I've written myself.

The bigquery_toolset allows the agent to interact with BigQuery (such as executing SQL queries) in response to natural language prompts. Let's take a look at how we configure this.

You can see I passed bigquery_toolset as a parameter to the tools list. We've defined this in finops_agent/client.py which serves as my centralised hub for client initialisation. Instead of having the root orchestrator and individual subagents instantiate their own SDK clients or tools independently, client.py sets up thread-safe, shared resources at the module level. Here I'll show you a few snippets from this file, for our BQ tools setup:

# Imports
import google.auth
from google.adk.integrations.bigquery import BigQueryCredentialsConfig, BigQueryToolset

from finops_agent.config import settings
# Other imports...
# Setup ADC and then configure BQ tools to use it
credentials, _ = google.auth.default()
credentials_config = BigQueryCredentialsConfig(credentials=credentials)
EXCLUDED_BQ_TOOL_KEYWORDS = {"execute", "query", "forecast", "anomalies"}

def bq_tool_filter(tool: Any, ctx: Any = None) -> bool:
    """Excludes certain BigQuery tools from the exposed tool list to prevent bypass of custom tools."""
    name = tool.name.lower()
    return not any(keyword in name for keyword in EXCLUDED_BQ_TOOL_KEYWORDS)

bigquery_toolset = BigQueryToolset(
    credentials_config=credentials_config,
    tool_filter=bq_tool_filter,
)

You can see I’ve added a tool filtering guardrail, which limits which of the out-of-the-box tools are exposed to the agent. For example, I don’t want to expose the standard SQL execution tools to the agent, as I want to use my custom tools instead, such as execute_cached_bigquery_sql and get_precomputed_spend_analysis.

Not a lot of code required!

Now, let’s take a look at one my custom tools: get_precomputed_spend_analysis. This bespoke tool performs some specific SQL queries. I've provided the queries I want it to execute in the function, since this is more token-efficient (and reliable) than getting Gemini to craft a SQL query for me in real-time. It's also much faster! (I'll talk a bit more about this later in this article.)

The tool’s description looks like this:

def get_precomputed_spend_analysis(
    days: int = 30, tool_context: ToolContext = None
) -> dict[str, Any]:
    """Pre-computes Month-to-Date (MTD) cloud costs, period-over-period trends, cost drivers, daily cost spikes, and Secret Manager/GCS zombie waste in Python for the given duration.
    Reuses cached BQ queries.
    """

    # Now I define the actual SQL queries and execute them
    # Skipping in the snippet for brevity

It’s very important that all of our custom tools have good descriptions — as docstrings — like this. This helps our agent always pick the right tool for a given task.

3. `InfrastructureAuditor` (Waste & Zombie Resource Auditing)

Model: gemini-3.6-flash.
Tools: list_zombie_resources, get_precomputed_spend_analysis, get_cai_metadata_for_resources, get_cai_history_for_resource.
Responsibilities: Scans for unattached Persistent Disks, idle static external IP addresses, inactive GCS storage buckets, and orphaned Secret Manager secrets. Generates recommendations JSON+A2UI payloads.

4. `CloudAdvisor` (Live Guidance Proxy)

Model: gemini-3.5-flash-lite.
Tools: cloud_assist_mcp_toolset.
Responsibilities: Proxies requests to Google Gemini Cloud Assist MCP for infrastructure recommendations.

This is a pretty simple agent that makes use of Google Cloud Assist.

Let’s look at the relevant code…

from finops_agent.app_utils.mcp_config import cloud_assist_mcp_toolset
# Other imports

CLOUD_ADVISOR_INSTRUCTION = """You are the CloudAdvisor subagent.
Use Gemini Cloud Assist tools (ask_cloud_assist, investigate_issue) to retrieve active rightsizing recommendations, perform operational issue diagnostics, and optimize performance/cost for active GCP resources.

CRITICAL OPERATIONAL DIAGNOSIS & RIGHTSIZING RULES:
1. OPERATIONAL ANOMALIES: If the session context or prompt indicates active operational errors (e.g. `today_operational_anomaly == True` or crash loops), use `investigate_issue` or `ask_cloud_assist` to query active GCP Monitoring alerts, failing services, and system diagnostics for the affected project/service.
2. DISCOVERED CONTEXT: BEFORE querying, inspect the prompt and session context for the top active services and projects ALREADY DISCOVERED in this session.
3. Focus all recommendation and diagnostic queries (`ask_cloud_assist`, `investigate_issue`) SPECIFICALLY on those identified active services and projects.
4. Do NOT output generic boilerplate recommendations for unconfigured services (like GKE or Compute Engine VMs if they are not driving spend). Every recommendation MUST be tailored directly to the discovered active workloads.

CRITICAL AUTH & FALLBACK RULES:
1. If `ask_cloud_assist` returns recommendations or diagnostic findings, compile them into a clear, structured report detailing estimated monthly savings or operational remediation steps.
2. If `ask_cloud_assist` returns a 403 Forbidden or permission error for certain projects:
   - Highlight any recommendations retrieved from accessible active projects.
   - For projects lacking Recommender permissions, provide high-value, actionable optimization guidance strictly tailored to the specific active services discovered in the environment.
3. Always invoke `finish_task` with your complete, formatted Markdown report in the `result` argument.
"""

cloud_advisor = Agent(
    name="cloud_advisor",
    description="Specialised subagent that calls Gemini Cloud Assist tools to retrieve active rightsizing recommendations, perform operational issue diagnostics, and optimize performance/cost for active GCP resources.",
    model=ConfiguredGemini(
        model=settings.fast_model,
        retry_options=types.HttpRetryOptions(attempts=3),
        use_interactions_api=False,
    ),
    instruction=COMMON_AGENT_HEADER + "\n\n" + CLOUD_ADVISOR_INSTRUCTION,
    tools=[
        cloud_assist_mcp_toolset,
        get_session_value,
    ],
    mode="task",
    output_schema=TaskOutput,
    disallow_transfer_to_peers=True,
    disallow_transfer_to_parent=False,
)

Now we’ll look at how we define cloud_assist_mcp_toolset. Obviously, we're using MCP and the actual configuration is defined in my app_utils/mcp_config.py:

class GcpMcpAuthProvider:
    """Provides valid OAuth2 headers for Google Cloud remote MCP connections."""

    def __init__(self, scopes: list[str] | None = None):
        self._scopes = scopes or ["https://www.googleapis.com/auth/cloud-platform"]
        self._credentials = None
        self._lock = threading.Lock()

    def __call__(self, ctx: ReadonlyContext) -> dict[str, str]:
        with self._lock:
            if self._credentials is None:
                self._credentials, _ = google.auth.default(scopes=self._scopes)

            if not self._credentials.valid:
                self._credentials.refresh(Request())

            token = self._credentials.token

        return {
            "Authorization": f"Bearer {token}",
            "x-goog-user-project": settings.google_cloud_project,
            "Content-Type": "application/json",
            "Accept": "application/json, text/event-stream",
        }

# Gemini Cloud Assist MCP Toolset Configuration
cloud_assist_mcp_toolset = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://geminicloudassist.googleapis.com/mcp",
    ),
    header_provider=GcpMcpAuthProvider(),
)

So now, whenever we need an investigation, we can get Gemini Cloud Assist to do the heavy lifting. Nice!

5. `KnowledgeAssistant` (GCP Architecture Grounding)

Model: gemini-3.5-flash-lite.
Tools: dev_knowledge_mcp_toolset (Google Developer Knowledge MCP: answer_query, search_documents).
Responsibilities: Grounds cost optimisation and architecture advice directly in official Google Cloud developer and architecture framework documentation, returning authoritative citations.

The code for this agent is very simple; it’s basically just the prompt and the use of the Google Developer Knowledge MCP toolset. The toolset itself is defined using the same pattern that we used previously for cloud_assist_mcp_toolset.

KNOWLEDGE_ASSISTANT_INSTRUCTION = """You are the KnowledgeAssistant subagent.
Query the Developer Knowledge MCP to retrieve and ground cost optimization recommendations in official GCP architectural guidelines.

GUIDELINES:
1. Identify the specific GCP services provided in the user prompt or identified as top cost drivers (e.g. Vertex AI, Gemini API, BigQuery, Cloud Storage).
2. Query the Developer Knowledge MCP to find official Google Cloud cost optimization strategies, architectural patterns, quota management, lifecycle policies, and scaling guidelines for those specific services.
3. Always provide inline citations referencing official GCP documentation when presenting architectural advice or product recommendations.
4. When outputting references or citations, ALWAYS format them as standard single-line Markdown links: [Title](URL). Never insert line breaks or whitespace inside the URL or between `]` and `(`.
"""

knowledge_assistant = Agent(
    name="knowledge_assistant",
    description="Specialised subagent that queries the Developer Knowledge MCP to retrieve and ground cost optimization recommendations in official GCP architectural guidelines and best practices.",
    model=ConfiguredGemini(
        model=settings.fast_model,
        retry_options=types.HttpRetryOptions(attempts=3),
        use_interactions_api=False,
    ),
    instruction=COMMON_AGENT_HEADER + "\n\n" + KNOWLEDGE_ASSISTANT_INSTRUCTION,
    tools=[
        dev_knowledge_mcp_toolset,
    ],
    mode="single_turn",
    disallow_transfer_to_peers=True,
    disallow_transfer_to_parent=False,
)

6. `RootCauseAnalyst` (Spike & Drift Correlation)

Model: gemini-3.6-flash.
Tools: get_today_top_services_and_usage, investigate_today_service_logs, get_precomputed_root_cause, get_precomputed_spend_analysis, get_session_value, set_session_value.
Responsibilities: Investigates spend anomalies across two workflows:
- Intra-Day (Today’s Spend): Uses real-time Cloud Audit Logs and BigQuery data to discover active services, API invocation counts, caller identities, and operational error anomalies (bypassing GCP Billing ingestion lag).
- Historical Spikes: Correlates BigQuery resource-level cost spikes with Cloud Asset Inventory (CAI) configuration change history logs (e.g. machine type upgrades or disk size increases).

Let’s look at the prompt:

You are the RootCauseAnalyst subagent.
Investigate spend anomalies and intra-day cost drivers by executing either the INTRA-DAY or HISTORICAL workflow based on the user request.

FIRST: Determine the investigation time-frame:
- If the request targets TODAY or real-time cost/spikes, follow the INTRA-DAY WORKFLOW.
- If the request targets a PAST date spike, follow the HISTORICAL WORKFLOW.

INTRA-DAY (TODAY'S COST) INVESTIGATION WORKFLOW:
1. Call `get_today_top_services_and_usage()` FIRST to discover active services today.
2. Extract the top active service names returned (e.g., ["Gemini API", "BigQuery", "Vertex AI", "Cloud Run"]) and pass them into `investigate_today_service_logs(target_services=[...])`.
3. Synthesise intra-day SQL metrics, audit log invocation counts, and caller findings in your final report.
4. INGESTION LATENCY & DISCLOSURE RULE: Always note that standard GCP Billing Export has a 3-12+ hour ingestion delay. If billing partitions show minimal ingested spend while Audit Logs show active calls, report the active invocation counts and state official billing figures are pending.
5. OPERATIONAL ANOMALY RULE: If `has_operational_anomaly == True`, explicitly highlight errors in your summary report and recommend that the user/coordinator run a follow-up diagnosis with `CloudAdvisor`.

HISTORICAL COST SPIKE WORKFLOW (PAST DATES):
1. Identify the single primary spike date (YYYY-MM-DD).
2. Call `get_precomputed_root_cause(date_str="YYYY-MM-DD")` EXACTLY ONCE for that peak date against `{resource_table_id}`.
3. NEVER call `get_precomputed_root_cause` multiple times or loop through multiple dates.
4. Correlate persistent resources with Cloud Asset Inventory (CAI) configuration logs.

CRITICAL: CONCISE SYNTHESIS & TERMINATION
1. Keep the final markdown report under 350 words total.
2. Call `finish_task` and pass the complete final markdown report directly into the `result` parameter, then terminate execution.

There are a few key highlights worth calling out in this system prompt:

Explicit Time-Frame Branching: The prompt mandates a top-level decision step (TODAY vs HISTORICAL) before executing any tools.
Overcoming Ingestion Lag via Audit Logs: Standard GCP Billing Exports have a propagation delay, which could be several hours. For intra-day queries, the agent pairs BigQuery partition checks with real-time Cloud Audit Logs (get_today_top_services_and_usage and investigate_today_service_logs) to capture active API invocations, caller principal identities, and operational errors in real-time.
Clean Advisory Hand-Off: RootCauseAnalyst focuses purely on log and spend telemetry. It does not contain Gemini Cloud Assist tools directly. When investigate_today_service_logs detects operational errors (has_operational_anomaly == True), our agent explicitly recommends that the user or root coordinator run a follow-up diagnostic turn with CloudAdvisor (which holds the investigate_issue and ask_cloud_assist MCP tools).

Okay, that’s it for our overview of the agents. Let’s take a look at how they’re coordinated.

Multi-Agent Orchestration Patterns

When designing multi-agent architectures, several standard workflow patterns exist for how we can coordinate them. Here are just some of those patterns:

Coordinator-Dispatcher: A central root agent acts as an intelligent router, delegating tasks to dedicated subagents based on intent. The root agent makes the decisions.
Sequential Pipeline: Output from Agent A is piped sequentially into Agent B, then Agent C (like an ETL pipeline). Here we use deterministic workflow agents, so a model is not actually making any routing decisions.
Parallel Fan-Out and Gather: Multiple agents run in parallel, and their results are gathered together at the end. Again, this uses deterministic workflow agents.
Graph-Based Agent Workflows: where each agent is a node in a graph, and complex routing between agents is defined declaratively. This is a routing pattern that was introduced with ADK 2.x.

For FinSavant, we selected the Coordinator-Dispatcher pattern. We give the root agent (our coordinator) a bunch of subagents, and let the root agent decide which agent to delegate to, based on the user’s latest prompt and the information that has already been gathered in the session.

I should also mention the collaboration modes used by each agent. These determine the behaviour of a subagent that has been delegated to. There are three modes we can choose from:

Chat: Full user interaction. I.e. the user can continue to have a conversation with that subagent, and control only returns to the calling agent when a specific criterion (such as an instruction from the user) is met.
Task: Here, the subagent performs a specific task, but is allowed to seek clarification from the user in order to complete it. Once the task is complete, control returns to the calling agent.
Single-turn: Here, the subagent simply performs a task, but is not allowed to interact with the user. Control returns immediately back to the calling agent. This is useful for asynchronous workflows, such as when calling multiple subagents in parallel.

The mode is defined as a property as part of each subagent definition. So we've got:

BillingExplorer: task
InfrastructureAuditor: task
CloudAdvisor: task
KnowledgeAssistant: single_turn
RootCauseAnalyst: task

You can see that all of our subagents ultimately return control back to the coordinator. And you can also see — in our agent definitions — that I explicitly prohibit subagents handing off to a peer. They must return to the calling orchestrator agent.

Testing with ADK UI Tools

Now we’ve got our root agent, subagents and tools defined, we’ve got enough to try it out.

A great thing about using ADK is that we don’t even need to build a UI to test our agents! We can just use the out-of-the-box developer UIs, like ADK CLI and ADK Web.

ADK CLI is a command-line interface intended for easy text-only chats with our agent. For FinSavant, we can launch it like this:

uv run adk run agent/finops_agent

And then you can issue prompts to the agent, like this:

Let’s ask it what’s driving my costs over the last 30 days…

(Just type exit when you're done.)

This is okay, but we can do much better! We can use ADK Web, a rich web UI that gives us loads of insights into what our agents are doing.

uv run adk web agent/finops_agent

By the way, this is a convenient time to add a shortcut to our Makefile, so we don't have to remember these ADK commands! If you followed my setup guidance from the previous part, this might already be in your Makefile. But if not, go ahead and add this target:

# Launch local ADK Web dev playground
playground:
    @echo "======================================================="
    @echo "| 🚀 Starting your agent playground... |"
    @echo "======================================================="
    uv run adk web agent/finops_agent --port 8501 --reload_agents

The ADK Web UI launches at http://localhost:8000. And it looks like this:

There’s so much cool stuff you can see and do from here. For example:

We can see which agents and tools are currently being invoked.
We can view our request and response payloads, including the exact prompts that were issued to the agent.
We can view event metadata, such as number of input and output tokens consumed.
We can view the agent state.
We can even build and run evaluation sets. (More on this in a future blog.)

I’ll issue the same “30 day” prompt that we used before.

Immediately, we get to see a load of useful real-time information. The first thing we see are the state changes, such as which sub-agents and tools are being called:

We can even view a dynamic visual graph, which reflects whatever event (e.g. request or response) we currently have highlighted:

Of course, we’ve still got our terminal logs:

And this is super-cool… We can even see a trace view in ADK Web, that shows a breakdown of the durations of each call:

Once upon a time, it was difficult to know what calls were causing our multi-agent solution to be slow. No longer!!

Performance Optimisation Lessons Learned

Speaking of slow, let me share a couple of key moments in my FinSavant optimisation journey. I made dozens of performance optimisations, but I’ll just share a couple of the most impactful ones.

Partition Pruning & Predicate Pushdown

Standard Google Cloud Billing export tables in BigQuery are partitioned by export_time. However, if an agent generates an outer SQL query with temporal filters wrapped around an un-scoped inner subquery, BigQuery ends up scanning the entire multi-gigabyte historical dataset before filtering the results!

To fix this, our BigQuery tool wrapper (execute_cached_bigquery_sql) dynamically parses temporal constraints (export_time, usage_start_time, usage_end_time) from the agent's SQL query and pushes down the predicates directly into the inner scoping subqueries:

FROM (
  SELECT * FROM `gcp_billing_export_v1_*` 
  WHERE project.id IN (...) 
    AND export_time >= TIMESTAMP(DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
    AND usage_start_time >= TIMESTAMP(DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
)

Why is predicate pushdown so powerful?

By moving the date filters directly into the inner table scan, BigQuery performs partition pruning right at the start. It reads only the specific disk partitions containing data for the requested time window (e.g. the last 30 days), completely skipping possibly years of irrelevant historical data.

This results in queries that are much faster and much cheaper! For me, the total time taken by the subagent was trimmed from over a minute to a few seconds.

Deterministic Python Precomputation & Subagent Tool Stripping

Rather than having LLM subagents generate complex SQL queries, inspect raw data rows, and run multi-turn self-correction loops, I implemented native Python precomputation tools, like get_precomputed_spend_analysis and get_precomputed_root_cause. Why do this?

Well…

Dynamically writing SQL queries is slow, non-deterministic, and often requires loops if the initial SQL queries are incorrect.
And, getting the agent to do this work is costly! It’s a waste of tokens.

If we know exactly what we need the agent to do in a given step, and we can code in a deterministic way, THEN WE SHOULD. Don’t use LLMs to dynamically work out how to do stuff you already know how to do. That’s a poor way to use AI!

Across all our agents, this change was probably the most significant time and token saver, overall.

Test-Driven Development & Unit Testing

Of course, I created unit tests. I say “I created unit tests”, but in reality, I got Antigravity to build most of them for me. But these proved extremely useful in catching issues and preventing regressions.

At the time of writing, I have:

80 unit tests across 13 modules
5 integration tests across 3 modules

I run them with make test, using these targets in my Makefile:

# Run unit tests
test:
    uv sync --dev
    uv run pytest tests/unit

# Run unit and integration tests
test-all:
    uv sync --dev
    uv run pytest tests/unit && uv run pytest tests/integration

I also have these tests integrated into my GitHub Actions CI/CD pipeline. (I’ll cover this in a future part.)

Building the FastAPI Backend-for-Frontend (BFF)

This part of the series is mainly about the agentic parts of the solution, so I won’t go into a lot of detail about the BFF itself. But I’ll cover it briefly, so you’ve got an understanding of how our UI will interact with the agentic layer.

What is a BFF and Why Do We Need It?

A Backend-for-Frontend (BFF) is an architectural pattern where a dedicated server-side application acts as an intermediary (a kind of proxy) between the client frontend (our React UI) and backend services, such as our agents. Rather than having the browser React application talk directly to GCP APIs or remote Agent Runtime endpoints, the BFF handles all the heavy lifting behind the scenes.

In FinSavant, the BFF is doing (amongst other things) the following:

Protocol & Stream Formatting: Formats raw agent event streams and tool calls into clean Server-Sent Events (SSE) for the React frontend.
Rate Limiting & Protection: Enforces per-user rate limits (via SlowAPI) to prevent denial-of-wallet API spikes.

What is FastAPI and Why Have We Used It?

FastAPI is a modern, high-performance Python API framework. It’s basically the gold standard for building APIs in Python these days. And Google ADK provides a native FastAPI helper (get_fast_api_app), making it simple to bind ADK runners, session storage, and A2A routes.

Let’s look at how the BFF (bff/fast_api_app.py) interacts with our agent layer...

Defining the FastAPI App

app: FastAPI = get_fast_api_app(
    agents_dir=AGENT_DIR,
    web=False,
    artifact_service_uri=services.ARTIFACT_SERVICE_URI,
    allow_origins=allow_origins,
    session_service_uri=services.SESSION_SERVICE_URI,
    otel_to_cloud=otel_to_cloud,
    lifespan=lifespan,
)
app.title = "smart-gcp-finops-bff"
app.description = "BFF API for interacting with the FinOps Agent"
app.state.limiter = limiter
app.add_middleware(SlowAPIMiddleware)
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

Note the web=False setting. By default, ADK's get_fast_api_app helper sets web=True, which automatically mounts ADK's built-in developer playground UI at the root (/) path. Since our BFF container serves our custom React SPA in production, setting web=False is essential. Without this, ADK's default playground (i.e. the ADK Web UI) overrides the root route.

The BFF automatically detects its runtime environment at startup. In local dev mode, it runs a standard in-process ADK Runner. In production on Cloud Run, it switches to "remote mode" and routes requests directly to Gemini Enterprise Agent Platform Agent Runtime:

@contextlib.asynccontextmanager
async def lifespan(app: FastAPI) -> AsyncIterator[None]:
    agent_runtime_id = os.environ.get("AGENT_RUNTIME_ID")
    if not agent_runtime_id:
        # Local development mode: run agent in-process via ADK Runner
        from finops_agent.agent import app as adk_app
        runner = Runner(
            app=adk_app,
            session_service=services.get_session_service(),
            artifact_service=services.get_artifact_service(),
        )
        app.state.runner = runner
    else:
        # Production mode: agent runs remotely on Agent Runtime
        app.state.runner = None

    yield

Streaming Agent Events over SSE (`/api/chat/stream`)

When a user submits a prompt, the React frontend calls /api/chat/stream. The BFF resolves the authenticated user's project permissions, sets contextual state variables (ALLOWED_PROJECTS_VAR), invokes the agent, and streams back thought logs, friendly tool names, and A2UI payloads in real time:

@app.post("/api/chat/stream")
@limiter.limit(settings.chat_rate_limit)
async def chat_stream(request: Request):
    user_email = _get_user_email(request)
    allowed_projects = get_user_accessible_projects(user_email)

    # Scope execution context to projects this user is authorised to query
    token = ALLOWED_PROJECTS_VAR.set(allowed_projects)

    async def event_generator():
        # Stream thought logs, tool execution badges, and final text/A2UI payloads
        async for event in run_agent_stream(request, user_prompt):
            yield f"data: {json.dumps(event)}\n\n"

    return StreamingResponse(event_generator(), media_type="text/event-stream")

This ensures the React frontend receives real-time progress updates. For details of what this looks like... You’ll have to wait until the next part!

Cloud Run Keep-Alive Heartbeats

Cloud Run automatically terminates HTTP connections if no data bytes are transmitted for a few seconds. To prevent connection drops during complex multi-tool agent reasoning flows, our SSE generator emits comment heartbeats every 15 seconds while waiting for agent turn updates:

# Stream heartbeats every 15 seconds to prevent Cloud Run connection timeouts
seconds_passed = 0
while not task.done():
    await asyncio.sleep(1)
    seconds_passed += 1
    if seconds_passed >= 15:
        # SSE comment heartbeat to keep connection alive
        yield ": heartbeat\n\n"
        seconds_passed = 0

BFF Rate Limiting (`slowapi`)

To prevent Denial-of-Wallet attacks and API quota exhaustion, the BFF applies slowapi rate limiting on some of our endpoints, like /api/chat/stream, keyed by the user's authenticated identity.

Testing the BFF

In the absence of a UI (coming in the next part), we just need to be able to send an HTTP request to our new shiny API. Let’s create a new target in our Makefile:

# Launch local development server with hot-reload (defaults to local in-process ADK agent mode)
# Usage: make local-backend [PORT=8000] - Specify PORT for parallel scenario testing
local-backend:
    AGENT_RUNTIME_ID="" PYTHONPATH=agent uv run uvicorn bff.fast_api_app:app --host 127.0.0.1 --port $(or $(PORT),8000) --reload

Now we can launch the API — which automatically launches the backend agent — with this command:

make local-backend

Once that’s running, start a separate terminal session and send some requests to the API with curl:

curl http://localhost:8000/api/status

Or we can issue a prompt, like this:

curl -N -X POST "http://localhost:8000/api/chat/stream" \
   -H "Content-Type: application/json" \
   -d '{"message": "What is driving my costs over the last 30 days?"}'

The response looks a bit horrible, but you get the idea!

What’s Next?

With our multi-agent backend, precomputed toolsets, and FastAPI BFF tested and (slightly) optimised, we’re ready to build the user interface!

In Part 4, we’ll dive into Designing and Building the UI with Google Stitch and A2UI, exploring how we used Google Stitch to craft our dark-mode aesthetic and how A2UI dynamically drives interactive SVG area charts, KPI tiles, and waste optimisation cards on the React canvas.

Stay tuned!

Before You Go

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

Useful Links and References

Project Demo & Portfolio

Series Links

Google Cloud Services & APIs

ADK

Automated GitHub Code Reviews Using Google Gemini

Darren "Dazbo" Lester — Thu, 16 Jul 2026 11:16:35 +0000

I Built a Thing!

TL;DR — Google Gemini-based Pull Request reviews and Issue Triaging for all your GitHub repositories and CI/CD pipelines.

What’s the Big Deal?

If you or your fellow developers aren’t yet using AI to automate code reviews, then you’re missing out on an absolute game-changer in the software development lifecycle.

Legacy approach:

You commit your code.
You submit your pull request (PR).
You wait for another developer to perform a code review and approve the PR.

This is the way it’s been for years. It’s fine. But the review process — and the reviewer — becomes a bottleneck. And furthermore, it’s a human process that is subject to significant variability.

Enter automated code reviews.

Now, after you submit the PR, a code review is automatically triggered and performed by your favourite model, using whatever instructions and grounding you and your team require. The review happens pretty much immediately. And the quality of the review is often higher than that of your fellow developers.

For the many colleagues I work with who have switched to this approach, the main benefits are:

No waiting for a human review.
High quality code reviews that not only catch issues, but also provide easy-to-follow recommendations and explanations that help the developer to learn and improve.
Massive increase in overall development velocity.

I love it. They love it. You’ll love it too!

RIP Gemini CLI Actions

For a while, Google gave us this review capability out-of-the-box. We had tools that could read our pull requests, analyse our code diffs, and write constructive, line-specific feedback comments directly on GitHub.

But then, the music stopped. If you used to rely on Google’s Gemini-based PR review integrations in GitHub, then you’re probably now sobbing into your strawberry daiquiri. (I know I was.)

Specifically, two Google mechanisms that developers loved have been decommissioned:

Gemini CLI GitHub Actions (run-gemini-cli) This was a GitHub Action that you could easily integrate into your GitHub repos by running a /setup-github command from within Google Gemini CLI. Once installed, this action would spin up a container running Gemini CLI, and use it to perform automated reviews of your code in response to a pull request. Alas, this mechanism stopped serving requests on June 18, 2026.
Gemini Code Assist on GitHub This direct GitHub App integration relied on Google Gemini Code Assist. Whenever a pull request was opened, GitHub sent a webhook to Google’s backend. This has also been shut down as of July 17, 2026.

But why have they gone? It’s because Google has terminated both Gemini Code Assist and Gemini CLI in favour of the newer Google Antigravity suite. This is true even for users on a paid Google AI subscription.

What can you do if you relied on these tools? What can you migrate to?

The Answer: My Super-Fast Drop-In Replacement

I didn’t want to lose my automated PR reviews. So, I built a drop-in replacement: the Gemini PR Review & Triage Action (derailed-dash/gemini-review-action).

I’ve officially published this to the GitHub Marketplace too, so you can find it indexed there and enjoy nice IDE autocompletion when configuring your workflows!

Features Overview

Here’s a quick summary of what it does…

AI-Powered Code Reviews: Automated, constructive line-specific feedback on Pull Requests using Google Gemini models (Gemini 3.6 Flash by default).
Automated Issue Triage: Dynamically labels, prioritises, and triages incoming issues.
Drop-in Migration: Fully compatible as a direct, drop-in replacement for the deprecated run-gemini-cli action.
Structured Outputs: Error-free JSON response formatting using Pydantic schema validation.
Hybrid Codebase Context: Automatically includes codebase context based on the overall size of the codebase. If the codebase isn't huge, the entire repo is loaded into context; but if it is huge, the agent reads the overall directory tree and judiciously includes a subset of the repo. (Note that it always reads markdown files, dependency files, packaging files, etc.)
PR Comment & Discussion Thread History: Automatically retrieves inline review threads and general PR conversation comments, enabling Gemini to track issue resolution, respect developer justifications/disagreements, and avoid repeating resolved suggestions across commits.
Tokenomics & Cost Telemetry Report: Appends a collapsible cost efficiency and token usage summary to each review.
Interactive Suggestions: Formats code recommendations inside native GitHub `suggestion blocks for one-click merge applications.
Triggers: The action triggers automatically in response to PR events. It can also be triggered by posting a comment in the PR starting with /gemini-review.
Fast-Execution Composite Action: Avoids containerisation build/pull latency (no slow docker build on every execution) by running as a native composite action.
Cross-Platform Support: Runs natively on Linux, macOS, and Windows runners (both GitHub-hosted and self-hosted).
Modern SDK Execution: Leverages the modern Google GenAI SDK (google-genai).
Enterprise-Grade Security: Authentication via either Google Gemini API Keys or Google Cloud Workload Identity Federation (WIF).
Customisable Prompts: Supports repository-specific overrides for both reviews and triaging via simple TOML config files.
Reviewer Personas: Customise the personality, tone, and review style of the agent with pre-built persona overlays (straight, dazbo, palpatine, rick).
Google Developer Knowledge Integration: Automatically queries official Google developer documentation (Google Cloud, Firebase, Android, etc.) via MCP to cross-reference your changes against up-to-date best practices.
On-Demand Agent Skills: Dynamically discovers and loads project-specific formatting guidelines and coding standards from .agents/skills on-demand, keeping prompt contexts lightweight and relevant (bundled with defaults for Google Cloud, Gemini APIs and agentic development).
Gemini Context Caching: Native, automatic integration with Gemini Context Caching, delivering up to 90% cost reduction on input tokens for repositories over 32k tokens.
Multi-Turn & Cross-PR Cache Reuse: Reuses active server-side context cache handles across multi-turn tool/skill calls and successive PR pushes within the TTL window (1h default), eliminating prompt re-tokenisation and server overhead. This is a huge efficiency and cost saving between successive reviews.

Rationale and Design Decisions

Before I built my own, I started by looking at the open source community and found a couple of replacements in the ecosystem. But they didn’t quite tick all my boxes.

Here are some reasons why I built it, and some of the design decisions I made along the way…

Performance — Native Composite Actions with `uv`

The community versions I found installed their Python dependencies using pip. This is fine, but it’s very slow compared to Astral’s awesome uv. So I wanted to build a solution that’s much faster. If you ever found yourself making changes and then re-running your code review, you’ll appreciate the frustration!

Instead of packaging the action inside a slow Docker container (like run-gemini-cli did), I designed it as a native composite action leveraging uv.

Because uv handles virtual environments and package installations with blazing speed, the scripts start running almost instantly. No Docker pulls, no container builds, and no slow pip resolution phases. The reviews execute in seconds, saving you valuable runner minutes.

Binary Fragility and Codebase Context

The community integrations I tried were a little fragile when processing binary files or encrypted assets, and they completely lacked project-wide context. They could only see the raw diff. I needed a solution that was resilient and understood the broader codebase.

My action parses the diff and automatically filters out binary, compressed, or encrypted assets. For the remaining text files, it implements a smart hybrid codebase context engine:

Full Context Mode: For smaller codebases (less than 1.5MB, excluding the stuff we filtered out), the action automatically attaches the full contents of all other files in the repository. Gemini gains complete project-wide awareness.
Sparse Context Mode: For larger codebases, it switches to a sparse mode. It attaches a visual file directory structure of the repository, plus the full contents of core manifest/configuration files and markdown documentation.

This ensures Gemini understands exactly how your PR changes fit into the overall project structure, resulting in significantly higher quality feedback.

JSON Schema Enforcement

Asking a model to return JSON in a text prompt is always a gamble. Without using Gemini’s native response_schema API (which forces structure via Pydantic model validation), the model can return markdown-wrapped JSON or invalid formats, breaking the comment parser. Again, another source of fragility.

My solution addresses this using structured outputs with strict Pydantic schemas.

SDK & Model Defaults

Alternatives I found were using older deprecated SDKs like google-generativeai, and legacy AI models like gemini-2.5-pro. I wanted to use the more up-to-date google-genai SDK, and default to the latest and greatest gemini-3.6-flash right out of the box. It’s so much better at code reviews than the older models, and so much faster too!

Configurable Language

The community actions I found didn’t offer a way to configure the preferred review language and sometimes the response was being returned to me in a language I couldn’t read! So I wanted the ability to configure (amongst other things) the review language.

Upgraded Intelligence: On-Demand Skills & Official Google Developer Knowledge MCP

I think you're gonna love this one!

A code reviewer is only as good as the standards and documentation it references. Historically, enforcing custom style guides or keeping up with changing APIs meant cramming thousands of lines of documentation directly into the system instructions, wasting tokens and confusing the model.

So my reviewer includes real-time, context-aware intelligence:

Google Developer Knowledge MCP (Out-of-the-Box): If your GEMINI_API_KEY (or Google Cloud Application Default Credentials) has the Developer Knowledge API enabled, the reviewer automatically registers the Developer Knowledge MCP. When it reviews PR code related to Google Cloud services (GKE, Cloud Run, Cloud Logging), Firebase, Android, or Google APIs, the model dynamically calls search tools to cross-reference your changes against official, up-to-date Google best practices in real-time!
On-Demand Agent Skills Registry: You can now add additional knowledge, custom style guides, API rules, or release standards by adding "skills" markdown files inside .agents/skills/ (e.g. .agents/skills/my-react-rules/SKILL.md). The reviewer checks for available skills when it starts up, and only activates specific skills that are relevant for the current review. This keeps our context lightweight. Plus, this action comes pre-packaged with a default set of skills for Google Cloud, Gemini APIs, and agentic development.
Best Practices Alignment: By combining official Google Developer Knowledge MCP tools with local workspace skills, the reviewer is primed out-of-the-box to ensure your code matches real-world, industry-standard best practices.

Clean Slate Reviews (No Session Bias)

When you're pair-programming or debugging with a local AI assistant, it builds up a massive conversational history. While that context is brilliant for generating code, it also introduces a subtle problem: session bias. The local agent knows the evolutionary journey of your code, what compromises you discussed, and what you intended to do. It understands your intent so well that it can become overly forgiving, overlooking gaps or regressions in the final implementation.

This GitHub Action, by contrast, starts with a completely clean slate. It has no idea how you arrived at your solution, what you struggled with, or what you discussed with your local IDE assistant. It is a stateless, objective reviewer checking the actual diff against the codebase. This means it often catches bugs, edge cases, or security issues that your local assistant completely glossed over!

A Quick Primer: What are GitHub Actions?

Before we start throwing a YAML configuration at your repository, let’s make sure we’re on the same page. If you already know your way around CI/CD in GitHub, feel free to skip this bit.

GitHub Actions are GitHub’s native automation platform. Instead of running and maintaining external build servers — I’m looking at you, Jenkins (shudder) — it allows us to run automated pipelines directly inside your repository in response to events like a code push, a new Pull Request, or even someone leaving a comment.

Here’s the basic vocabulary:

Workflows : The overall automated process, defined in a YAML file inside your .github/workflows/ directory.
Events/Triggers : The GitHub occurrences that kick off the workflow (e.g. pull_request).
Runners : The virtual machines (hosted by GitHub or self-hosted) that execute the jobs.
Jobs : A collection of steps that run sequentially on the same runner.
Steps : Individual tasks that either run commands or use GitHub Actions.
Actions : Reusable plugins (like ours!) that do the heavy lifting, saving you from writing your own scripts.

It all hangs together like this:

Setting It Up in 3 Minutes

Now you know what a GitHub Action is. Let me walk you through how to bring my GitHub Action into your own repository.

Step 1: Authentication (Required for Both Methods)

Before you install any workflows, you need a one-time authentication setup for your repository so the action can authenticate with the Google Gemini API. You have two choices:

The Easy Route: Generate a Gemini API Key in Google AI Studio. In GitHub, navigate to Settings > Secrets and variables > Actions, click New repository secret, and add your key named GEMINI_API_KEY.
The Enterprise Way: If you are running in a corporate Google Cloud environment, you can use Workload Identity Federation (WIF) and Application Default Credentials (ADC) to authenticate securely without storing static secrets. See the repository for WIF setup instructions.

Step 2: Install the Workflows

Once authentication is configured, choose one of the two options below to add the workflow files to your repository.

Option A: The Ultra-Lazy Route (Install via Agent Skill)

If you are already using an agentic coding environment like Google Antigravity, you don't even need to copy and paste the YAML configuration files manually. You can use my skill repository to automate the setup!

Simply run the following command in your terminal to install the skill locally:

npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g --skill install-gemini-code-review-action

Once installed, you can just tell your AI coding assistant:

"Install the Gemini code review action in this repo."

The skill will run an interactive setup checklist:

Detects and removes legacy actions (like run-gemini-cli) that might conflict.
Prompts you for your preferences (e.g. if you want both PR Review and Issue Triage, your preferred review language, and model).
Writes the workflow .yml files and custom prompt .toml templates.
Offers to commit and push the changes directly to your repository!

Option B: The Manual Route

If you prefer to set it up manually, it’s still very easy! Create a file in your repository called .github/workflows/gemini-review.yml and paste in the sample configuration.

You don’t need to change this config at all, but you can if you want to. The part you’re most likely to want to modify is the inclusions and exclusions. There are other configurations you can tweak here, and the repo provides more details.

After you add the workflow to your own repo, it will look something like this:

Step 3: [Optional] Customise the AI’s Personality

You don’t have to stick to the default prompt. But I suggest you do — there’s a lot of smarts built into the default. But I recommend you always start by copying the defaults located in the starter-examples/ directory of the project.

Let’s See It Run!

Let’s do a quick demo. For this demo, the action has already been installed our repo.

Then we create a PR:

In a couple of seconds we’ll see the workflow begin to run:

A few seconds later, the review completes and we see the recommendations:

Triggering a Review with a Comment

We’ve seen the review trigger in response to creating a PR. But we can also trigger a PR by adding a GitHub comment: /gemini-review. This is really useful for re-running a review on-demand. (Again, this is a feature that existed in the original Google tools, and I wanted to keep it.)

Under-the-hood, my workflow achieves this using the issue_comment trigger.

Notice the if conditional for issue_comment. This is incredibly important. On public repositories, anyone can leave a comment on a Pull Request. Without that author_association check, a random internet stranger could comment /gemini-review on your PR and drain your Gemini API quota — not to mention your GitHub Action runner minutes. By restricting the trigger to OWNER, MEMBER, or COLLABORATOR, we ensure only trusted team members can summon the AI.

So, when you need a quick review: just leave the comment, and watch the magic happen!

Using Out-of-the-Box Personalities

You can configure the personality of your reviewer! A number of personas area available to choose from.

Here's what a review from palpatine looks like:

And here's a review from Rick. Wubba-Lub-a-Dub-Dub!!

Wait, What About Issues Triage?

I nearly forgot! My action can also be used to triage any issues that are raised against your repo.

As your open-source projects grow, the issue tracker can quickly turn into a chaotic mess of bug reports, feature requests, spam, and questions. Keeping the backlog clean and correctly tagged is a chore that most developers dread.

To help solve this, you can run my action in triage mode. When a new issue is opened, Gemini reviews the title and description, compares it against your existing repository labels, and automatically applies the most appropriate tags.

What you get is an immediately organised issue backlog, complete with a brief reasoning comment explaining why the labels were selected. It takes the manual effort out of issue classification entirely.

If you want to set this up in your repository, visit the repository for the full setup instructions.

Wrapping-Up

Sunsets are always frustrating, especially when they disrupt a workflow you’ve grown to rely on. But they also present a fantastic opportunity. An opportunity to learn and an opportunity to do things in a slightly different way. The main benefit for me is having a reviewer that’s now much faster than my old one. It consumes fewer runner minutes, it supports custom TOML prompts, and it leverages the latest from Gemini.

PLEASE give the repository a star , try the action out on your open-source projects, and let’s keep our CI/CD pipelines smart, secure, and fast!

Let know how you get on!

If you run into any issues or want to contribute a custom workflow, drop a comment, open an issue, or add your own contribution to derailed-dash/gemini-review-action.

Before You Go

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

Useful Links and References

Building an Agentic FinOps Platform — Development Environment Setup, Google Antigravity, MCPs and Skills, and ADK Bootstrapping with Agents CLI

Darren "Dazbo" Lester — Mon, 13 Jul 2026 15:31:20 +0000

TL;DR — This article is going to be jam-packed with useful information, tips, tricks and hacks for setting up an agentic development in the Google ecosystem.

This one isn’t really about the FinOps!

Welcome to Part 2

Welcome back, friends!

In the first part, I described the purpose of the FinSavant FinOps solution, the motivation for creating it, its overall architecture and tech stack, and how it works.

In this part, we’ll use FinSavant as a case study in how to set up a development environment for the purposes of building such an ADK-based agentic solution. Even if you’re not particularly interested in FinSavant itself, I hope you’ll find a bunch of useful information and tips here that will help you build your own agentic solutions more effectively and quickly.

We’ll cover:

Using Antigravity IDE
Overall project workspace structure
Setting up agent skills for your coding agent
My project’s GEMINI.md (or if you prefer, AGENTS.md)
My documentation approach
Setting up MCP servers for your coding agent, such as BigQuery MCP
Scaffolding the initial ADK agent using Google Agents CLI and its supporting skill
Getting started with a Makefile

Sound good? Let’s get cracking!

Series Orientation

Let’s see where we are in this series.

Goals, Architecture, and Tech Stack: Capabilities, project goals, target architecture, technology stack, and design decisions.
Development Environment Setup, Google Antigravity, MCPs and Skills, and ADK Bootstrapping with Agents CLI 📍 You are here.
Building the ADK Agent and API
Designing and Building the UI with Google Stitch and A2UI
Deployment with Gemini Enterprise Agent Platform, Agent Runtime, Cloud Run and IAP
Automating Deployment with CI/CD and Terraform
Agent Observability, Evaluation, and Tuning with Gemini Enterprise Agent Platform

Getting Started with Antigravity IDE

These days, my favourite coding environment for any significant project is Antigravity IDE. This is Google’s agent-first integrated development environment. You get a look-and-feel that’s familiar to VS Code users, but powered with autonomous, context-aware agents that can plan, execute, verify, and work in parallel.

You can get it here.

By the way, Antigravity IDE is just one member of the Antigravity (aka Agy) suite.

I’ve covered these before, but here’s a quick reminder of the four Agy solutions in the suite:

Antigravity 2.0, which is now the dedicated agent-first “builder” environment on your desktop. Notably, it doesn’t itself include an IDE. Instead, we now interact only with the agent manager. This surface aims to usher in the era of “idea to product” using agents, without concerning ourselves over the code. Many builders who don’t come from a coding background will love this.
Antigravity IDE, which gives us the more familiar VS Code-esque coding environment, supported by the Antigravity agent harness. Here we can do agent-assisted development, and we always see the code. Coders will feel at home here.
Antigravity SDK, which gives you the harness and tools that power Antigravity, but exposed as a Python Agent SDK. By importing from google.antigravity we can programmatically leverage Antigravity’s capabilities.
Antigravity CLI, which is the next evolution of the extremely awesome Gemini CLI. It’s still a terminal-first environment for interacting with Gemini models. But the new Antigravity CLI is built in Go, and you can tell; it feels much faster than Gemini CLI, both during startup and in general use. It leverages the same agent “harness” as Antigravity 2.0 and the IDE, and this allows for common settings and configuration across the Antigravity suite.

Project Structure

Here’s the rough outline of the project structure we’ll be creating. We won’t be building all of this structure here; nor does this represent the final state of the project. But it gives you an idea of where we’re heading. (I’ll explain the * in a minute!)

  smart-gcp-finops/  
  ├── agent/                # ADK agent package  
  │   ├── finops_agent/     # Root agent  
  │   ├── .env              # Agent specific environment vars  
  │   ├── Dockerfile        # For deploying agent to Agent Runtime  
  │   └── pyproject.toml    # Agent runtime dependencies  
* ├── bff/                # Backend-for-Frontend (API)  
* ├── deployment/         # Infrastructure & CI/CD (Terraform IaC)  
* │   ├── terraform/      # Centralised IaC for Prod & Staging  
  │   └── README.md         # Deployment documentation  
* ├── docs/               # Project documentation  
* │   ├── images/         # Diagrams and architectural visual assets  
  │   ├── DESIGN.md         # Visual identity, components, and UI design  
  │   ├── architecture-and-walkthrough.md # Solution blueprints, ADRs, and component data flows  
  │   └── testing.md        # Testing strategy and verification instructions  
* ├── frontend/           # React UI frontend  
* ├── notebooks/          # Jupyter notebooks for prototyping and evaluation  
* ├── scripts/            # Environment setup and other utility scripts  
  │   └── setup-env.sh      # Configure local environment including Google auth / ADC  
* ├── tests/              # Unit and integration test suites  
* │   ├── eval/           # Agent evaluation  
* │   ├── unit/           # Unit tests  
* │   └── integration/    # Integration tests  
* ├── .agents/            # Workspace customizations root  
  │   └── mcp_config.json   # E.g. MCP servers  
* ├── .github/            # GitHub Actions workflows and CI/CD  
* ├── .env                # Root environment vars (dev setup, unified container, GitHub, etc)  
  ├── .envrc                # Automatically launch when entering this directory  
* ├── .gitignore          # Exclude from git  
* ├── Makefile            # Centralised developer convenience commands  
* ├── GEMINI.md           # Development agent context & guidelines  
* ├── LICENSE             # Standard open-source license file  
* ├── pyproject.toml      # Root project configuration / dependencies  
* ├── README.md           # Developer documentation homepage  
  └── TODO.md               # TODO list

If you wanted to build such a structure from scratch, here’s a cool thing to try…

Create your new project folder, e.g. my-cool-project
Open that folder in Antigravity IDE.
Supply this prompt to the Agy Agent:

/grill-me Using this folder tree as a template, 
create the required folder structure in this workspace for my new Python 
project. Only create folders and files that are marked as '*'. 
For required files, provide initial starter-for-10 content. 
<< paste the tree structure here >>

Why /grill-me? This is a built-in Agy command that causes the agent to ask questions to remove ambiguity. If you were to give the agent a slightly vague prompt without this prefix, then the agent might make some guesses about what you want. But with /grill-me, the agent will still make educated guesses, but it will also ask you questions to clarify your intent.

The prompt above is a good example of where this is useful. You’ll notice that my project tree has a LICENSE.md file, which is a standard component to include in open-source projects. But my prompt doesn't specify which license to use. So when you use /grill-me, the agent will offer sensible license choices based on your project and context, and ask you to confirm.

This video demonstrates Agy scaffolding the entire project from scratch, in response to the prompt above:

Give it a go!

Skills for Your Coding Agent

I like to describe skills as units of knowledge that agents load on-demand, when they need to do a particular task. I’ve previously written articles on the subject of my favourite skills, where to find them, and how to install them. I recommend you check out this one. You might want to go ahead and install all of my favourites!

But for now, let’s add a few skills that will definitely be useful for our current project. I recommend installing them globally, so they’ll be available to all of your development projects.

npx skills add https://github.com/vercel-labs/skills -y -g --skill find-skills  
npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g  
npx skills add https://github.com/google/skills -y -g  
npx skills add https://github.com/google-gemini/gemini-skills/ -y -g  
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill technical-writer

We’re also going to install the Google Agents CLI and its associated skills, but we’ll get to that later.

`GEMINI.md` - Context for Your Coding Agent

The GEMINI.md file (or AGENTS.md if you prefer) is how you define your project's rules and context. It's where you tell the Agy Agent:

About your project’s goals
Rules and guidelines you want it to follow
References you want it to read

When we create GEMINI.md in the root of a project then the file is scoped only to that project. (This project-specific context gets appended to any global GEMINI.md you have defined.) When you launch any Antigravity tool from this workspace - such as Agy 2.0, Agy IDE, or Agy CLI - the Agent will automatically read this context.

Let me show you what my GEMINI.md looked like, when starting out with FinSavant:

# FinSavant - the Agentic FinOps Solution  

## Project Goals  

To create an agentic FinOps solution for GCP that:  
- Uses ADK for agent orchestration.  
- Is able to examine billing and cost data in BigQuery, based on billing   
  exports.  
- Is able to understand Google Cloud infrastructure and services across   
  multiple Google projects associated with a billing account.  
- Considers projects associated with a particular Google Cloud organisation,    
  associated with a billing account.  
- Leverages Google Developer Knowledge API MCP for grounding:   
  Google APIs, Google Cloud infrastructure, Google Cloud best practices.  
- Is able to detect cost anomalies and inefficiencies, and trends.  
- Is able to understand all deployed infra and services, and historical   
  configuration changes, leveraging Google Cloud Asset Inventory  
- Is able to invoke Google Cloud Assist for immediate logs investigation,   
  RCA and recommendations.  
- Is able to combine all of the above to provide actionable insights and   
  recommendations to users.  
- Provides a UI for users, which includes:  
  - Dashboard of cost trends, billing data and anomalies  
  - Cost forecasting  
  - Cost analysis  
  - Anomaly detection  
  - Recommendations  
  - Cost optimisation suggestions  
  - A natural language chat interface  
- The UI should be based on React. Use skills you have available to leverage   
  React best practices.  
- Leverage Google Stitch to design the UI, and use the Stitch MCP server to   
  pull in the design, in order to convert to React.  
- The UI is connected to the agent via FastAPI.  
- The UI and API will be hosted in a single Cloud Run service. The service   
  will be secured using IAP, using direct Cloud Run integration - no   
  Load Balancer.  
- The Agent will be deployed to Agent Runtime in Gemini Enterprise Agent   
  Platform.  

## Tool Use: Skills, Gemini Enterprise Agent Platform, Agent Runtime and ADK  

Be sure to use all **agents** skills, **Gemini Enterprise Agent Platform**   
skills, and **ADK** skills you have available for developing ADK agents and   
best practices, and use **adk-docs-mcp** for latest ADK documentation.   

You will have additional skills available to you, but always check if the   
following can help with a particular task.  

### ADK & agents-cli Lifecycle Skills  

- `google-agents-cli-workflow`: Entrypoint for building ADK agents (scaffold,   
build, evaluate, deploy, publish, observe).  
[skipping for brevity]  

### Gemini Enterprise Agent Platform APIs  
- `gemini-api`: Gemini Enterprise Agent Platform, Google Cloud, and   
Agent Platform enterprise usage with the Google Gen AI SDK.  
[skipping for brevity]  

### Agent Platform Engine & Model Management  
- `agent-platform-deploy`: Deploying models and tuned weights to Agent   
  Platform endpoints.  
[skipping for brevity]  

## Key Internal Documentation  

- README.md - Project README; the developer's front door  
- TODO.md - High level plan for the project  
- architecture-and-walkthrough.md - The main architecture, including design   
  decisions  
- DESIGN.md - Where we will capture the UI design  
- testing.md - Where we will document test strategy, summary of tests,   
  testing instructions, any manual testing processes  
- docs/blog.md - A blog post document we will build along the way  
- /deployment/README.md - Deployment and CI/CD documentation  

## Essential Reading  

You should read and leverage these resources for guidance and best practices,   
in addition to the skills and MCP servers you have available for knowledge.  

| Resource | Description and Relevance |  
| -------- | ------------------------- |  
| https://docs.cloud.google.com/bigquery/docs/use-bigquery-mcp?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | Use the BigQuery MCP server |   
| https://adk.dev/integrations/bigquery/?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | BigQuery tool for ADK |  
| https://docs.cloud.google.com/gemini-enterprise-agent-platform?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | Gemini Enterprise Agent Platform Overview |  
| https://adk.dev/deploy/agent-runtime?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | ADK with Agent Runtime |  
[skipping for brevity]  

## Other Notes  

- "Vertex AI" no longer exists as a product; the replacement is Gemini   
  Enterprise Agent Platform.  
- "Vertex AI Agent Engine" is no more; the replacement is "Agent Runtime",   
  which is a part of the Gemini Enterprise Agent Platform.  
- But APIs and Google internal resource names may still refer to legacy names,   
  e.g. `reasoningEngine` rather than Agent Runtime. Always use the new names   
  when creating documentation, but be mindful that we may need to use old   
  names in API calls and certain resource definitions.  

## Blog  

I want to build a multi-part blog series, which I'll post on Medium and Dev.to.  

### Documenting As We Go  

As we go, document steps taken, experience and findings in docs/blog.md.   
Later, I will build a Medium blog from this content. During this "as we go"   
phase, the blog.md does not need to be a collection of notes, code snippets, and observations. It should:  

- Include all the key steps we did, in the order we did them.  
[skipping for brevity]

If you’re following along and you’ve just created your context file, give Agy a restart now, so it picks this up.

Documentation Approach

I’m a big fan of having a consistent set of high-quality, continuously maintained documentation. I even have my own agent skill — maintaining-core-documentation - to automate much of this for me. Check out my previous blog on this subject: Documentation as Context: A Skill to Automate Your Blueprints for the Agentic Era.

If you previously ran the npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g command from above, then you already have this skill installed.

With this in place, you could issue this prompt to bootstrap a set of documentation for a brand-new project:

Use maintaining-core-documentation to bootstrap my project documentation.

Check out this video to see the skill doing its magic!

As you evolve your project, this skill will automatically maintain your documentation.

MCP Servers for Your Coding Agent

I’ve previously written about some of my favourite MCP servers. There are only a couple that we’ll need for this project:

Note that we won’t be using either of these in the FinSavant agent itself. These are purely to help us during development.

Let’s try out the BigQuery MCP server first. In your workspace’s .agents/mcp_config.json file, we configure the Remote BigQuery MCP server like this:

{  
  "mcpServers": {  
    "bigquery-mcp-server": {  
      "serverUrl": "https://bigquery.googleapis.com/mcp",  
      "authProviderType": "google_credentials",  
      "oauth": {  
        "scopes": [  
          "https://www.googleapis.com/auth/bigquery"  
        ]  
      },  
      "headers": {  
        "x-goog-user-project": "your-gcp-billing-project"  
      }  
    }  
  }  
}

A few things to note about this:

Billing project: Replace your-gcp-billing-project with the Google project where your billing data export lives.

BigQuery API: Make sure the BigQuery API (bigquery.googleapis.com) is enabled on that project.
Developer Identity Permissions: Because the MCP server uses google_credentials to authenticate, your local developer account (active in gcloud auth) must be authorised on Google Cloud. You need the roles/bigquery.dataViewer and roles/bigquery.jobUser roles on the project hosting the billing dataset.
You also need the roles/mcp.toolUser role, in order to use this managed MCP server to query the BigQuery database.

And now, when you open the workspace in Antigravity IDE, it will load this configuration automatically. Your coding agent will be able to query schemas, inspect tables, and try out SQL queries in order to assist you when you actually create the FinSavant agent code.

Let’s test it!

First, I issue this prompt to the Agy agent:

What billing tables do I have? Explain their key functions.

You can see the agent immediately finds the MCP server and asks for permission to invoke its tools. After I grant permission, I get this response:

Nice! You can see how helpful this is going to be.

Scaffolding Your ADK Agent

The easiest way to scaffold a new ADK agent is to make use of Google Agents CLI. The Agents CLI is actually a bundle, containing:

The Agents CLI itself — commands for scaffolding, evaluating, deploying, and observing AI agents on Google Cloud. The GitHub repo describes the commands available:

An associated set of agent skills that turn your development agent into an expert in using Agents CLI.

You install the bundle using this one-time command:

uvx google-agents-cli setup

If you already have it installed, then you can upgrade like this:

uv tool upgrade google-agents-cli

(It’s worth doing this occasionally — this CLI is evolving quickly!)

With this installed, we could create our top level agent folder that contains a root agent called finops_agent by running this command:

agents-cli scaffold create agent \
  --agent adk \
  --prototype \
  --agent-directory finops_agent

You’ll end up with the following inside of your workspace folder:

agent/  
├── finops_agent/                 # Your agent code  
│   ├── __init__.py               # Registers the app (exports `app`)  
│   ├── agent.py                  # Agent definition — instructions, model, tools  
│   └── app_utils/                # Utilities (telemetry, converters)  
│       ├── __init__.py  
│       ├── telemetry.py          # OpenTelemetry setup for Cloud Trace  
│       ├── typing.py             # Request/response Pydantic models  
│       └── gcs.py                # GCS utility functions  
│  
├── tests/  
│   ├── eval/                     # Evaluation test cases  
│   │   ├── datasets/  
│   │   │   └── basic-dataset.json    # Default eval cases  
│   │   └── eval_config.yaml          # Evaluation metrics configuration  
│   ├── integration/  
│   │   └── test_agent.py         # Integration test (runs agent end-to-end)  
│   └── unit/  
│       └── test_dummy.py         # Placeholder for unit tests  
│  
├── .env                          # Environment variables (project ID, location)  
├── .env.example                  # Example environment variables  
├── .gitignore                    # Git ignore file  
├── pyproject.toml                # Project config and dependencies  
├── agents-cli-manifest.yaml      # Configuration for agents-cli  
├── Dockerfile                    # Dockerfile for the agent runtime  
└── GEMINI.md                     # Guidance file for coding agents

But since we now have the skills installed, there’s an easier way to accomplish this, that doesn’t require you to check the CLI documentation…

Please bootstrap a new ADK agent project. The agent top-level project should   
be named `agent`, and it should contain a root `agent-directory` called   
`finops_agent`, NOT the default of `app`. This means `pyproject.toml` and   
other config files will live under `agent/`, and all Python source files   
(like `agent.py` and `fast_api_app.py`) will live inside   
`agent/finops_agent/`.

Sure, this prompt is quite detailed, but I’m after a very specific folder structure.

Let’s see a live demo…

As you can see from the demo, we can now use agents-cli to check if our newly scaffolded agent is working.

For example, by issuing a single test prompt on the command line:

cd agent  
agents-cli run "Hello! Who are you?"

Or, we could run up the extremely powerful and useful ADK Web interface, using this handy shortcut:

# From the agent folder
agents-cli playground

Concluding thought about Agents-CLI: if you know your way around the CLI, you can use it directly. It'll be faster and use fewer tokens. But when you're doing lots of agent related activities like boostrapping, adding CI/CD, deploying and evaluating, you'll probably find that natural language conversations are going to save you a lot of time and pain.

Bonus #1: Getting Started with a Makefile

In a “monorepo” project setup like FinSavant, you quickly end up managing a lot of moving parts: building frontend assets, compiling Python environments, building and running multiple Docker images, executing test suites, and deploying resources to various target environments.

Rather than forcing yourself (or your team) to remember a massive list of commands and flags, wrapping them in a Makefile is a big win.

But what actually is a Makefile? At its core, it is a configuration file used by the classic make build automation tool. These days it has evolved into a lightweight, standardised task runner. It allows us to define short aliases (known as "targets") for complex shell commands, documenting project workflows in a single, standard file that is easy for both humans and agents to discover.

Earlier, during the demonstration of bootstrapping the project, the agent actually created an initial Makefile for us. If you followed along, you'll now have a Makefile that looks something like this:

.PHONY: install lint format lint-fix test  

install:  
    @command -v uv >/dev/null 2>&1 || { echo "uv is not installed. Installing uv..."; curl -LsSf https://astral.sh/uv/0.11.16/install.sh | sh; source $HOME/.local/bin/env; }  
    uv sync  

lint:  
    uvx codespell@latest -s  
    uvx ruff@latest check .  

lint-fix:  
    uvx codespell@latest -w  
    uvx ruff@latest check --fix .  

test:  
    uv run pytest tests/

Now you can run any of these make targets, like this:

make install

With this in place, we can build on it in future articles as we develop the FinSavant solution.

Bonus #2: My Setup-Env Script

These days, whenever I’m working on a project that makes use of Google services, I always create a helper setup-env script to configure my environment for me.

This script:

Loads environment variables: Automatically exports all key/value pairs from .env directly into the current shell session.
Handles Google Cloud authentication: If not skipped (via the --noauth flag), it runs gcloud auth login --update-adc to authenticate the user and configure Google Application Default Credentials (ADC).
Sets the active gcloud project: Configures gcloud defaults for the target project and billing quota project settings.
Extracts project metadata: Dynamically retrieves the Google Cloud Project Number and constructs helper variables (like the Cloud Build service account email) for deployment scripts.
Synchronises Python dependencies: Runs uv sync to ensure all standard, development, and notebook dependencies are installed in the local environment.
Activates the virtual environment: Activates the local Python virtual environment (.venv) so the user is immediately ready to run code.

You can find a copy of this scripts/setup-env.sh in my GitHub repository. Because it uses standard environment variables defined in your .env, you can use it in any of your Google projects!

You run it from the project root directory like this:

source scripts/setup-env.sh

Bonus #3: Automating Setup with `direnv` and `.envrc`

If you haven’t come across this before, I think you’re going to like it!

Manually sourcing the setup-env.sh script every time I open a terminal in the project directory is a bit of a chore. To automate this, we can use direnv — an extension for your shell that automatically runs custom scripts and loads / unloads environment variables depending on your current directory.

By placing a .envrc file at the root of the project, direnv automatically executes it whenever you cd into the directory.

Here is what our .envrc looks like:

if [ ! -d ".venv" ]; then  
  uv venv  
fi  

# Check if gcloud token is still valid to avoid re-authenticating  
if gcloud auth print-access-token --quiet > /dev/null 2>&1; then  
  echo "gcloud token is valid, skipping authentication."  
  source scripts/setup-env.sh --noauth  
else  
  echo "gcloud token is not valid, re-authenticating."  
  source scripts/setup-env.sh  
fi

This configuration does a few smart things:

Bootstraps the virtual environment: Automatically initialises a virtual environment using uv venv if it doesn't already exist.
Verifies active Google session: Runs gcloud auth print-access-token silently to check if our Google Cloud session is active.
Conditionally sources configuration: If the Google Cloud session is still valid, it sources the setup-env script with the --noauth flag, avoiding repetitive and annoying browser login prompts. If the session has expired, it triggers the full setup script to re-authenticate.

There are a couple of one-off steps we have to do to get direnv up and running:

Install direnv. On Debian/Ubuntu systems, this is sudo apt install direnv.
Allow this folder for direnv. Run direnv allow in the terminal, in the project folder where we've placed our .envrc file.

Now, when we enter our project folder, the script runs automatically, like this:

Pretty neat, right?

Wrap-Up and Next Steps

Okay, we’re done with the environment setup. We’ve:

Setup Google Antigravity, along with some killer skills and MCP servers
Bootstrapped our project using the Agy agent
Played with /grill-me
Established an initial set of core project documentation, using a custom skill
Used the Agy agent to bootstrap an ADK agent, making use of agents-cli and its skills
Created a Makefile for standardising common development, testing and deployment tasks
Created a scripts/setup-env.sh script for setting up our Google Cloud environment
Used direnv and a .envrc file to automate the setup process, every time we open a terminal in this directory

In the next part, we’ll look at the actual code for our FinSavant agents and tools!

See you there!

Before You Go

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

Useful Links and References

Project Demo & Portfolio

Gemini Enterprise Agent Platform & ADK

Google Cloud Services & APIs

FinSavant Part 1: Building an Agentic FinOps Platform with Google ADK, A2UI and Gemini Enterprise Agent Platform — Goals, Architecture, and Tech Stack

Darren "Dazbo" Lester — Wed, 01 Jul 2026 04:25:12 +0000

Welcome

Hello folks, Dazbo here. I’m on holiday, which means I’ve got time to catch-up on some blogging of my recent experiments!

If you’ve ever had to manage a Google Cloud Platform footprint of any decent size, you’ll know the feeling. You open up the billing console, look at the monthly total, and feel your eyes water. You start digging into dashboards, trying to map raw costs to actual running infrastructure, and quickly realise you’re essentially flying blind.

To be fair, Google has made a bunch of improvements lately, with its own Google Cloud FinOps Hub. As Google describes it:

“The FinOps hub presents all of your active savings and optimization opportunities in one dashboard.”

But I wanted to build my own agentic FinOps solution, for a few reasons. Some are about the FinOps capability itself:

I want to be able to have natural language conversations with the agent. I want to be able to dig into my cost spikes, and ask follow-up questions.
I want an agentic solution that can combine information like what I spent last month, why I spent it, and why spending spikes occurred.
I want the solution to be able to immediately spot orphaned resources , such as unused VMs, unattached disks, or unused IP addresses. For example, a persistent disk costing us $100 a month might be adding value if it’s actually attached to a VM; but it’s a total waste of spend if it’s not. (Obviously, this is more of a problem for traditional IaaS infrastructure; this is not generally a concern for serverless services.)
I want the solution to understand Google Cloud architecture and best practices , so that it can advise what I should do, and why this is the most appropriate course of action.

But mainly, I wanted an excuse to experiment with some relatively new agentic services in Google Cloud:

I wanted to deploy to the new Gemini Enterprise Agent Runtime; the thing that has replaced Vertex AI Agent Engine.
I wanted to play with some of the associated Gemini Enterprise Agent Platform capabilities, such as native support for ADK agents, the Agent Registry , and built-in observabiltiy and telemetry.
I wanted to experiment with some specific tools and MCP servers.

Specifically:

Native BigQuery tools from ADK — in order to interrogate billing information in BigQuery.
Google Cloud Assist — to be able to obtain live insights from Google Cloud metrics and logging, and provide recommendations using Google built-in recommenders.
The Asset Inventory API — to determine our exact current deployment configuration, to identify orphaned resources, and to see what has changed.
The Developer Knowledge MCP — so that my agent always has the latest knowledge about Google products, services, APIs, architectures, and best practices.

And so, friends, I give you FinSavant , an agentic FinOps solution for GCP that gives you an active, infrastructure-aware virtual analyst that combines costs with real-time operational context, and can make recommendations about what you should do next.

This is what it looks like:

I’ve open sourced the project, and you can find the project and its code on GitHub. If you like it or think it's useful, please add a star to the GitHub repo.

GitHub - derailed-dash/smart-gcp-finops

Series Structure

Let’s see where we are in this series.

Goals, Architecture, and Tech Stack: Capabilities, project goals, target architecture, technology stack, and design decisions. 📍 You are here.
Dev Environment Setup with Google Antigravity, ADK, Agents CLI, MCP & Skills
Building the ADK Agent and API
Designing and Building the UI with Google Stitch and A2UI
Deployment with Gemini Enterprise Agent Platform, Agent Runtime, Cloud Run and IAP
Automating Deployment with CI/CD and Terraform
Agent Observability, Evaluation, and Tuning with Gemini Enterprise Agent Platform

FinSavant: How Does It Work?

FinSavant is a conversational agent that uses:

BigQuery Billing Exports to know exactly what our costs are, down to the resource ID. Of course, this means you need to be exporting you billing data to BigQuery in the first place. Setting up billing exports to BigQuery is a standard process.
Google Cloud Assist in order to interrogate our services, metrics and logs, and provide recommendations accordingly.
Google Cloud Asset Inventory to understand our real-time deployment configuration, but also to provide a 35-day audit history of every asset change in our GCP estate. We can use this to investigate any changes that may have driven a cost spike.
Developer Knowledge MCP to ground the agent with both broad and deep Google knowledge. This means that if you ask it any questions relating to Google Cloud, Google APIs, or general Google best practices, the agent will provide factually correct answers that are up-to-date, and with very little hallucination. For example, if a Cloud Run service seems costly, we can ask the agent for best practices on what we should do to reduce costs whilst, for example, maintaining availability.

By bringing these together under a GenAI agent built with the Google Agent Development Kit (ADK), we have created an assistant that can perform root-cause analysis on cost spikes, as well as provide recommendations on how to fix them.

Architecture Overview

When designing FinSavant, I wanted a clean separation between the frontend delivery mechanism and the agentic backend, while keeping deployment costs and security overhead to an absolute minimum.

The overall architecture looks like this:

Tech Stack & Design Decisions

Let’s dive into the core components that make up FinSavant’s tech stack and see how they complement one another.

User Interface: React/Vite

With React I can create a great looking UI, and I have the ability to render dynamic A2UI widgets. (More on this in a future part of the series.)

By the way: I’m no frontend developer. I used Stitch to help me design and prototype the frontend UI, and then I used Antigravity (Gemini) to turn this into React code.

I can compile the React UI to clean, static assets, so I don’t need Node.js. This means my frontend container image will be pretty small, and therefore fast and cheap to run.

Rich UI with Agent-to-UI (A2UI)

Rather than building a static dashboard or a free-form chatbot, FinSavant uses Agent-to-UI (A2UI) to dynamically render rich UI components like tables, charts, and summary cards directly from the LLM. This ensures the interface is always context-aware and adapts to the user’s specific query.

A2UI is Google’s declarative specification that enables agents to generate dynamic user interfaces in the form of JSON objects. So for FinSavant, the agent builds the UI component on-the-fly, and then our frontend just converts this JSON object into a React component and renders it.

This is a game-changer for building a UI. I don’t have to hard-code any UI components — the agent decides what to display in real time! I’ll show you exactly how to do this in a future part of the series.

Backend-for-Frontend (BFF)

The FastAPI BFF simply acts as a secure proxy. It streams queries to the agent and receives structured responses. But also, it allows us to decouple the backend from the UI. If I want surface this application through a different UI in the future — like Gemini Enterprise — I can.

UI & BFF Unified Container

I’ve packaged the React frontend and FastAPI BFF into a single container image. This eliminates cross-origin resource sharing (CORS) headaches, minimises the runtime footprint, and simplifies the deployment.

Cloud Run for Container Hosting

Cloud Run is Google’s serverless, zero-ops, autoscaling container hosting environment. This is perfect for hosting our UI/BFF container. There are a number of useful features I’m going to make use of:

It scales to 0, so it doesn’t cost anything when there’s no traffic.
It autoscales based on demand, but we can limit the number of instances in order to control costs.
It natively integrates with Google Identity-Aware Proxy, providing a simple way to ensure only authenticated / authorised users can get to our application. (This native integration, without need for a load balancer, is a fairly new feature.)
We can map a domain name to our Cloud Run service, without need for a separate load balancer. (This is quite a new feature.)

Authentication with Identity-Aware Proxy

I’ve secured the Cloud Run service using Google’s Identity-Aware Proxy (IAP). This is a cool service that both authenticates and authorises users before they can access our Cloud Run service. Unauthorised users will not be able to see the application.

Until recently, the only way to use IAP with Cloud Run was to put a load balancer in front of the Cloud Run service and associate IAP with the LB. This adds additional complexity and cost.

But now we can secure a Cloud Run service directly with IAP, without needing the LB. I’ve blogged about this before, when the feature first went into Preview. But now it’s Generally Available.

Agent Orchestration: Google Agent Development Kit (ADK)

ADK is an open source framework and SDK for building agents and agentic systems. These days I reach for it automatically.

This is what it gives us:

Powerful multi-agent orchestration.
Session context management.
Bi-directional streaming support.
Agnostic of AI model.
Agnostic of hosting environment, but optimised for hosting on the Google Agent Runtime.
Integrates natively with Gemini Enterprise Agent Platform / Agent Runtime.
Easy to configure telemetry and observability.
Really useful local development user interfaces.

Agent Runtime for ADK Agent Hosting

Having decided I wanted to deploy the agent independently of the frontend and FastAPI, the next question is: where should we deploy the agent itself?

In days gone by I would probably have deployed it to a separate Cloud Run service. But now we have Agent Runtime, Google’s evolution of their previous product, Agent Engine. It is built for hosting agents and has a number of benefits:

It is simple to deploy ADK agents to Agent Runtime, using the Agents CLI.
It is serverless and autoscaling.
When there’s no demand for the agent, there’s no cost.
Exposing the agent’s endpoint to consumers (like our BFF in Cloud Run) is trivial.
Agents deployed to Agent Runtime are automatically registered in the Gemini Enterprise Agent Platform’s Agent Registry.
Agents deployed to Agent Runtime can leverage the various capabilities of GEAP, like Memory Bank, Agent Gateway, Model Armor, telemetry, and agent evaluations.

Hybrid Execution Mode

To support a fast local development cycle, the BFF supports two different run modes:

Remote Execution Mode : In staging and production, the BFF acts as a stateless proxy to the remote agent, running on the Google Agent Runtime.
Local Fallback Mode : If no remote agent runtime ID is configured, FastAPI loads the agent code directly into the container and runs the ADK engine locally in a background thread, using the developer’s Application Default Credentials (ADC).

Project and Organisational Scope

I want FinSavant to give me a holistic view across all the projects that are incurring cost against my billing account. But at the same time, I only want FinSavant to provide insights for projects that I actually have authority to see.

But GCP resource hierarchies are rarely neat and tidy. Some of my projects live inside a nice, clean Google Cloud organisation, and some are standalone — essentially orphaned projects floating in the ether that are linked to the billing account but don’t inherit anything from an organisation root.

To solve this, I designed a multi-layered discovery and security boundary:

Billing-Led Discovery : Rather than scanning the Resource Manager from the top down (which misses standalone projects entirely), the backend starts by querying the Cloud Billing API to retrieve every project linked to our central billing account. This gives us a comprehensive list of all projects incurring costs.
Hierarchical Permission Resolution (With Caching): Once we have the master list of billing projects, we need to know what the user is actually allowed to see. The discovery service attempts a top-down interrogation:
Org-Level Scan (Fast): If a target organisation ID is configured, the backend queries Cloud Asset Inventory’s IAM policies. This is extremely fast because it lets us resolve all of the user’s project bindings across the entire hierarchy in a single API call.
Project-Level Fallback (Granular): If organisation-wide access isn’t available or fails (as is often the case with standalone projects outside the org boundary), the service seamlessly falls back to a project-by-project scan, calling getIamPolicy on each individual project in the billing list to compile the user's allowed set.
Performance Protection : To prevent rate limits and quota exhaustion from repeating project-by-project IAM scans, this resolved set is cached in-memory with a thread-safe, 10-minute time-to-live (TTL).
IAP-Enforced Row-Level Security : We serve the React dashboard and agent chat through an Identity-Aware Proxy (IAP). When a user requests data, the BFF extracts their email from the x-goog-authenticated-user-email header. It resolves their allowed projects list and sets it in a local context variable.
To prevent prompt injections or the agent from hallucinating data about projects the user shouldn’t see, we intercept all BigQuery billing queries and wrap them in a subquery that filters based on only the allowed projects. This means that even if the agent is querying the whole dataset, the database engine itself enforces strict row-level filtering based on the logged-in user’s identity. If the user only has access to one project, that’s all the agent can query.

Cloud Asset Inventory (CAI)

I’m using CAI for:

Zombie Detection : I built custom CAI queries to instantly scan for unattached disks and idle external IPs.
Detective Mode : When we detect a cost spike, the agent uses CAI history to audit the exact configuration changes that occurred on that resource over the last 35 days. For example, detecting that an engineer upscaled a Cloud Run instance memory limit.

BigQuery Tool Calls From Our Agents

I want to be able to query my billing data — stored in BigQuery — using natural language prompts. I’m achieving this in two different ways, depending on where I’m coming from.

In my development workspace, I’m using the Google remote managed BigQuery MCP server (https://bigquery.googleapis.com/mcp).
In our FinSavant ADK agent itself, I’m using ADK’s native BigQueryToolset directly. In doing so, we simplify authentication, reduce runtime latency when making BQ calls, reduce dependency on an external service, and align with ADK best practices.

Developer Knowledge MCP

To make FinSavant’s advice more than just generic feedback, we need to ground its recommendations in official Google Cloud engineering standards. That’s where the Developer Knowledge MCP comes in.

This MCP server provides a direct gateway to Google’s official developer documentation, product guides, API reference material, and the Cloud Architecture Framework. Instead of relying on the LLM’s static training data, the agent can query this knowledge base in real time to retrieve authoritative, up-to-date information.

In FinSavant, we use the Developer Knowledge MCP to:

Determine the Best Course of Action : When the agent discovers a cost anomaly, it doesn’t just throw alerts. It queries the MCP to formulate an appropriate, structured response grounded in official documentation.
Verify Architectural Best Practices : It checks current Google Cloud design patterns, ensuring the agent doesn’t recommend legacy or non-optimal resource structures.
Provide Actionable Remediation : If an idle persistent disk is flagged, the agent uses the MCP to outline the exact recommended steps to snapshot and clean up the asset safely, linking the user directly to the relevant documentation.
Eliminate Hallucinations : By grounding the agent in real-time documentation, we ensure any CLI commands or configuration snippets it presents are correct and match the latest GCP standards.

Let’s See It In Action!

In this short video I demonstrate a number of FinSavant features, including:

Using starter chips to kick off an initial converation, e.g. looking for cost spikes over the last 30 days
Seeing the various tools and MCP servers called in real time
Seeing recommendations based on the findings
Watching tiles and graph widgets being created in real time using A2UI
Asking follow-up questions about particular projects
Looking for other cost anomalies

Cool, right?

What’s Next?

In the next part of this series, we’ll get our hands dirty with Part 2: Building the Agentic Solution: Development with Google Antigravity, ADK, Agents CLI, MCP & Skills.

I’ll show you how to setup your development environment, how to boostrap ADK agents, and the code behind FinSavant.

Stay tuned!

Before You Go

Please share this with anyone that you think will be interested. It might help them, and it really helps me!
Please give me 50 claps! (Just hold down the clap button.)
Feel free to leave a comment 💬.
Follow and subscribe, so you don’t miss my content.

Useful Links and References

Project Code & Demo

Gemini Enterprise Agent Platform & ADK

Google Cloud Services & APIs

GCP Billing & FinOps

Articles & Resources

Portfolio

Dazbo’s Portfolio

Dialling Our Agents to 11: Agent Skills You Need to be Using!

Darren "Dazbo" Lester — Mon, 15 Jun 2026 03:25:13 +0000

What This Article Is About

Howdy friends!

Recently I wrote an article called Dialling Our Agents to 11: My Favourite MCP Servers. It talked about how MCP servers and skills are essential components in transforming a simple agent into a useful, dependable, grounded and multi-skilled agent harness. I listed my favourite MCP servers for productivity, and promised a follow-up article that focuses on agent skills.

Well, here it is!

Quick Skills Recap

If you don’t know what a skill is: think of it as a unit of knowledge and capability for an agent, loaded on-demand as required.

I recently did a talk on the topic of using MCP and skills to power-up our agents. In April I presented this at Google Next ’26 in Vegas:

My Incredible Google Cloud Next 26 Experience as a GDE

And in May I did a similar talk for Google Developer Group Prishtina, as part of the Google Build with AI roadshow.

Build with AI | Google for Developers

In that talk I explain what MCP and skills are, how they work, and how they differ. I talk about the use cases where skills are better than MCP servers and vice versa, and I talk about the scenarios where you might want to use them together.

Here’s a recording of the BwAI session for GDG Prishtina:

Favourite Skills

Time for me to talk about some of my favourite skills. I’ll explain what they are, how you use them, and how you install them.

By the way, they’re free (and open source), and off-the-shelf; including a few created by me.

1. Google Agent Skills / Agents-CLI

Let’s face it, building production-ready AI agents on Google Cloud used to feel like trying to build a functioning helicopter from a box of random Lego bricks. You had Vertex AI, sorry — I mean Gemini Enterprise Agent Platform, Cloud Run, APIs, service accounts, IAM roles, and about a thousand vector store options. Your poor coding assistant would choke on the complexity, even if grounded with good quality documentation.

The Google agents-cli is a game changer for this scenario. It’s a combined CLI and set of skills for building, evaluating and deploying agents in Google Cloud. Now your assistant gets the exact API references, schemas, and scaffolding patterns it needs to build, test, and ship agents without having to guess the plumbing.

Because it’s actually a combination of CLI and skills, we can use it in two ways:

We can just run CLI commands directly from our terminal.
We can use skills to inform our coding agent about how to use the CLI.

Setup

Installation is a piece of cake. You can bootstrap the environment using uv — which, as you know, is my absolute favourite environment manager:

uvx google-agents-cli setup

Use

With the CLI and skills installed, we can issue prompts like these to our coding agent:

“ Build a support agent that answers questions from our docs. I want to build using Agent Development Kit (ADK) and I want to deploy to Google Cloud eventually.”
“Write evals for the Rickbot agent and run them”
“ Deploy this to Cloud Run”
“ Integrate this with Gemini Enterprise”

Past-Me used to build agents, run some unit tests, try a few manual prompts to the agent and declare: “Yep, looks good to me!”

Don’t be Past-Me. This agents-cli framework makes it so easy to add agentic reviews to your development process.

How Is it Different to Developer Knowledge and gcloud MCP Servers?

If you are already using Google tools in your IDE, you might wonder how this fits in with the other tools at your disposal:

Google Developer Knowledge MCP (The Library 📚): A read-only lookup tool. It tells the agent how GCP works (services, products, APIs and syntax) but doesn’t run commands or build resources.
gcloud MCP (The Muscle 💪): Exposes low-level SDK commands. You supply natural language commands and your agent executes the gcloud commands to turn your wishes into reality. But has zero built-in understanding of agent architecture, ADK code, or prompt tuning.

But the Google agents-cli is more like an orchestrator built specifically for the Agent Development Lifecycle (ADLC). And it knows how to leverage and deploy appropriate services in the Google Cloud ecosystem. It abstracts low-level GCP setup into single commands and adds agent-specific capabilities like evaluation runs and version trajectory grading.

Fun Fact

The Google Agents-CLI has replaced the Google Agent Starter Pack.

2. Vercel Labs Find-Skills

Every great software ecosystem needs a package manager — think apt for Debian, npm for Node.js, uv for Python — and the AI agent world is no different. Enter the Skills CLI (npx skills), a package manager developed by Vercel Labs. It lets you discover, install, and update modular packages (skills) that expand your agent’s capabilities.

But wait! What’s the difference between the Skills CLI and the find-skills skill? It’s actually a really neat inception-style loop:

The Skills CLI (npx skills) is the command-line package manager tool itself (analogous to the npm binary). It is the mechanism that physically installs, checks, and updates skills on your machine.
The find-skills skill is the on-demand knowledge that you install into your agent's brain using that package manager.

Without the find-skills skill loaded, if you ask your assistant: "Hey, is there a skill to help me write Playwright E2E tests?", the agent will just guess or tell you it doesn't know. Once you install the find-skills skill, it teaches your agent when and how to run the npx skills find CLI command on your behalf — allowing the agent to self-extend based on your requirements.

Setup

npx skills add https://github.com/vercel-labs/skills -y -g - skill find-skills

Use

Once installed, you can search for capabilities directly using natural language. For instance:

“Find and list some skills to help me write and maintain high quality software project documentation”

In response to this, the skill advises my agent (Antigravity) on the command to run, and prompts me for approval:

It finds a bunch of skills (alas, not the skill I was hoping it would find — more on that later!), and asks if I want to install any of them:

Also, just like any other package manager, you can actually use npx skills and find-skills to update your set of skills. I only just found out this is possible!!

Nice!

Pro Tip: Check the Leaderboard!

Before you install a random skill, head over to skills.sh to see the Open Skills leaderboard. This leaderboard automatically tracks open skills, along with GitHub metrics and the number of npx-based installs. From here, you can see the skills that are most popular and most trusted.

3. Dazbo Agent Skills

Yes, I’m biased. But sometimes, you need a specialized toolset that addresses very specific workflows — which is exactly why I created my own suite of custom skills. But then, of course, I realised that these skills will often be useful to others, so I uploaded them to GitHub.

The dazbo-agent-skills repository is a curated collection of skills that I use often. In the box, you get:

`maintain-core-documentation`

A specialist framework that guides the creation and maintenance of high quality core documentation files, including README.md, TODO.md, DESIGN.md (for Stitch-compatible UI spec), Architecture.md, Testing.md, and Deployment.md (for setup, Infra-as-Code, GitOps and CI/CD).

It also leverages the technical-writer skill, which I’ll mention later.

`deploy-skills-in-antigravity`

A global installer and relocator that automates adding or updating agent skills via npx and safely moves them to my preferred shared global path (~/.gemini/skills/).

`convert-to-devto`

A skill that automatically converts, structures and standardises Markdown files for publication on dev.to.

Basically, it takes your input and reformats to the required dev.to markdown format, including injection of the YAML frontmatter, formatting of inline variables, handling of nested code blocks, and converting links to dev.to-compatible Liquid tags.

Because I often post blogs like this on both Medium and dev.to, it saves me a huge amount of time in performing the appropriate conversion.

`secrets-with-git-crypt`

Have you ever accidentally committed a local file that contained sensitive information, like an API key? I bet you’ve read some horror stories of what happens if you do! (Like waking up to a five-figure cloud bill because your GCP credentials got scraped off GitHub within 30 seconds).

This skill provides a workflow that leverages git-crypt — an open-source tool that enables transparent encryption and decryption of files in a Git repository using AES-256 encryption.

I use this skill to ensure that if my repo has any files with sensitive configuration — like a .env or terraform.tfvars— the skill detects it, ensures it is ignored by git (by automatically adding to my .gitignore), but also offers to create an encrypted version that will be stored in the repo. This is useful, because then the encrypted version can be pulled to any other machines I’m working on and decrypted locally. And the skill manages the decryption and synchronisation between encrypted and non-encrypted versions for me.

Sure, you could just use a Secret Manager, or use GitHub secrets. But this approach is very convenient and operates completely transparently.

`create-md-from-browsermcp-snapshot`

One thing I often want to do is create a markdown version of a web page. This is especially useful for turning a page into quick, persistent context for my agent.

Often, this is something that can be easily achieved using the Browser Agent built into Antigravity. But sometimes this isn’t possible, and I’ve explained these scenarios here. In these scenarios, I use BrowserMCP to remote control and read a specific Chrome browser tab. But the BrowserMCP tools are not natively able to create markdown. And so I created a skill which executes Python to turn the BrowserMCP JSON output into high-fidelity markdown.

Setup

You can install all these skills in one hit, or just install the ones that look most interesting to you:

# All Dazbo skills
npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g

# Installing a specific Dazbo skill
npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g --skill maintaining-core-documentation

If You Like These Skills…

Please add a star to my repo!

4. Google Skills

If you are building systems on Google Cloud, you don’t want your AI assistant to guess how to configure your databases or auto-scale your clusters. You want the official blueprints.

The official Google Skills repository (google/skills) is a collection of skills that provide AI agents with precise, up-to-date knowledge of Google Cloud services and architectural standards. And since they exist as multiple skills with well-defined narrow scopes, they’re only loaded when you’re working on a relevant service.

With these installed, you’ll find that agent output is much higher quality, token usage goes down considerably, and the number of loops required to achieve a goal is also reduced. It will save you time and money!

What’s in the Box?

To help make sense of the repository, the skills are categorised into three main logical groups:

Agent Platform Skills:

agent-platform-deploy : Automates the packaging and deployment of AI agents to Google Cloud platforms (like Cloud Run or GKE) with proper service bindings.
agent-platform-endpoint-management : Configures and manages Vertex AI model endpoints, routing, and access control.
agent-platform-eval-flywheel : Sets up continuous evaluation pipelines for monitoring agent response quality over time.
agent-platform-inference : Directs optimal model invocation patterns, including parameter tuning, fallback models, and token budget management.
agent-platform-migrate-from-ai-studio : Streamlines porting agent prompts and configs from Google AI Studio to enterprise Vertex AI environments.
agent-platform-model-registry : Tracks and organises different versions of foundation and tuned models within Vertex AI.
agent-platform-prompt-management : Version-controls system prompts, system instructions, and few-shot examples independently of the application code.
agent-platform-rag-engine-management : Guides the configuration of document chunking, indexing, and vector database retrieval settings for grounding.
agent-platform-skill-registry : Manages the life cycle of installed agent tools and skills, ensuring correct schema definitions.
agent-platform-tuning-management : Oversees model tuning jobs, tracking parameters, and comparing metrics across different runs.
agent-platform-tuning : Provides instructions for formatting datasets and executing supervised fine-tuning (SFT) jobs for Gemini models.

Core Services & APIs:

alloydb-basics : Scaffolds and optimises Google's enterprise-grade PostgreSQL-compatible database, including pgvector setup.
bigquery-basics : Guides dataset creation, partitioning, clustering, and writing optimised SQL queries for massive data analysis.
cloud-run-basics : Handles containerised application deployment, scaling configurations, and setting up HTTPS endpoints in seconds.
cloud-sql-basics : Scaffolds and secures managed database instances (PostgreSQL, MySQL, SQL Server) in Google Cloud.
firebase-basics : Scaffolds mobile/web backends, including Firestore database rules, Authentication, and Cloud Storage setup.
gcloud : Bridges the gap between your coding agent and low-level CLI infrastructure commands, ensuring correct flags and parameters.
gemini-agents-api : Guides integration with Vertex AI Agent Builder APIs for orchestrating pre-built agentic workflows.
gemini-api : Formulates correct payloads, system instructions, and schema definitions for the Gemini developer API.
gemini-interactions-api : Configures chat history buffers, session state persistence, and conversational turn-taking logic.
gke-basics : Scaffolds Google Kubernetes Engine clusters, container deployments, ingress controllers, and namespace isolation.
workload-manager-basics : Evaluates, configures, and runs best-practice checks on complex cloud workloads (like SAP or high-performance computing).

Well-Architected Framework (WAF), Recipes and Operations:

google-cloud-networking-observability : Guides setting up VPC Flow Logs, Connectivity Tests, and Network Intelligence Center dashboards.
google-cloud-recipe-auth : Implements best-practice authentication flows, from simple API keys to complex OAuth2 and service accounts.
google-cloud-recipe-onboarding : Automates initial GCP landing zone setup, including IAM bindings, project creation, and resource hierarchies.
google-cloud-waf-cost-optimization : Aligns setups with Google's cost-saving principles (like rightsizing, billing alerts, and lifecycle rules).
google-cloud-waf-operational-excellence : Configures monitoring dashboards, alerts, health checks, and structured logging policies.
google-cloud-waf-performance-optimization : Guides resource profiling, caching strategies, database indexing, and low-latency network setups.
google-cloud-waf-reliability : Configures multi-region failovers, automated backups, load balancers, and disaster recovery strategies.
google-cloud-waf-security : Enforces Least Privilege access, identity federation, secret rotation, and data encryption at rest and in transit.
google-cloud-waf-sustainability : Details carbon footprint tracking and architecting workloads to minimise compute-hour waste.

How do “Agent Platform Skills” Differ from “Google Agent Skills”?

With Google agent skills appearing in two sections, you may be wondering how they differ.

The Google Agent Skills are focussed on the developer workflow. They help our developer agent to know how to build, scaffold, evaluate, and deploy agents, leveraging the Agents-CLI.
The Agent Platform Skills from the Google Skills repo are focused on the underlying architectural blueprints of Gemini Enterprise Agent Platform services. They teach the agent how to configure the platform control plane, such as setting up RAG, vector stores, and model fine-tuning jobs.

In short: Google Agents Skills help you to build and run agents; Agent Platform Skills give us the deep system capabilities and blueprints.

Setup

# To install all the skills
npx skills add https://github.com/google/skills -y -g

# To install an individual skill (e.g. alloydb-basics)
npx skills add https://github.com/google/skills -y -g --skill alloydb-basics

Pro Tip

By keeping these skills installed globally, you ensure that if you ask your assistant to design a BigQuery schema or secure a Cloud Run service, it automatically references the exact WAF parameters without you having to copy-paste documents.

5. Awesome Agent Skills

If you’re looking for the Swiss Army knife of specialised agent capabilities, my buddy Shubham Saboo has built an absolute goldmine. His repository, awesome-llm-apps, is incredibly popular in the AI engineering community — sitting at a staggering 114,000+ stars on GitHub!

While the repo started as a showcase for RAG and agent patterns, it also includes a dedicated awesome_agent_skills directory. The goal of this collection is to provide developers with modular, plug-and-play skills that teach AI assistants how to handle specific tasks with professional-grade precision.

If you browse the Open Skills leaderboard on skills.sh, you’ll find that Shubham’s skills are frequently trending near the top. According to the registry, the top 5 most popular skills from his package are:

deep-research — Highly installed for conducting comprehensive, multi-source investigations.
fact-checker — A specialised claim-verification tool.
technical-writer — For generating developer-friendly API references and guides.
debugger — A systematic troubleshooting skill for bug isolation.
fullstack-developer — Blueprints for web development covering React, Next.js, and database architectures.

Let’s do a mild deep dive into the three skills I use most often in my own workflows…

Deep Research

For conducting thorough investigations and synthesising multiple perspectives with clean citations, the deep-research skill acts as your agent’s private investigator.

It instructs the agent to break down a complex, open-ended query into smaller, logical subtopics. The agent then gathers and cross-references information from multiple sources, eventually generating a structured research report. The output is complete with an executive summary, detailed breakdowns, consensus vs. debate analyses, and inline citations pointing to original sources.

To install it globally:

npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill deep-research

Fact Checker

The ultimate BS detector.

If you need to verify statistics, cross-reference claims, or check for potential bias or misinformation in a document, the fact-checker skill is your go-to.

It teaches your agent to dissect text into testable assertions and evaluate them using a strict, evidence-based scale — ranging from ✅ TRUE to 🚫 FALSE. It is particularly good at spotting subtle logical fallacies, statistics pulled out of context, and missing caveats.

To install it globally:

npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill fact-checker

Technical Writer

Clear documentation is a developer’s superpower, but writing it is often a chore. The technical-writer skill gives your agent the exact templates and principles needed to write high-quality technical guides.

It directs the agent to write using a clear, active voice in the present tense. Crucially, it enforces the principle of progressive disclosure — structuring documents so that the quick-start guide, code snippets, and interactive examples appear first, while the massive, dry reference tables and configurations are pushed to the end of the document.

Fun fact: my own maintain-core-documentation skill actually makes use of the technical-writer skill, if it can. (It will offer to install it, if it’s not yet installed.)

To install it globally:

npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill technical-writer

6. Remotion Best Practices

If you’ve ever tried to generate programmatic videos, you probably ended up writing spaghetti scripts calling ffmpeg command strings that looked like ancient hieroglyphics.

Remotion changes the game by letting you build real, high-quality MP4 videos using React components, HTML, and CSS. The remotion-best-practices skill provides coding assistants with the complete ruleset for scaffolding, animating, and rendering Remotion videos safely.

What’s Inside the Box?

Project Scaffolding: Instructions on bootstrapping clean projects immediately
Animation Rules: Animating elements mathematically.
Asset Handling: Enforces using Remotion’s specialized media components (<Img>, <Video>, and <Audio> from @remotion/media) wrapped in the staticFile() helper to reference files in the local /public folder.
Studio & Rendering: Commands to start the local preview server (npx remotion studio) and render single frames to sanity-check layouts.

Setup

npx skills add https://github.com/remotion-dev/skills -y -g --skill remotion-best-practices

Typical Use Cases for Remotion

Remotion is an absolute game-changer in scenarios where you need to move beyond desktop editors and build scalable video pipelines:

Personalised Video Reels : Generating user-specific analytics videos (like “Year-in-Review” summaries) or custom onboarding clips dynamically at run time.
Real-time Content Teasers : Turning text articles, RSS feeds, or news updates into short video summaries and teasers for social media automatically.
Interactive Parameter Editing : Building interfaces where non-technical users can tweak text, colors, or transitions and preview renders instantly in their browser.
Headless Rendering Pipelines : Running serverless video rendering to stitch clips, apply dynamic watermarks, and spit out MP4s programmatically.

Real-World Example: Prompt-to-Video Engine

To see just how powerful the combination of AI and Remotion is, I asked my coding assistant to build a working prototype: a Prompt-to-Video Engine.

“Create a 15-second teaser for Antigravity, an agent first development environment for turning ideas into reality, built on Google Gemini technology. Let’s turn months into minutes. Dark theme. Pull in Google Antigravity visuals.”

In response to this prompt, the coding assistant leveraged the remotion-best-practices skill to implement the following system:

The Generator (generate_video.py): A Python script that uses the modern google-genai SDK and Pydantic validation to translate my prompt into a structured JSON configuration (video-data.json), selecting dark-mode colors, highlights, and scene copy. It automatically authenticates via Google Cloud Vertex AI or Developer APIs.
The Remotion Template (VideoTemplate.tsx): A parameterised React component that reads the generated JSON configuration, imports modern typography dynamically using @remotion/google-fonts, and applies custom Bézier animation curves (interpolate) to animate headings, dividers, and body copy frame-by-frame.
Dynamic Composition (Root.tsx): Configured to dynamically compute the video's total frames based on the scene durations returned by Gemini.

The agent then generated a still image from one second in, to test the application:

And then it went ahead and created the full 15 second video.

If I wanted to edit the video and re-generate, it would be as simple as asking the agent to update the application, or I could just manually edit the scene file that the agent created for me:

{
  "background_color": "#0D0E15",
  "accent_color": "#6366F1",
  "text_color": "#F3F4F6",
  "scenes": [
    {
      "title": "Ideas Grounded?",
      "subtitle": "Traditional development slows innovation. Complex, manual, frustrating.",
      "duration_secs": 3.5
    },
    {
      "title": "Antigravity: Agent-First",
      "subtitle": "Powered by Google Gemini. Intelligent agents transform concepts into reality.",
      "duration_secs": 4.5
    },
    {
      "title": "Months to Minutes",
      "subtitle": "Accelerate from vision to deployed product at unprecedented speed. Build smarter.",
      "duration_secs": 4.0
    },
    {
      "title": "Antigravity.",
      "subtitle": "Your ideas, unleashed. Experience the future of development.",
      "duration_secs": 3.0
    }
  ]
}

7. Google Genmedia Skills

In Part 1 of this miniseries, I explored several media-focussed MCP servers, such as avtool (which wraps the command-line Swiss Army knife ffmpeg), chirp3-hd (for high-fidelity speech synthesis), and lyria (for generative music).

But Why Do We Need the Skills?

You might wonder: if my agent has access to avtool and therefore ffmpeg commands via MCP, why does it need skills?

Whilst those servers provide the raw capabilities — the “hands and eyes” to manipulate media files — they do not teach the agent how to compose media like a professional.

That is where the Google Genmedia Skills come in. These skills supply the procedural knowledge, prompt blueprints, and guardrails necessary to transform a basic coding assistant into a competent, multi-talented media showrunner.

Let’s look at the difference between atomic tasks and composite creative tasks :

The Atomic Task Scenario: MCP is Sufficient

Suppose you ask the agent:

“Extract the first 10 seconds of this video and save it as a new clip.”

This is a straightforward, single-step operation. The agent simply looks at the tools exposed by the avtool MCP server, identifies the correct command, and executes a standard ffmpeg trim. No special domain expertise or workflow management is required. The raw MCP server is perfectly sufficient.

The Composite Creative Task — Skills Required

Now suppose you give a more complex prompt:

“Generate a 15-second promotional clip using a warm narrator voiceover, a low-key background music track, and place our company logo watermark in the bottom-right corner. Make sure the video loops cleanly if the audio runs slightly over.”

Without specialised skills, a naive agent will likely fail in several ways:

Audio clashing: It will layer the narrator and background music at default volumes, resulting in a loud, unintelligible mess. (No vocal boosting; no music ducking.)
Watermark coordinate guesswork: It will try to overlay the logo image at a random coordinate, likely cropping it or placing it off-screen, since it doesn’t know it must first probe the video dimensions and calculate the offset mathematically.
Audio-video desync: If the voiceover runs to 16.5 seconds, the 15-second video will abruptly cut off or loop incorrectly, ruining the pacing.
Unrefined prompts: It will send a dry, text prompt to Gemini TTS or Imagen, resulting in a flat, robotic voiceover and a generic style.

The Genmedia skills solve this by encoding the exact workflows, volume offsets, and coordinate calculations used by real video editors and audio engineers, guiding the agent to orchestrate these tool calls systematically.

What’s Inside the Box?

genmedia-producer : The master orchestrator for complex multi-step media workflows. It guides the agent through storyboarding, script sanitisation (such as removing markdown syntax before synthesis), and matching video total runtime with audio duration.
genmedia-video-editor : Expert knowledge in FFmpeg composition. It handles video stitching, two-pass high-quality GIF generation, and teaches the agent how to mathematically calculate watermark coordinates after querying media dimensions.
genmedia-audio-engineer : Specialist in high-fidelity speech synthesis, music generation, and multi-track mixing. It instructs the agent on professional volume adjustments — boosting voiceovers while lowering background music — and ensuring sample rates match to prevent pitch shifts.
genmedia-image-artist : A direct line to Gemini image generation. It guides prompt building using professional terminology (like "chiaroscuro" lighting or "bokeh" lens effects) and handles collaborative, iterative refinements using multimodal inputs (like PDFs or video reference frames).
genmedia-voice-director : Expert director for virtual voice actors. It instructs the agent to treat Gemini TTS as talent, setting detailed scenes and using bracketed inline audio tags (like [sigh], [laughs], [enthusiasm], or [long pause]) within transcripts to shape realistic, emotional delivery.
story-generator : A heavy-duty, feedback-driven media engine that orchestrates parallel subagents to build full multi-scene storybooks (complete with images, video, voice, and music).

Setup

To install the Genmedia skills suite globally:

npx skills add https://github.com/GoogleCloudPlatform/vertex-ai-creative-studio/experiments/mcp-genmedia/skills -y -g

Real Demo

Let’s take the 15 second video I created with Remotion, and then use the GenMedia skills to add an audio track:

“Using the GenMedia skills, generate a 15-second ambient, futuristic electronic synth track matching the duration of our teaser video out.mp4. Mix this music track into the video as background audio using avtool, set the music volume to a subtle level (e.g. -18dB) so it doesn't overpower, and output the final file to media-output/agy_teaser_with_music.mp4."

First, Agy asks for permission to use Lyria:

Then it prompts to allow avtool. And then, after no more than about 5 seconds of work:

Let’s add a voiceover.

“Now, using GenMedia skills, please add a professional voiceover over the top. English female voice. Render the new video as agy_teaser_with_music_and_voiceover. The voice over should just include the main punchy statements from each scene.”

And the result:

Insane! All done in less than 5 minutes.

Of course, we could have just generated the whole video with Veo, or even Google Flow. But producing the original video with Remotion gives us a deterministic result with very specific aesthetic controls.

8. Google Data Agent Kit

If you are a data engineer or data scientist, a huge portion of your day is likely spent on the “tab-hopping” loop — jumping between the BigQuery console, Python notebooks, dbt terminals, and your AI chat window. Google’s open-source Data Agent Kit (DAK) is designed to a) eliminate this context-switching fatigue and b) give your agent knowledge of best practices for all of the various data services in the Google ecosystem.

By embedding live metadata access and MCP tools directly into your IDE, DAK gives your coding agent a direct line of sight into your Google Cloud data estate. DAK integrates natively with Antigravity IDE and VS Code, via the Google Cloud Data Agent Kit extension.

What’s Inside the Box?

Unified Data Estate Hub: Consolidates databases (AlloyDB for PostgreSQL, Cloud SQL, Spanner) and storage (Google Cloud Storage) into a single, cohesive view inside the IDE.
A set of agent skills: relating to Google data services.
Conversational analytics: Run natural language queries to profile, search, and visualize BigQuery datasets, with the ability to generate LookML models or Streamlit dashboards.
Automated pipeline assembly: Instruct your agent to construct end-to-end data workflows. The agent programmatically builds the Apache Spark notebooks for ingestion, dbt projects for bronze → silver → gold transformations, and scheduled orchestration pipelines (like Apache Airflow and Dataflow).
Intelligent workload routing: Automatically routes data tasks to the optimal engine — SQL-native ELT operations land on BigQuery, while custom Python transformations and distributed ML training are directed to Spark.
Incident diagnosis & autonomous recovery: If a pipeline fails in production, the kit runs root-cause analyses, drafts fixes, tests them, and redeploys the jobs autonomously.

Setup & Installation

Unlike the other skills I’ve listed so far, this the DAK is a much more holistic integration with your IDE. You install the Data Agent Kit from the Extensions Marketplace in VS Code or Antigravity IDE. You can install the extension directly from the Extensions view:

What Do You See in the IDE?

After installing, you’ll see:

The Unified Data Estate Hub: A new Google Cloud Data Agent Kit icon appears in your left-hand activity bar. Clicking it opens a dedicated sidebar explorer that consolidates your BigQuery datasets, Cloud Storage buckets, Spanner/AlloyDB/Cloud SQL instances, and Dataproc notebooks. If you are not yet authenticated, a sign-in prompt is pinned to the bottom status bar to guide you.
A bunch of agent skills :

Auto-provisioned MCP tools: Rather than forcing you to manually run npx skills add to register skills one-by-one, the extension automatically provisions a suite of remote and local Model Context Protocol (MCP) servers (like datacloud_bigquery_remote or datacloud_spanner_remote) directly into Antigravity's agent harness. When you chat with the agent or query /mcp, these tools are instantly active — empowering the agent to inspect schemas, write dbt transformations, or run query-optimisation analyses on your behalf.

Wrapping Up

So, there you have it; a whistle-stop tour of my absolute favourite agent skills that are currently transforming the way I build, test, and run things.

And you’ll notice that these skills work in a number of ways:

Some are standalone and simply provide your agents with guidance.
Some include embedded scripts — such as bash or Python code — and execute these scripts when required.
Some go hand-in-hand with other tools, such as locally installed CLIs or MCP servers. This combo is especially powerful, because the tools provide all the capabilities our agents need, whilst the complementary skills advise our agents on how to use those tools effectively.

Whether you’re bootstrapping GCP resources with agents-cli, self-extending your assistant’s capabilities with find-skills, or orchestrating headless video pipelines via Remotion and Genmedia — loading the right skills on-demand is the secret to dialling your agents to 11.

So, what are you waiting for? Install a few of these, power-up your IDE, and let me know how you get on.

What Are Your Favourites?

Please, tell me what skills you use. Post in the comments. Let's crowd-source a great set of useful skills!

Before You Go

Please share this with anyone that you think will be interested. It might help them, and it really helps me!
Please interact!
Feel free to leave a comment 💬.
Follow and subscribe, so you don’t miss my content.

Useful Links and References

Skills and MCP

Tools, Frameworks and Environment

Google Agents-CLI

Dazbo Agent Skills

Dazbo Agent Skills on GitHub

Google Skills

https://github.com/google/skills

Genmedia

Miscellaneous

Resolving WSL Friction with Google Antigravity: the Agy 2.0 and Agy IDE Edition

Darren "Dazbo" Lester — Fri, 12 Jun 2026 02:42:21 +0000

Resolving Friction

Last year when the very cool Google Antigravity (Agy) was first launched, there were some teething issues when working with the Windows Subsystem for Linux (WSL) environment. These caused some friction, but they could all be solved. So I wrote a blog to consolidate the fixes. This blog turned out to be very popular, with about 40,000 of you having read it in the last six months!

Enter the New Agy 2.0 Ecosystem

In May 2026, Google dropped the new Antigravity suite. This was a major overhaul of Antigravity, and a split into these four products:

Antigravity 2.0 , which is now the dedicated agent-first “builder” environment on your desktop. Notably, it doesn’t itself include an IDE. Instead, we now interact only with the agent manager. This surface aims to usher in the era of “idea to product” using agents, without concerning ourselves over the code. Many builders who don’t come from a coding background will love this.
Antigravity IDE , which gives us the more familiar VS Code-esque coding environment, supported by the Antigravity agent harness. Here we can do agent-assisted development, and we always see the code. Coders will feel at home here.
Antigravity SDK , which gives you the harness and tools that power Antigravity, but exposed as a Python Agent SDK. By importing from google.antigravity we can programmatically leverage Antigravity’s capabilities.
Antigravity CLI , which is the next evolution of the the extremely awesome Gemini CLI. It’s still a terminal-first environment for interacting with Gemini models. But the new Antigravity CLI is built in Go, and you can tell; it feels much faster than Gemini CLI, both during startup and in general use. It leverages the same agent “harness” as Antigravity 2.0 and the IDE, and this allows for common settings and configuration across the Antigravity suite.

What Does This Mean for WSL?

Surprise: this introduces some new friction with WSL. But good news: once again, these friction areas are easily resolved!

Here I’ll list some of the problems I’ve encountered with Agy in WSL, and how to fix them.

No Way To Execute or Approve Interactive Commands

This one was causing me a lot of strife: when the agent was executing shell commands in my WSL environment, it would often:

Start running the shell command.
Show in the conversation window that it’s waiting for approval, but never actually ask for it.
Move the command to a background thread.
Never complete the command. Or alternatively, complete the command and not notice it has done so.

It’s easy to reproduce. In Agy IDE, whilst connected to WSL, I can issue a prompt like this:

“Try running some interactive shell commands”

And this is what happens:

Here’s the interesting thing: it says it’s waiting for approval , but there’s actually no prompt from Agy and no way to provide it. If you click on the first blue dot you’ll see this:

We see the interactive command. But there’s no way to interact with it! The dropdown arrow at the bottom right simply hides this line. All we can do is terminate the background command by pressing the X.

I found a LOT of posts about this on the Internet. But this one is the only one that worked for me. (My own flavour of the fix is mostly built on that thread.)

The Cause

It appears that my bash shell prompt includes funky characters that are polluting the prompt to the agent. In my case, this is almost certainly because I’m using oh-my-bash shell customisation.

When I say shell prompt, I mean the thing that looks like this…

Or this:

Furthermore, my oh-my-bash is actually configured to pick a random prompt from a list. This explains another thing that was confusing me: sometimes, my Agy agent was able to run these shell commands. But most of the time it couldn’t.

The Fix

Modify your ~/.bashrc so that it doesn’t load any funky shell prompts or other interactive prompt intelligence. Add the “Antigravity Agent fix” block in your ~/.bashrc, like this:

### TOP OF .bashrc

# Enable the subsequent settings only in interactive sessions
case $- in
  *i*) ;;
    *) return;;
esac

# Antigravity Agent fix - clean the terminal
if [[-n "$ANTIGRAVITY_AGENT"]]; then
    # Force the shell to behave as a simple pipe
    export TERM=dumb
    export DEBIAN_FRONTEND=noninteractive

    # Disable aliases that might wait for terminal polling
    unalias -a

    # Clean prompt
    export PS1='$ '
    unset PROMPT_COMMAND

    # exit early, without running the rest of .bashrc, e.g. bypassing oh-my-bash
    return
fi

# The REST of your .bashrc
# E.g.
export OSH='/home/dazbo/.oh-my-bash'

Okay, let’s restart Agy and see if it has worked…

It created a script, executed it, injected interactive responses to the script, and completed!

Woop!

Browser Agent is Broken

The browser agent is the thing that allows you to launch a browser from your chat, and then navigate. It can also take screenshots or even record a video of the session.

But… It doesn’t work in WSL out-of-the-box, of course.

I test it with a prompt like this: “Use the browser agent to navigate dazbo.co.uk”

Agy fails, and gives me a response like this.

The Fix

This is super-easy to fix!

We just need to enable mirroring mode in our WSL config!

In Windows, we just need to edit our \.wslconfig file (or create it, if it doesn’t yet exist):

notepad %userprofile%\.wslconfig

Just make sure the file has this block:

[wsl2]
networkingMode=mirrored

Then shutdown and restart WSL, from your Windows Command Prompt or Powershell:

wsl --shutdown

# Wait a few seconds
wsl

Now we restart Agy, and let’s see what happens…

How Does It Work?

By default, WSL2 uses a Network Address Translation (NAT) architecture, which essentially places your Linux environment behind a virtual router on a separate network isolated from Windows. When Agy triggers its browser agent, it spins up a browser instance on Windows and attempts to talk to it via the Chrome DevTools Protocol (CDP). In NAT mode, that connection slams straight into a networking wall because your Linux-based Agy harness can’t seamlessly see or route traffic to Windows localhost ports (like Chrome’s default debug port 9222).

Switching your networking mode to mirrored solves this. Instead of treating Linux as a detached VM on a virtual router, Windows literally mirrors its exact network interfaces directly into WSL2. This completely removes the network isolation barrier. Now, localhost means the exact same thing to both Windows and Linux, allowing Agy in WSL to hook straight into Chrome's remote debugging interface on Windows with zero port-forwarding friction, and no firewall headaches.

That’s It

Hope this has saved you some bother.

Until next time!

You Know What To Do!

Please share this with anyone who you think will be interested. It might help them, and it really helps me!
Please interact or leave a comment 💬.

Useful Links and References

Dialling Our Agents to 11: My Favourite MCP Servers

Darren "Dazbo" Lester — Mon, 08 Jun 2026 02:27:01 +0000

What This Article Is About

I’d like to tell you about a few of the MCP servers and agent skills that I use most often. I’ll tell you what they do, how I use them, and how to install them.

These make up much of my agentic environment — or agent harness — that ensures that my agentic tools do what I need them to do, in a reliable and repeatable way. Since I mostly work within the Google ecosystem, it will be no surprise to the majority of my readers that most of these (but not all) are Google-centric.

This first part will cover the MCP servers, and I’ll share my favourite agent skills in the second part.

Not Sure What MCP Servers and Skills Are?

Check out this video, where I explain MCP and skills, how they work, and how they differ.

I talk about the use cases where skills are better than MCP servers and vice versa, and I talk about the scenarios where you might want to use them together. (This is the talk I did for the Google Build with AI roadshow.)

MCP servers and skills are crucial for grounding our agents and ensuring they do what we want them to do, in a repeatable way. They make up two core components of the agent harness. If you’re new to this term, then here’s the thing to know: “If you’re not the model, you’re the harness.”

When you’re using an agent to achieve a goal, that agent calls at least one model. But every agent also needs at least some of the following: prompts, context management, state management, tools, data for grounding, orchestration and an execution environment. These are the things that make up the harness.

So, where exactly do MCP and skills fit into this scaffolding?

MCP servers let you have natural language conversations with tools, services and data. They provide a standardised open interface that gives the agent its hands and eyes — letting it safely interact with local files, run database queries, fetch documentation, execute code, browse the web, and so on.
Skills configure the on-demand knowledge for our agents. I.e. the reusable prompts, patterns, workflows, checklists, principles and rules.

Assembling a tailored set of skills and MCP servers dials your agentic development environment straight up to 11. Suddenly, your agentic editor isn’t just suggesting code; it’s actively provisioning cloud services, auditing your SEO, checking your security protocols, and maintaining your documentation.

Environment

These days I’m doing all my development work in either Google Antigravity CLI or Antigravity IDE. (By the way, Google Antigravity is also known as Agy. So I’ll be using this nickname frequently in this article.) If you want a general overview of how to set up skills and MCP servers in Agy, check out my article:

Configuring MCP Servers and Skills for Antigravity CLI and IDE

Okay, that’s it for the preamble. Let’s get into the list!

#1 — GitHub

What It Does

This MCP server acts as the bridge between your agent and your GitHub repositories. It exposes a full set of tools for managing pull requests, creating issues, committing changes, and pushing them.

It’s also particularly useful if you manage to get yourself in a git pickle! I have a bit of imposter syndrome when it comes to remembering certain git commands. Is it just me?

For example, you might say to Antigravity: “Commit all the changes in my workspace in a new branch, and push.”

In response, Agy is going to pick an appropriate name for your branch, create it, stage and commit your changes with an appropriate commit message, and push to your remote repo.

Here’s a really simple demo, where I’ve asked Agy:

“Look up all my public github repos. Return them to me directly in this chat as a markdown table, including one line description, primary technologies used, and number of stars. List them in descending stars order.”

Installation

To install it, just add this block to your MCP configuration. (In Antigravity, it will be ~/.gemini/config/mcp_config.json.) The MCP server is remote, so you don’t need to install anything locally. You will need a GitHub access token, to allow your agent to authenticate to GitHub.

"mcpServers": {
  // other MCP servers
  "remote-github": {
    "serverUrl": "https://api.githubcopilot.com/mcp/",
    "headers": {
      "Authorization": "Bearer YOUR_GITHUB_PERSONAL_ACCESS_TOKEN",
      "Content-Type": "application/json"
    }
  }
}

#2 — Google Developer Knowledge

What It Does

This is a remote server that gives your agent the power to perform semantic search of the official Google developer documentation corpus. It covers everything from Android, Go, Flutter, Firebase, ADK, and Gemini APIs, to Google Cloud and TensorFlow.

With this MCP server, your agent knows:

The latest Google services and APIs
What’s deprecated and should be avoided
Best practices for architecture, coding standards, and implementation
How to troubleshoot common issues related to Google services

In short… If you do any work with Google services, you want this MCP to be running!

Without this MCP, you’ll often get outdated information about Google services and APIs, or code generated with hallucinations that don’t actually work.

Let’s give it a try…

“Using Google Developer Knowledge MCP, tell me about GKE in-place pod resize”

Our agent quickly comes back with an accurate and up-to-date response:

Note: it’s not really necessary to tell Agy which MCP server to use to do a task. But sometimes, if you have many servers with complementary capabilities, it can save your agent a bit of confusion if you tell it how you want it to fetch your information.

Installation

To configure this, you’ll need to authenticate (which can be with ADC or an API key), and then add an entry like this to your MCP config:

"mcpServers": {
  // other MCP servers
  "google-developer-knowledge": {
    "command": "npx",
    "args": [
      "-y",
      "mcp-remote",
      "https://developerknowledge.googleapis.com/mcp",
      "--header",
      "X-Goog-Api-Key: YOUR_API_KEY"
    ]
  }
}

#3 — AVTool

What It Does

I love this one! It’s basically a wrapper around the free command line tool, ffmpeg. With it you can manipulate video, images and audio with natural language commands. With prompts like…

“Extract the audio from the video file video123.mp4 as mp3”
“Trim the first 5 seconds off the video”
“Convert all the gif files >5MB in this folder to jpg”
“Double the playback speed of this video”
“Optimise this video so it’s less than 10MB”

Let’s do a quick demo… I’ve put an episode of an old 1980s Dungeons and Dragons cartoon into the workspace directory. My goal is to extract just the first 10 seconds of the episode and save it as a separate video file. The original video has quite a long title, but I don’t have to be specific with Agy:

“Take the first 10 seconds of the dungeons and dragons video, and save it as a new video.”

The clip generation was super fast. Agy, via the MCP server, ran this command, but we don’t need to know or care!

ffmpeg -y -i "dungeons & dragons -01- the night of no tomorrow (mummra1983).avi" \
  -ss 00:00:00 -t 10 -c:v libx264 \
  -c:a aac media-output/dungeons_and_dragons_10s.mp4

Insanely cool, right?

Installation

Unlike the previous MCP servers I’ve described, this one requires that we set up some prerequisites...

Of course, we need to have ffmpeg installed locally.
The tool can optionally write to a GCS bucket. For this, make sure you’ve specified a Google Cloud project and bucket you have write access to. (Authentication is done using ADC.)
Install the local AVTool MCP server. See the instructions here.

Finally, add your MCP configuration as usual:

"mcpServers": {
  // other MCP servers
  "avtool": {
    "command": "mcp-avtool-go",
    "env": {
      "MCP_SERVER_REQUEST_TIMEOUT": "55000",
      "PROJECT_ID": "your-google-project",
      "GENMEDIA_BUCKET": "your-gcs-bucket",
      "LOCATION": "europe-west1"
    }
  }
}

#4 — NotebookLM

What It Does

Everyone knows I love NotebookLM! A quick recap, if you don’t know what it is…

NotebookLM is a personalised AI research assistant built on top of Google’s multimodal Gemini models. It’s designed to help you understand, synthesise, and present complex information that’s scattered across all sorts of different formats. Some key tenets:

The information it synthesises is grounded strictly on only the sources you provide.
It supports various formats of data, including videos, audio, Google Docs and Sheets, PDFs, images, web pages, and more.
It can generate various types of output for you, including detailed reports, mind maps, audio podcasts, presentations, and even videos!

I’ve written a dedicated blog about using MCP to integrate with NotebookLM previously:

Integrate NotebookLM with Gemini CLI, Google Antigravity or Other Agents with MCP

That blog has a number of use cases demonstrated, so I won’t repeat them here.

Installation

This is another MCP server that runs locally, so there’s a few things you need to setup:

Have uv installed. (Like many locally running MCP servers require.)
Install the local notebooklm-mcp-cli: uv tool install notebook-mcp-cli

Now you can go ahead and add your MCP server entry:

"mcpServers": {
  // other MCP servers
  "notebooklm-mcp": {
    "command": "uvx",
    "args": [
      "--from",
      "notebooklm-mcp-cli",
      "--with",
      "fakeredis<2.20.0",
      "notebooklm-mcp"
    ]
  }
}

#5 — ADK-Docs

What It Does

This is very useful when developing using Google Agent Development Kit (ADK). This particular MCP Server provides your agent with specific grounding documentation about ADK itself. These days, this one might be a little redundant, given that the Google Developer Knowledge MCP includes ADK documentation in its corpus. But I still find that having this MCP installed provides very targeted information when I’m building agents with ADK.

It works by running a local mcpdoc MCP server on your machine and pointing that server to the official ADK documentation. If you want to know a bit more about how this works, you might find this interesting:

Give Your AI Agents Deep Understanding With LLMS.txt

Installation

You do need to have uv pre-installed, but otherwise, the only configuration you need is this:

"mcpServers": {
  // other MCP servers
  "adk-docs-mcp": {
    "command": "uvx",
    "args": [
      "--from",
      "mcpdoc",
      "mcpdoc",
      "--urls",
      "AgentDevelopmentKit:https://adk.dev/llms.txt",
      "--transport",
      "stdio"
    ]
  }
}

#6 — Stitch

What It Does

Google Stitch is very cool! It’s all about designing the UI.

This is its tagline:

You describe an idea in natural language, and Stitch creates the wireframe and the interactive mockups of what your application will look like. You might give Stitch a prompt like:

“A landing page for a movie club application. Minimalist dark-mode aesthetic with neon purple and green accents. Top bar navigation, with main window widgets for calendar and movie management.”

Let’s give that prompt a go!

Initially, as Stitch is building the design, we see this:

And a minute later, we have this:

How cool is that?

From here, you can annotate, modify and iterate.

As you go, Stitch maintains your UI design in a standardised DESIGN.md document that is both human and agent-readable. And you can export everything created by Stitch — the DESIGN.md, the HTML, and the images — in various formats, including Figma, as a zip file, or directly into AI Studio.

If I download the zip, it looks like this:

Now I can add these files to my development project. If I’m vibing the frontend, I could drop in these files and then ask Agy to (say) create a React web application that matches these files.

But with the Stitch MCP server, it’s even easier! It essentially opens a two-way conversation about your agentic development environment (like the Agy IDE) and Stitch. So now you could say, from Agy:

“Using Stitch MCP, create a landing page for a movie club application. Minimalist dark-mode aesthetic with neon purple and green accents. Top bar navigation, with main window widgets for calendar and movie management. Let me give it the once over before we build the actual web UI application.”

This is what we then see in Agy:

Then, as with any MCP server, Agy asks if it has permission to execute the required tool:

Once Agy is finished, we see this:

Of course, we can always go into the Stitch UI and take a look at what was created.

To conclude, with the Stitch MCP server we can:

Create the design using a natural language prompt
Iterate on the design
Then proceed directly to implementation

And all without ever leaving our IDE’s chat interface. Also, we never have to export any files from Stitch and dump them into our workspace. We have true two-way conversation between our Agy agent and Stitch.

Installation

Stitch uses a remote MCP server, so we just need to download an API key from Stitch, and then add this to our MCP config:

"mcpServers": {
  // other MCP servers
  "StitchMCP": {
    "command": "npx",
    "args": [
      "-y",
      "mcp-remote",
      "https://stitch.googleapis.com/mcp",
      "--header",
      "X-Goog-Api-Key: YOUR_API_KEY"
    ]
  }
}

#7 — Google Cloud Remote MCP Servers, e.g. Firestore, BigQuery, etc

What It Does

These have been around for a little while now, but Google made them generally available (GA) in April 2026.

Basically, they are a set of remote MCP servers, hosted and fully-managed by Google. They align to many of Google’s services and products, like BigQuery, Firestore, Cloud SQL, Cloud Storage, Cloud Run, GKE, Maps, Cloud Monitoring, Cloud Logging, and so on. They allow us to have natural language conversations with these Google services.

And because they are fully-managed, we don’t have to install anything and we never have to maintain them.

Typically, I don’t have these enabled all the time. But if I’m working with a particular Google Cloud service for a given project, I’ll typically configure the required MCP server for as long as I need it.

Installation

We do need to do a couple of things in Google Cloud first. This includes:

Ensuring we have a Google project
Enabling the API for the service we want to talk to, e.g. bigquery.googleapis.com
Enabling the required MCP server
Granting your identity the roles/mcp.toolUser role
Granting your identity the correct IAM role to use the underlying service that is provided via MCP

Then we can add our MCP configuration:

"mcpServers": {
  // other MCP servers
  "FirestoreMCP": {
    "serverUrl": "https://firestore.googleapis.com/mcp",
    "authProviderType": "google_credentials",
    "oauth": {
      "scopes": [
        "https://www.googleapis.com/auth/cloud-platform"
      ]
    },
    "headers": {
      "X-Goog-User-Project": "YOUR_PROJECT_ID"
    }
  }
}

If you want to know more about these Google MCP servers, check out Romin Irani’s Google MCP Server Tutorial Series. He goes into a lot of depth, and provides a bunch of use cases.

#8 — gcloud

What It Does

This empowers our agent to know how to use the Google gcloud CLI. So we can issue natural language prompts like:

“Find all log entries with severity ERROR in the last 15 minutes”
“Deploy my local container to Cloud Run and split the traffic 50/50”

This saves a lot of time in trying to determine the exact gcloud syntax to do a specific thing.

Installation

This is a remote MCP server, and setting it up is as simple as adding this config:

"mcpServers": {
  // other MCP servers  
  "gcloud": {
    "command": "npx",
    "args": [
      "-y",
      "@google-cloud/gcloud-mcp"
    ]
  },
}

It operates with the authority of your ADC credentials.

Wrap-Up

Having a robust agent harness transforms the effectiveness of your agent. Having a good set of MCP servers is part of this harness. Give these a try in your own development environment, whether it’s Antigravity or other. And let me know: which are your favourites? What other MCP servers would you recommend?

Stay tuned. The Agent Skills rundown will arrive soon.

Before You Go

Please share this with anyone that you think will be interested. It might help them, and it really helps me!
Please give me 50 claps! (Just hold down the clap button.)
Feel free to leave a comment 💬.
Follow and subscribe, so you don’t miss my content.

Useful Links and References

Skills and MCP Servers Explained (Build with AI, Prishtina)

Configuring MCP Servers and Skills for Antigravity CLI and IDE

Darren "Dazbo" Lester — Sun, 24 May 2026 10:36:37 +0000

Introduction

We had a few big announcements from Google I/O 2026 in the AI space. One was the announcement of Gemini Flash 3.5, which went straight to general availability (GA). Another was the launch of the Google Antigravity (aka “Agy”) ecosystem.

The Agy suite supports and enables Gemini 3.5 from day 1 and is made up of a number of products:

Antigravity 2.0 , which is now the dedicated agent-first “builder” environment on your desktop. Notably, it doesn’t itself include an IDE. Instead, we now interact only with the agent manager. This surface aims to usher in the era of idea to product using agents, without concerning ourselves over the code.
Antigravity IDE , which gives us the more familiar VS Code-esque coding environment, supported by the Antigravity agent harness.
Antigravity SDK , which gives you the harness and tools that power Antigravity, but exposed as a Python Agent SDK. By importing from google.antigravity we can programmatically leverage Antigravity’s capabilities.
Antigravity CLI , which — somewhat controversially — replaces the hugely popular and open-source Gemini CLI. It’s still a terminal-first environment for interacting with Gemini models. But the new Antigravity CLI is built in Go, and you can tell; it feels much faster than Gemini CLI, both during startup and in general use. It leverages the same agent “harness” as Antigravity 2.0 and the IDE, and this allows for common settings and configuration across the Antigravity suite.

I can understand Google’s rationale for bringing Gemini CLI into the Antigravity suite. Previously these products were developed independently and in parallel. As a result they had different standards and approaches for configuration (such as MCP servers), and where to put things… like skills. This creates a certain amount of friction for users. Now, in theory, we only need to configure in one place.

There’s already a bunch of articles in the Google Cloud Publication describing how to get started with the Antigravity suite.

Here I’m going to briefly share my experience in configuring MCP servers and skills.

This is literally day 1 of me experimenting with these things in Agy, so there’s a lot I need to discover. And I expect we’ll continue to see a lot of bug fixes across the Agy suite too. But I wanted to share this with you ASAP, as I’ve been getting a lot of folks asking me questions about this. I hope it’s useful for you.

Global Configuration

As before, we have a .gemini folder in our home directory. But now it looks like this:

.gemini
├── antigravity/
├── config/
│   ├── plugins/ # Global / shared plugins
│   ├── projects/ # Approved project folders
│   └── mcp_config.json # Global / shared MCP config
├── antigravity-cli/
│   ├── mcp/ # Dynamically generated from shared MCP config
│   └── settings.json # CLI settings
├── antigravity-ide/
│   ├── mcp/ # Dynamically generated from shared MCP config
│   ├── plugins/ # Symlinked from global config
│   └── installation_id
├── skills/ # Global / shared skills
│   └── {skill_name}/
│       └── SKILL.md
└── GEMINI.md

Some things to note about this:

At the time of writing, the official Antigravity documentation says that to configure skills “globally” , you need to put them here: ~/.gemini/antigravity/skills/<skill-folder>/

But my experience is that this is incorrect. Antigravity tools do not pick up skills placed in this location. Instead, you should put your skills folder at the top of your .gemini folder. We can confirm this by running the /skills command from inside Agy CLI:

You can see that “global” skills — meaning those available to all workspaces when running Agy CLI only — should go in ~/.gemini/antigravity-cli/skills, whereas “shared” skills — meaning those available to *all workspaces running any Antigravity tools * — should go in ~/.gemini/skills.
If we want to share MCP server configurations across Antigravity tools, you need to create mcp_config.json file and place it in the new ~/.gemini/config folder. (This is where “shared” extensions — now called “plugins” go also.)

MCP Configuration

Here’s what my new ~/.gemini/config/mcp_config.json currently looks like:

{
  "mcpServers": {
    "lyria": {
      "command": "mcp-lyria-go",
      "env": {
        "MCP_SERVER_REQUEST_TIMEOUT": "55000",
        "GENMEDIA_BUCKET": "my-bucket-name",
        "PROJECT_ID": "my-google-project",
        "LOCATION": "europe-west1"
      },
      "disabled": true
    },
    "avtool": {
      "command": "mcp-avtool-go",
      "env": {
        "MCP_SERVER_REQUEST_TIMEOUT": "55000",
        "PROJECT_ID": "my-google-project",
        "GENMEDIA_BUCKET": "my-bucket-name",
        "LOCATION": "europe-west1"
      }
    },
    "chirp3-hd": {
      "command": "mcp-chirp3-go",
      "env": {
        "MCP_SERVER_REQUEST_TIMEOUT": "55000",
        "GENMEDIA_BUCKET": "my-bucket-name",
        "PROJECT_ID": "my-google-project"
      }
    },
    "gcloud": {
      "command": "npx",
      "args": [
        "-y",
        "@google-cloud/gcloud-mcp"
      ]
    },
    "notebooklm-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "notebooklm-mcp-cli",
        "--with",
        "fakeredis<2.20.0",
        "notebooklm-mcp"
      ],
      "disabled": true
    },
    "StitchMCP": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://stitch.googleapis.com/mcp",
        "--header",
        "X-Goog-Api-Key: <my-stitch-api-key>"
      ],
      "env": {}
    },
    "FirestoreMCP": {
      "serverUrl": "https://firestore.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": [
          "https://www.googleapis.com/auth/cloud-platform"
        ]
      },
      "headers": {
        "X-Goog-User-Project": "dazbo-portfolio"
      },
      "disabled": true
    },
    "remote-github": {
      "serverUrl": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer <my-github-api-key>",
        "Content-Type": "application/json"
      }
    },
    "google-developer-knowledge": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://developerknowledge.googleapis.com/mcp",
        "--header",
        "X-Goog-Api-Key: <my-google-developer-knowledge-api-key>"
      ],
      "env": {}
    },
    "google-cloud-resource-manager": {
      "serverUrl": "https://cloudresourcemanager.googleapis.com/mcp",
      "authProviderType": "google_credentials"
    }
  }
}

A few notes about this MCP JSON file…

You need to use serverUrl, not the older httpUrl
The “timeout” parameter is no longer supported at the top level of each MCP server.
Inline comments are not supported.

Let’s see if this works…

Let’s test one of these.

I say to Agy CLI: “List my public GitHub repos. Present them in a markdown table, along with their summaries, primary technologies, and number of stars. List in desc stars order.”

And Agy CL comes back with:

So that worked fine.

But what about in Agy IDE? Let’s just ask the agent, “What MCP servers do we have?”

So you can see that Agy IDE has picked up the same MCP configuration. Hurrah!

I did discover one issue… In my old Gemini CLI MCP server configurations, I was able to pass in environment variables, e.g. for API keys. In Agy CLI / IDE, this isn’t working for me and I’ve had to hard-code these keys into my mcp_config.json file. I hope this will get fixed soon.

Skills Configuration

I started by downloading and installing a number of skills in the usual way; i.e. via npx, like this:

# Skills related
npx skills add https://github.com/vercel-labs/skills -y -g --skill find-skills

# My skills - e.g. project-documentation
npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g

# Agentic dev, Gemini, ADK
npx skills add https://github.com/google/skills -y -g
npx skills add https://github.com/GoogleCloudPlatform/vertex-ai-creative-studio/experiments/mcp-genmedia/skills -y -g

# Research, content, documentation, and marketing
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill deep-research
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill fact-checker
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill strategy-advisor
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill technical-writer
npx skills add https://github.com/wshobson/agents -y -g --skill architecture-decision-records
npx skills add https://github.com/coreyhaines31/marketingskills -y -g --skill seo-audit

# UI and frontend
npx skills add https://github.com/vercel-labs/agent-skills -y -g --skill vercel-react-best-practices
npx skills add https://github.com/remotion-dev/skills -y -g --skill remotion-best-practices

These commands install skills to your ~/.agents/skills folder. But I want them to be in ~/.gemini/skills. As mentioned previously, this location is picked up by all Agy products. So, go ahead and move the skills you’ve installed. Or you can run a script like this to do it for you:

for d in ~/.agents/skills/*/; \
do [ -d "$d" ] && rm -rf "$HOME/.gemini/skills/$(basename "$d")"; \
done && mv ~/.agents/skills/* ~/.gemini/skills/

By the way, I’ve actually created a skill that does this for me. I.e. it helps with installing any skill, and then relocating it to the appropriate location for Antigravity. It’s called deploy-skills-in-antigravity and you can check it out here. After installing it, I can say to Agy:

“please install the skill seo-audit from https://github.com/coreyhaines31/marketingskills”

Agy then activates my skill and uses the correct commands to install and move the newly installed SEO skill.

(If you like this skill, please add a star to my repo!)

When we start Agy CLI, these skills are all available. Let’s check in Agy IDE too. I ask Agy IDE: “What skills do we have installed?”

So we can see the skills are detected in Agy IDE, as required.

If I ask the Agy agent to “Perform a core documentation review,” we can see that it uses the required skills automatically:

(If you’re interested in this documentation review skill, then you can obtain it here. Please add a star to the repo, if you find it useful!)

Wrap-Up

So, where does that leave us?

Migrating from the old Gemini CLI to the new Antigravity ecosystem does require a bit of mental rewiring when it comes to folder structures. But having a single, unified source of truth for your MCP servers and skills is a leap forward. No more duplicating configurations or wondering why a custom skill works in your terminal but fails in your IDE. (Hopefully!)

Is it perfect? Not yet. We still have some day-one paper cuts — like that frustrating environment variable bug in the global MCP configuration that forces us to hardcode API keys for now. But given the sheer startup speed of the new Go-based CLI and the potential of the shared agent harness, the foundation is incredibly solid.

Hopefully, this guide saves you some time scratching your head over directory discrepancies. Let me know if you run into any other teething issues!

Now, if you’ll excuse me, I think it’s time to put on a Hawaiian shirt, mix up a piña colada, and go enjoy a bit of sunshine.

Until next time, happy building!

Before You Go

Please share this with anyone that you think will be interested. It might help them, and it really helps me!
Please give me 50 claps! (Just hold down the clap button.)
Feel free to leave a comment 💬.
Follow and subscribe, so you don’t miss my content.

Useful Links and References

Upgrading Your Microsoft Surface Laptop Hard Disk — Easier Than You Think!

Darren "Dazbo" Lester — Sat, 23 May 2026 10:59:05 +0000

Overview

Older generations of Microsoft Surface devices were not upgradeable. You made your choice and you were stuck with the consequences. But the Microsoft Surface Laptop 7 is surprisingly easy to upgrade.

Here I’ll walk you through:

What types of upgrade SSDs are compatible
How to create your recovery image
How to open up your case, including the screwdriver you’ll need
How to use the recovery image, including some common gotchas
A few handy links of bits and pieces you might want to buy

Why Would You Want to Do This?

I love the Microsoft Surface Laptop range. I currently have a Surface Laptop 7 and I think it’s a great bit of kit. (By the way, you should check out my blog: Should You Switch to a Windows ARM Laptop? My Experience of the Surface Laptop 7.)

But these are not cheap. They’re premium devices with premium prices. And when you buy one, you need to think carefully about the spec you’re getting. When the Surface Laptop 7 launched, here’s what the line-up looked like, and how much each model would set you back:

Microsoft Surface Laptop 7 - Launch Configurations and Prices - Google Drive

docs.google.com

But what do you do if you’ve already bought it, and now your disk is full? My laptop has a 512GB and it’s full. No amount of housekeeping is going to save me!

And what if you wanted to put in a 2TB disk? There’s no option for that.

Upgrade Walkthrough

Ordering Parts

First you’re going to need your replacement SSD. The internal drive on the Surface Laptop 7 is a M.2 SSD. But it’s not the standard 80mm card. For this laptop you need the shorter 30mm format, called “ 2230 ”. Then pick your size. I wanted to upgrade my 512GB to 1TB.

There are a few popular choices for this SSD upgrade, including the Corsair MP600 Micro, the WD Black SN770M, and the Sabrent Rocket 2230. I went with the Corsair and bought one of these on Amazon:

This model cost me £145.

Next, you’re going to need an appropriate screwdriver to take the laptop apart. After a bit of research I determined that the screws used are “5IP”, aka Torx Plus 5. OMG, I fell down a rabbit hole of screws used in devices. Here is an excellent article that explains what Torx and Torx Plus screws are, and why they exist.

But it turns out that getting a Torx Plus screwdriver is difficult; certainly here in the UK. But here’s the good news: a standard Torx T5 screwdriver does the job fine. You could just buy such a screwdriver on its own, but I ended up buying this very cool JOREST precision screwdriver set from Amazon for a tenner. It includes the T5 bit that we need.

The other great thing about this set is that the screwdriver bits are magnetic, and so too is the case. This is very handy, because the screws you’re working with are TINY! They are easy to lose. Being able to lift them out with the screwdriver and then drop them into a magnetised case is a life-saver!

Create Your USB Recovery Drive

Time required: approx 30 mins. (Most of it spent downloading and waiting for the copy.)

You’re going to need a bootable USB recovery drive to perform a clean install of Windows 11 on your Surface Laptop after you’ve installed your shiny new SSD.

This Microsoft guide explains what to do. There are some things to note:

First, we download the Surface Laptop 7 factory image from this page. You’ll need to choose “Surface Laptop” from the dropdown, and enter your serial number.

I downloaded the newer “ Windows 11 Home Version 25H2 ”. It turns out that this creates a minor problem, but easy to solve. I tell you more in a minute.

Next we need to create a USB recovery drive. First we create the recovery drive from Windows, and then we’ll transfer the factory image files to it. The documentation is ambiguous about the size of flash drive you can use. The MS guide says “32GB is large enough but you may be able to use a smaller size”. And I’ve found other blogs and advice online that says it won’t work if your drive is bigger than 32GB. This is incorrect; you can go larger. I used a 128GB and it was fine. Basically, the “Create a recovery drive” option in Windows will format your USB drive with a 32GB FAT32 partition. (By the way, you can run this step from any machine running Windows 11. It doesn’t have to be done on your Surface Laptop.)
Now, unzip the recovery image you downloaded previously, and then copy all folders and files directly to your recovery drive. The file transfer took me about 10 minutes. (You should definitely unzip first. It’s much faster if you do this, rather than just opening the zip and then copying over all the contents.) When prompted, select “Replace the files in the destination.”

Swap the SSD

Time required: 5 minutes.

First we need to take off the back plate. Ensure the device is powered off and disconnected from power. Then remove the four black rubber stoppers from the laptop to expose the screws we need to remove. The screwdriver kit I mentioned earlier comes with a handy tool that’s great for removing these stoppers.

Now we need to remove the screws themselves. This is what a Torx Plus 5 screw looks like, up close and personal!

We can go ahead and use our Torx T5 screwdriver bit. Be careful. Since this isn’t the perfect fitting screwdriver, you don’t want to damage the screw heads.

One all four screws are removed, we just need to remove the back plate. Again, we can use the plastic tool from our screwdriver set to do this. It comes off incredibly easy.

And now we can see the SSD:

You need to unscrew it with the same Torx T5 screwdriver. And unpeel the tape that is holding it in place. Then remove, and insert your new SSD. Screw it down and put the tape back in place.

Now go ahead and reattach the back plate. When you’re putting the screws back in, don’t over-tighten. Again, we want to be careful not to damage the screw heads.

Booting From the Recovery Drive

Insert the recovery drive into the USB port, and attach power to the laptop. Then go ahead and start the device.

After a few seconds, you might see the error “Couldn’t find a bootable operating system. Check the Boot configuration to try to fix this.”

Eek! We don’t want to see that. But panic not! The issue here is the laptop is set to use Secure Boot in the UEFI, but the Windows 11 factory recovery image is signed with a newer certificate that isn’t recognised by the device!

This is easy to fix. When you press “Ok” on the error, you’ll see the UEFI settings. From here select “Security”, then under “Secure Boot” select “Change configuration”. Now select disable secure boot. (Don’t worry; we’ll revert this later.)

Now your laptop will restart and it should detect your recovery drive. By the way, you’ll see a big red banner with an unlocked padlock as it boots. This is to remind you that Secure Boot is disabled.

You’ll now be prompted how you want to recover. Select “Just remove my files”, and the recovery process will begin. At this point, you’re into a fairly standard Windows install flow.

Re-Enable Secure Boot

Once Windows is installed, we have no more use for the USB recovery drive, and we can re-enable Secure Boot. To do this:

Shutdown the laptop.
Press and hold the volume-up button and then press the power button.
Once the MS logo appears, you can release the volume-up button.
The UEFI screen will appear and you can re-enable Secure Boot in the Security menu.

Wrap-Up

And there you have it! For around £150 and less than an hour of actual desk time, my Surface Laptop 7 has gone from a cramped 512GB base model to a spacious 1TB powerhouse — saving me a massive chunk of cash compared to buying a higher-tier spec directly from Microsoft.

The ability to easily upgrade the internals using a M.2 2230 slot is a massive win for repairability and longevity in the thin-and-light laptop space, and Microsoft deserves real credit for making this generation so incredibly accessible to work on. If you’ve been sitting on the fence wondering if you should pull the trigger on upgrading your own storage, stop hesitating. Grab yourself a solid 2230 drive, a decent precision bit set, and go for it!

You Know What To Do!

Please share this with anyone that you think will be interested. It might help them, and it really helps me!
Please give me 50 claps! (Just hold down the clap button.)
Feel free to leave a comment 💬.
Follow and subscribe, so you don’t miss my content.

DEV Community: Darren "Dazbo" Lester

Meet the Antigravity Extension: Gemini Code Assist on Steroids, in Whatever IDE You Love

The Worry

Until Now

Install the Extension

Take It For a Spin

Models

The Plugins Created Some Skills Duplication

A Nice View of Token Usage

Things Not Working

Browser Subagent

Antigravity In-Line Complete and Tab Features

What Does This Mean for Agy IDE?

Wrap-Up

Before You Go

References and Useful Links

Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent

Introduction

Skills Context (It's a Sort of Pun...)

Overview of Progressive Disclosure

Level 1: Metadata (Frontmatter)

Level 2: Instructions Loading (On-Demand)

Level 3: Resources and Code (As Needed)

How This Helps

But Can You Have Too Much of a Good Thing?

What's the Problem?

Confusion-Nation

The Empirical Evidence: Shortlist Depth and Selection Accuracy

Why Do I Have So Many Skills?

Next Question: Do I Need Them All?

What Else Did I Discover?

Clarifying Skill States

Excluding Skills

Irony and Guitars: I Made a Skill!

Outcomes of Optimising

Summary & Conclusion

Before You Go

References and Useful Links

Standards, Hubs & Agent Platforms

Related Dazbo Articles & Repositories

Key Agent Skills Repositories

Academic Research & Benchmarks

Finally — Hard Caps to Limit Your Google Cloud Spend

TL;DR

What’s the Problem?

So I Built My Own Killswitch

Google Introduced Cloud Spend Caps!

Setting Up a Spend Cap

Trying It Out

How to Lift the Cap?

How Does This Differ From Spend Caps in AI Studio?

The Most Frequently Asked Question…

Spend Cap Limitations?

Wrapping Up

Before You Go

Useful Links and References

Building a Multi-Agent FinOps Solution with Google ADK, Levering Tools, MCP and Google-Managed Assistants

Welcome Back!

Series Orientation

Deciding on Our Agents

Agent Directory Structure

The Specialised Agents & Their Tools

1. FinOpsCoordinator (Root Agent)

Quick Aside: ADK Callbacks vs App Plugins

2. BillingExplorer (Spend Aggregation & Dashboards)

3. InfrastructureAuditor (Waste & Zombie Resource Auditing)

4. CloudAdvisor (Live Guidance Proxy)

5. KnowledgeAssistant (GCP Architecture Grounding)

6. RootCauseAnalyst (Spike & Drift Correlation)

Multi-Agent Orchestration Patterns

Testing with ADK UI Tools

Performance Optimisation Lessons Learned

Partition Pruning & Predicate Pushdown

Deterministic Python Precomputation & Subagent Tool Stripping

Test-Driven Development & Unit Testing

Building the FastAPI Backend-for-Frontend (BFF)

What is a BFF and Why Do We Need It?

What is FastAPI and Why Have We Used It?

Defining the FastAPI App

Streaming Agent Events over SSE (/api/chat/stream)

1. `FinOpsCoordinator` (Root Agent)

2. `BillingExplorer` (Spend Aggregation & Dashboards)

3. `InfrastructureAuditor` (Waste & Zombie Resource Auditing)

4. `CloudAdvisor` (Live Guidance Proxy)

5. `KnowledgeAssistant` (GCP Architecture Grounding)

6. `RootCauseAnalyst` (Spike & Drift Correlation)

Streaming Agent Events over SSE (`/api/chat/stream`)

BFF Rate Limiting (`slowapi`)

Performance — Native Composite Actions with `uv`

`GEMINI.md` - Context for Your Coding Agent

Bonus #3: Automating Setup with `direnv` and `.envrc`