Forem: Google Developer Experts

My Incredible Google Cloud Next 26 Experience as a GDE

Darren "Dazbo" Lester — Tue, 28 Apr 2026 13:40:53 +0000

Hello friends! I landed back in the UK this evening, after spending the last few days in Vegas for Google Cloud Next '26. This was my 4th in-person Next event, and my second time as a speaker.

Those that follow my work on other platforms (because I haven't been on dev.to for long) know that I've been writing post-Google Next blogs for a few years now. I tend to report on the key updates, what I think of them, how they might impact the teams I'm working with, and share a bit about my experience.

This time, I'm going to strip it back to the experience, for a couple of reasons:

After Next 26, loads of people are already writing blogs with keynote summaries. And they're all so quick! There's no value in me adding another blog with the same content.
This was my first time attending and presenting as a Google Developer Expert. And this made the experience very different to previous visits. It's been an amazing experience, and I'd like to share some of it with you. (Where else am I gonna share all these cool photos?)

So, grab your coffee and your cat (or is that just a me thing?) and let's go!

What is Google Cloud Next?
- Next 26 Was the Biggest Event That Week, Right?
What's This Google Developer Expert Thing?
- And One Perk of Being a GDE? Going to Next, Baby!
Corporate Note
Sunday: Flying Out
Monday
- At the Luxor
- A Sneaky Visit to the Pool
- GDE Happy Hour
Tuesday: GDE Summit, Baby!
Wednesday
- Breakfast with Jack
- The Opening Keynote
- The GDE and Certified Lounge
- Partner All-Stars Event
Thursday
- Breakfast with Richard
- The Developer Keynote
- Puppies!
- Recording Session in the GDE Studio Pod
- Weezer and Benson
Friday
- Morning Panic
- My Talk
- Poker
- Going Home
Final Reflections
Links

What is Google Cloud Next?

For those who haven't experienced it, Google Cloud Next is the annual flagship event for all things Google Cloud and Google AI. It’s a massive three-day (or for some of us, four-day) takeover of the Las Vegas Strip, bringing together over 30,000 developers, IT leaders, and cloud enthusiasts. It's where Google drops its biggest product announcements, deep-dives into new technologies, products and capabilities, and generally sets the pace for the cloud industry for the coming year.

Some of it can be watched virtually, with the Digital Pass. But most of the session content is only available to those who attend in person.

Attendees occupy all of the hotels along the strip. But the conference itself takes place in the Mandalay Bay Resort and Convention Center, which is HUGE.

Next 26 Was the Biggest Event That Week, Right?

Maybe not! When I arrived on Sunday night, Wrestlemania 42 was underway. Apparently, attendance for Wrestlemania over two nights was nearly 110,000!

What's This Google Developer Expert Thing?

I'm so glad you asked. The GDE program is an invite-only program for individuals who have proven themselves to be both experts, but also evangelists of the Google technology ecosystem. There are only about 1200 GDEs in the world, from over 90 countries. That's about 1 GDE for every 500 Google professionally certified individuals!

The evangelisation part is important. It's not sufficient to be a Google technology expert. You also need a proven (and ongoing) track-record of informing, educating and advising in the public Google ecosystem. This evangelising must extend beyond the scope of an individual employer. And Google does actually count the stats and verify your influence. 🫨

And One Perk of Being a GDE? Going to Next, Baby!

That's right. Google invites their GDEs to attend Next. And they also offer a limited number of speaker slots to GDEs. This year there were around 20 such speaker slots, and my talk proposal was one of the lucky few to be accepted. Woop! More on that later.

Also, for the avoidance of any doubt: there are many perks! But it requires a lot of continuous work. No free lunches here! You put in the work, and good things follow.

Corporate Note

I work for EPAM, and EPAM are a proud Google Cloud partner, and a sponsor of Next 26.

EPAM had a booth on the Expo floor, right in the middle of the action. And my fellow EPAMers presented a number of talks on the cool things they've been building with our clients. You can read about some of these things here.

Oh, just one tiny thing. Announced during Next: EPAM won Google Cloud Partner of the Year for the 4th year in a row.

Just sayin'.

But this is a personal blog, not a corporate one. And with that in mind, I won't say much more about EPAM here. You know, these are my personal views, yadda, yadda!

Sunday: Flying Out

I'm flying out from London, UK. Take-off was around 1730 in the sun. We were in the air for about 10 hours. Did some work. Landed in Vegas a little after 20:00. Sun is just setting. This is a weird experience, leaving me with undeniable jetlag which didn't shift for the whole week!

This is Moulin. He's an excellent travelling companion. Very supportive (especially of my neck), but not too chatty.

Monday

At the Luxor

I was staying the iconic Luxor hotel. It's the one that looks like a pyramid:

Staying in this hotel is trippy. It's a hollow pyramid, and as you're walking along corridors, the strange angles induce a weird sense of vertigo.

Also, the elevators - sorry, inclinators - travel diagonally up and down the sides of the pyramid! I was in three separate inclinator journeys where some hotel newbie would say "What's wrong with this elevator?"

And I'd explain the situation, and let them know they're not in immediate peril!

But it turns out I was in immediate peril. When I got to my room, THERE WAS NO COFFEE. I'm in tech. I need coffee. Fortunately, there's a Starbucks downstairs. They're the real winners here.

The Luxor is located next door to the Mandalay. Here's my view of the Mandalay from my room:

And you can go directly from one to the other by walking through the casinos. Actually, this is pretty much a standard rule in Vegas. You can get EVERYWHERE by going through the casinos. It's possible to go a long time without seeing daylight.

A Sneaky Visit to the Pool

I decided to try and get an hour of sun before the shizzle gets rizzle. Whilst scouting out the pool, I spotted my first fellow GDE. Like every GDE I met in Vegas, I'd only previously met John Capobianco virtually. But even as a distant stranger, this guy is unmistakeable. Pleasure to meet you John! I failed to grab a selfie with John at this point, but we were destined to meet many times.

By the way, this is me at the pool. I know what you're thinking: "Wow, those are hunky legs. Are you part of Wrestlemania?"

GDE Happy Hour

1700 was the start of the Global GDE Happy Hour. And I'm super excited to meet folk. The room was packed full of GDEs and Googlers, but I was feeling a little intimidated. Clearly a lot of people knew each other, and I was feeling a bit like a 5th wheel.

But I was rescued nearly immediately. At this point, two Googlers turned up who are my friends, and who I've been looking forward to meeting for ages: Jack Wotherspoon and Luke Schlangen. They immediately started introducing me to other people, and I started to feel at home. (Side note: Luke knows EVERYONE.)

From left to right: me, @jackwoth, Andrew Brogdon, @lukeschlangen, Bryce Howitson, Martin Omander, Emma Twerksy, and... John Capobianco! (Two Dev Keynote speakers in one photo!)

By the way, Jack and Luke: I want you to know how much I appreciate you guys. In general, but also for hanging out with me that evening.

Here's a couple more nice guys I met in the party: Giuliano Ribeiro and Azidin Shairi.

And a couple of GDE powerhouses that I've known for a while and was also looking forward to connecting with: Mazlum Tosun and @xbill.

In the time it takes me to write this blog, Will will have published 50. He's a content-factory. (Will, somehow I totally failed to get a selfie with you. Next time...)

Then I met Shishir Suresh, fellow GDE from the UK. Another super-nice, welcoming and smart guy. (More with Shishir later.)

And I finally got to meet some of the folks that run the GDE program, and who make this whole experience possible: Ronan Mandel, Asrar Khan, and Alfredo Morresi. Guys, we owe you so much. (Selfies later in the blog!)

Tuesday: GDE Summit, Baby!

Tuesday was the Google Developer Experts Summit, at the Luxor.

This was my first ever GDE summit. The day was packed with talks from some Google titans, followed by a number of round tables. It was a sneak peek of things to come, and an opportunity for no-holds-barred Q&A. The content is all under NDA, so I'm not going break any rules.

But a quick glimpse at some of our speakers and sessions...

A welcome from Ron and Asrar:

Then some insights about the program. Alfredo and Natalie described the geographic distribution of GDEs, the mix of expertise, and the types of contributions we've made in the last 12 months.

Ooh look - that's me!

Then, an amazing hands-on session from Richard Seroter.

"What, THE Richard Seroter?"
"Yes, the very same."

(This guy is my hero. I might mention this in passing as the blog continues...)

This talk was a masterclass in how to do inspiring (and amusing) live demos. The demo included Gemini Enterprise, Stitch integrated with MCP, App Design Centre (which supports SO MANY MORE services than it did a few months ago), App Hub, the new BigQuery Agent for talking to your data, and so much more.

For me, this session reinforced the message that we're in a world where everyone can be a builder with AI. Some folks choose to resist that, for whatever reasons. But we have the option to embrace it, and help builders (who might be our clients) to use AI the right way, and get the most out of the platform.

These were some of the key nuggets. Or rather, my interpretation of those nuggets:

Planning remains crucial, but AI can certain help us with that.
Use cases are rarely unique, even across verticals. So we need to share more.
The lines between disciplines are dissolving with agents. So many folks over the last few days have mentioned how they're terrible at frontend dev (including Richard). But that just doesn't matter anymore.
Software dev tools are evolving. IDEs are evolving from being code-centric to being agent centric. (Aja talked quite a bit about this in the next session.) Now our tools are using multi-modal models, MCP and skills, so we can integrate with everything and we can "see" everything.
"Builders" are now managers of agents.
Context engineering is absolutely paramount, as we all knew it would be. And Google's platform now allows for sharing of context between services.
Boring reports should be a thing of the past. There's no excuse to not make compelling material / documentation / business cases, whatever, when we all have access to models like Nano Banana and Veo 3, and the ability to use Gemini in Google Workspace.
Researching has always been one of the things I enjoy most about what I do. I guess it's partly a legacy from that biochem degree, a lifetime ago. But now, everyone can do detailed research in a highly compressed timeline, using agents like Gemini Deep Research and tools like NotebookLM.
Everyone can prototype, and we shouldn't block this. (Enterprises - I'm looking at you!) Embrace the new-found enthusiasm of our new ecosystem of builders. And then, when we're ready to take this to production, Google's got you covered.
Train your builders! Certainly in my current client, I've been spending time educating teams on how to leverage agentic tools effectively, regardless of your role.

Then we had sessions from:

Scott Densmore and Aja Hammerly, discussing the evolving landscape of generative AI coding tools.
Logan Kilpatrick, Michael Gerstenhaber, and David Mclaughlin, discussing the partnership of Google Deepmind and Gemini Enterprise Agent Platform (the artist formerly known as Vertex AI)
A panel discussion combining Cloud DevRel, AI DevRel and GDM DevRel, with Karl Weinmeister, Aja, Dave Elliott, Omar Sanseviero, and Matt Thompson.

Wednesday

Breakfast with Jack

Early start! At 0700 I had breakfast with the legend that is Jack Wotherspoon.

"Not THE Jack Wotherspoon?"
"Yeah, that one."
"The Gemini CLI Jack Wotherspoon?"
"Yeah, the same."
"The Dev Keynote Jack Wotherspoon?"
"Yep."
"Pictures or it didn't happen."

Dammit, forgot to take a breakfast selfie.

Jack and I have been buddies for a while now. But it was great to just chat, and make the most of the EPAM VIP breakfast at the Seabreeze Café in the Mandalay.

The Opening Keynote

The keynotes are held in the Michelob ULTRA Arena, inside the Mandalay. It seats 10,000 people. It sounds like a lot, but it's not enough! Only about a third of people manage to get seated in the arena, and you have to queue early. My top tip for my colleages: for the 0900 Main Keynote, make sure you're in the queue by 0800.

Fortunately, GDEs get a fastlane and reserved seating. Check out this welcome!

The arena starts filling up. Time for a couple of fun photos.

And now let me introduce Jesse Nowlin:

He's a fellow GDE, and he's also a famous content creator. He happens to be the authority on Google Next and always shares an extremely helpful Know Before You Go, like this one:

As we're waiting for the keynote to begin, we were treated to an awesome duo of DJ + dynamic music visualisation using hand gestures to render the code in real time! (If someone knows their names, please tell me!)

The keynote then formally begins with a very cool video, created using Nano Banana 2, Veo 3.1 and Genie 3. Check out the Google blog on how this was done.

And then, as always, Thomas Kurian took to the stage to talk us through some of the big announcements. I said I wouldn't do a proper keynote recap. So I'll keep it short! You can check out the whole Google Cloud Next '26 - Opening Keynote on YouTube.

The era of the pilot is over. The era of the agent is here.

Let me give just a few key points...

The main theme of the keynote was that we're out of the agentic "proof-of-concept" era, into a world where everyone works with agents, and everyone is a builder.
Now we need to ensure our agents are production-ready, that they can scale, that we have seamless observability across our agents and their stack, and unified context, no matter where we are.
Gemini Enterprise agents were central for flight readiness and astronaut safety for Artemis II.
Google continues to be the only Cloud provider that offers a full stack for AI and agentic solutions, and a number of big innovations were announced across all layers in this integrated stack.
Mention of some of the latest models, which are not quite new. E.g. Gemini 3.1 Flash Image (aka Nano Banana 2), Veo 3.1 Lite, and Lyria 3 Pro.
The Vertex AI Platform has been rebranded - with evolution, of course - as Gemini Enterprise Agent Platform.
The new Gemini Enterprise Agent Platform is split across four pillars: Build, Scale, Govern, and Optimize.
The Agent Platform now integrates capabilities like: low-code Agent Studio, Agent Registry, and Skills & Tools Registry.
We now have off-the-shelf agent skills for many Google services and Workspace. Nice! Check them out.
And managed, remote MCP servers for all GCP services are now available in GA.
ADK now supports graph-based deterministic multi-agent orchestration.
Agent Identity, such that every agent has a unique, cryptographic ID.
Agent Gateway, a centralised command centre for agentic policy enforcement.
End-to-end multi-agent observability.
AI Hypercomputer:
- The big announcement here was the 8th Gen TPUs, which are not split across two specialised platforms: TPU 8t for training, and TPU 8i for inference. Lots of numbers dumped here, and mentions of advancements like "inter-chip interconnect".
- Google Cloud Axion N4A - now offering 2x price-performance vs comparable x86
- Support for latest NVIDIA GPUs
- The new Virgo network, which doubles the bandwidth between chip pods in a cluster.
- And up to 1 million TPUs in a single training cluster!
Knowledge Catalog is essentially the evolution of Dataplex. It allows for universal metadata management and context, and supports both structured and unstructured data sources, as well as third party sources.

Okay, you get the idea. You can check out 260 Things We Accounced at Google Cloud Next '26 to deep-dive into any of these topics.

The GDE and Certified Lounge

THIS. This was my favourite thing about Next. It was my oasis. My safe haven. My place of calm. My spiritual home during Next 26.

Look it's John Capobianco, again!

Here we had coffee; we had power; we had the ongoing live streams. And most importantly, ALL THE AMAZING PEOPLE! As a result, I spent way more time in this space than I was expecting. I had so many sessions booked in my calendar. But I ended up skipping several in order to spend more time in this Lounge, interacting with with Googlers and fellow GDEs. (And, of course, panicking for my own sessions and planned activities.)

These are some of the first people I met:

Cristine Souza was organising the GDE Studio Recording sessions here at Next, and my recording session was planned for tomorrow (Thursday). More on that later. But TL;DR - what an absolute pleasure to work with.

Then we have Lisa Carpenter, expert in ML and lead for GDG Bletchley. Thanks to Lisa for such a warm welcome, and: I've joined Bletchley!

And Xavier Portilla Edo. Our paths had not yet crossed. But I know they will in future. This guy is a GDE mentor, podcaster, course creator, author... (Man, I feel old.)

Then I got a chance to take a selfie with Shishir. We only met a couple of days ago, but I feel like we've been friends for a lifetime.

Jesse, who let me try out his cool Meta sunglasses!

And Abdel, who actually interviewed me for the GDE program!

(At this point, if I fail to mention how friendly / welcoming / smart someone is, let's just take it as given!)

Partner All-Stars Event

A few months ago I was fortunate to be named a Google Cloud Partner All-Star in Delivery Excellence.

And so, I got invited to the All-Star event at Next. But, thanks to a stupid migraine attack in the evening, I was scatter-brained and totally missed it. With any luck, there will be a next time...

Thursday

Breakfast with Richard

Early start. At 0700 I had breakfast with the legend that is Richard Seroter.

"Not THE Richard Seroter?"
"Yeah, that one."
"The Google Cloud Chief Evangelist?"
"Yeah, the same."
"The Dev Keynote Richard Seroter?"
"Yep."
"Pictures or it didn't happen."

DAMMIT Dazbo! Why do you keep forgetting to take selfies!

I may have mentioned I'm a fan. Richard has supported me for a while now, and was the person who invited me to the GDE program. So I owe him a lot! We've chatted quite a bit over the last year or so, but never met face-to-face. The fact that he gave up time to chat to me, just a couple hours before the big keynote, is a little astonishing. But he's such a decent guy.

We're in the Seabreeze, and we talked about stuff like: model lifecycles, demand for TPUs, and how Google is well-positioned in the AI long game, given the integrated stack.

And I learned that the keynote speakers get the full Hair, Wardrobe & Makeup treatment. Their outfits are selected for them!

As we parted ways, the unimagineable happened. He said: "I'm a big fan."

This Next is just getting better and better.

The Developer Keynote

This is the session many have been waiting for; certainly the GDEs. It's the Developer Keynote - where the rubber meets the road.

GDEs once again were escorted to reserved seating, right in front of the stage. I was in row 3! Check out the arena behind me:

This was an amazing keynote, where Richard and Emma guided us through the overall journey of building a marathon planning application. And with each section, they brought in Googlers to live demo a particular part of the journey. Again, I'm not going to share details about this. You can check out the Dev Keynote here:

I'll just share a few snaps...

Richard and Emma:

Look, Jack's back! (Watch the video - Jack has a camel.)

Here's Megan:

Jason and Ines:

Puppies!

No Next experience blog would be complete without at least one picture of the puppies on the Expo floor:

I wish I could sleep as easily as these guys!

Recording Session in the GDE Studio Pod

I've been incredibly excited about this. A little while back I submitted a proposal to record a fireside chat at Next, in the dedicated GDE Studio Pod. Then I forgot all about it. (Standard.)

A couple of weeks ago I received confirmation that the proposal had been accepted. Woop!

So, on Thursday afternoon, just after the Dev Keynote, I hopped into the pod with my buddies Jack (yes - that Jack), and Romin Irani. I've known Romin for a fairly long time. He is a Google Developer Advocate, and one of the managers of the Google Cloud Medium publication. Submitting content to that publication is how we originally met. Since then we've collaborated often and I'm honoured to call him my friend.

In the fireside, I refer to both these guys as Google legends. Google already sets the bar quite high on this front. It's rare I meet a Googler I don't like. But these guys definitely deserve "Legend" status.

The chat is about Gemini CLI, agents, MCP, skills, from three different perspectives:

From Jack, Google DevRel, in the AI Tools Team
From Romin, Google Developer Advocate, as someone who has a broad view of adoption through the publication
From myself, from the perspective of what it's like getting these sorts of tools into enterprises

Check it out! And please don't forget to hit the Like button and subscribe. I don't do a lot of YT content, but if you guys like it, I'll try and do more.

Weezer and Benson

At Google Next, there's always a big concert for attendees on the Thursday night. Last year it was The Killers. This year, it was Benson Boone, supported by Weezer.

So look, Google, I don't mean to tell you your business. But for an audience that is arguaby mostly male geeks, do you think Benson was the right choice? Was he though?

Of course, I'm just kidding. However, my wife - a Benson superfan - was not happy that I got to see Benson, whilst she didn't. There's definitely a glitch in the Matrix.

Try as I might to not like him (mainly for the benefit of my wife), there's no doubt that the guy can backflip off a piano without skipping a beat:

Friday

Morning Panic

For me, this was the big event. I was doing a lightning talk in the Developer Theatre, called: Automating the UI with Gemini CLI, MCP and Skills. Just a couple of hours before it was due to start, I was at 815 registrations. Eeeek!

I sat in the GDE and Certified Lounge and did a couple of panicked run-throughs. Whilst there, I managed to get a couple more selfies...

This is Ronan, Lord of Google Cloud GDEs. (I just made up that title. It's probably not his actual title.)

Matthew Eckstrom, it was a delight to meet you!

And now, a life-changing moment. I stood next to Asrar Khan, and thought... "Is he taking the p1ss?" He stood exactly as I was standing:

And then I had a bit of a lesson on how to pose for a camera. How have I gone my whole life without getting this advice? I NEVER look good in a photo. But just maybe half of the problem is how I've been standing.

Here's the post-Asrar-advice version:

OMG, that's so much better! This might genuinely be the most important thing I've learned at Next 26.

My Talk

I did my customary three visits to the toilet that precede any talks I do. Then I was backstage, getting mic'd up. And then... Showtime!

I asked my friends to help me crowd-source some photos. They didn't disappoint! Here's just a few:

And finally, I've ALWAYS wanted to do this. The stage selfie shot.

That was a blast! I think it went well. I didn't quite leave enough time to do Q&A. (Maybe that was by design!)

Quick shout-out: Mandeep, thanks for coming to say hello. It was a pleasure to meet you!

Poker

With the adrenaline still pumping from the talk, I had one last Vegas 'to-do' list item before heading to the airport. It wouldn't be a Vegas trip without at least some time spent in the casino. So I decided to play a couple of hours of poker before my late flight.

My buddy Marius and I found a table in the Mandalay. We both started out with $100 of chips. Over the next couple of hours I was up and down, but found myself with roughly what I'd started with. The girl to my left was dominating the table, and had probably about $1500 at this point.

I figured I was going to depart in the next couple of hands, one way or another. I've got a flight to get to! So, here's how my last hand played out, for any poker fans out there...

Blinds are $1 and $2.
I'm dealt pocket threes under the gun.
I probably wouldn't normally play it, but I knew I wanted to leave soon. I raise to $6.
Girl on my left re-raises to $15.
Everyone folds except BB, who calls.
Now it's back to me. Again, I possibly wouldn't normally call, but I figured, there's over $30 in the pot, I'm already in for $6, and if I happen to hit, they'll never see it coming. So I call.
Flop comes down: AK3. Oh yeah!
I bet $6. She raises to $15. BB calls. All exactly as expected.
I go All-In for about $70.
She calls. BB folds.
We turn the cards. She's got one K, but gets no help from the turn and river.

And then I go back to my room, with roughly twice what I started with. Yay!

I know it's not the biggest hand you've ever seen. But it was a fun way to end the day.

Going Home

Finally, I'm about to board for the 10 hour return flight. It's a little before 2300 and I have the pleasure of meeting Shishir at the gate, alongside my EPAM buddy Suds. Apologies to these guys - I kept dozing off whilst talking to them. I was SO TIRED!

Finally, I'm on the plane. And one of the nicest things happens. A guy who I've never met stops as he walks past my seat. He shakes my hand and tells me my talk was inspiring.

What a way to finish the Vegas experience.

Final Reflections

It sounds a bit cliché to say "it's all about the people". But in this case, it definitely was. I loved hanging out with Googlers and other GDEs. There's so many folks I'd spoken to remotely, but never met IRL. And I met so many unexpected new friends. I feel like part of the family now.

Well, I think I've written enough. That's a wrap!

Self-hosted Gemma 4 on TPU with vLLM, MCP, ADK, and Gemini CLI

xbill — Tue, 28 Apr 2026 01:48:30 +0000

This article provides a step by step deployment guide for Gemma 4 to v6e Trillium TPUs in an 8 core 2x4 setup. A suite of Python MCP tools is built to simplify management of the vLLM hosted Gemma 4 deployment with Gemini CLI. Finally- this deployed Gemma model is used as the main LLM from sample ADK agents.

What is this project trying to Do?

This project is a DevOps/SRE assistant that uses a Gemma 4 model self-hosted on Google Cloud TPUs to analyze infrastructure issues. It provides tools to provision the TPU and deploy the model, as well as for observability and performance testing.

Just the facts, ma’am

This project includes an active GCP infrastructure (V6E TPU, 2x4 topology, created 2026–04–26), compute (gemma4-vllm-stack-node, internal IP 10.128.0.18, external IP 35.193.100.125), and online vLLM inference with google/gemma-4–31B-it. Optimization standards include BF16/FP8 precision, TP=8 parallelism, 16384 max sequence length, and Flax/JAX (OpenXLA) engine.

AI-Driven Troubleshooting

The agent connects to Google Cloud Logging to identify errors in your environment. It uses a self-hosted vLLM inference server to summarize logs.

Infrastructure Automation

The project includes a full “Inference Stack” manager. It can:

Deploy Gemma with vLLM : Automatically generate and execute commands to deploy a 4x2 Trillium v6e
Generate Configs: Create Kubernetes (GKE) manifests for running vLLM on TPU v6e chips.

Gemini CLI

If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:

npm install -g @google/gemini-cli

Testing the Gemini CLI Environment

Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ gemini

 ▝▜▄ Gemini CLI v0.39.1
   ▝▜▄
  ▗▟▀ Signed in with Google /auth
 ▝▀ Plan: Gemini Code Assist Standard /upgrade

Node Version Management

Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:

GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Python MCP Documentation

The official GitHub Repo provides samples and documentation for getting started:

GitHub - modelcontextprotocol/python-sdk: The official Python SDK for Model Context Protocol servers and clients

Where do I start?

The strategy for starting MCP development for vLLM management is a incremental step by step approach.

First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.

Then, a minimal Python MCP Server is built with stdio transport. This server is validated with Gemini CLI in the local environment.

This setup validates the connection from Gemini CLI to the local server via MCP. The MCP client (Gemini CLI) and the Python MCP server both run in the same local environment.

Setup the Basic Environment

At this point you should have a working Python environment and a working Gemini CLI installation. The next step is to clone the GitHub samples repository with support scripts:

cd ~
git clone https://github.com/xbill9/aisprintapr2026

Then run init.sh from the cloned directory.

The script will attempt to determine your shell environment and set the correct variables:

cd tpu-vllm-devops-agent
source init.sh

If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:

cd tpu-vllm-devops-agent
source set_env.sh

Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.

vLLM Management Tool with MCP Stdio Transport

One of the key features that the standard MCP libraries provide is abstracting various transport methods.

The high level MCP tool implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.

The simplest transport that the SDK supports is the stdio (stdio/stdout) transport — which connects a locally running process. Both the MCP client and MCP Server must be running in the same environment.

The connection over stdio will look similar to this:

# Initialize FastMCP server
mcp = FastMCP("Self-Hosted vLLM DevOps Agent")

Running the Python Code

First- switch the directory with the Python version of the MCP sample code:

~/aisprintapr2026/tpu-vllm-devops-agent

Run the release version on the local system:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ make install
Processing ./.

The project can also be linted:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ make lint
ruff check .
All checks passed!
ruff format --check .
5 files already formatted
mypy .
Success: no issues found in 5 source files

And a test run:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ make test
python test_agent.py
......
----------------------------------------------------------------------
Ran 6 tests in 0.055s

OK

vLLM Interaction with MCP stdio Transport

One of the key features that the MCP protocol provides is abstracting various transport methods.

The high level tool MCP implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.

In this project Gemini CLI is used as the MCP client to interact with the Python MCP server code.

Gemini CLI settings.json

Replace the default Gemini CLI configuration file — settings.json with a pre-configured sample:

{
  "mcpServers": {
    "vllm-tpu-agent": {
      "command": "python3",
      "args": [
        "/home/xbill/aisprintapr2026/tpu-vllm-devops-agent/server.py"
      ],
      "env": {
        "GOOGLE_CLOUD_PROJECT": "aisprint-491218",
        "MODEL_NAME": "google/gemma-4-31B-it"
      }
    }
  }
}

Validation with Gemini CLI

The final connection test uses Gemini CLI as a MCP client with the Python code providing the MCP server:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ gemini

 ▝▜▄ Gemini CLI v0.39.1
   ▝▜▄
  ▗▟▀ Signed in with Google /auth
 ▝▀ Plan: Gemini Code Assist Standard /upgrade

 > /mcp list
Configured MCP servers:

ent
  - mcp_vllm-tpu-agent_verify_model_health

Getting Started with Gemma 4 on TPU

The GitHub Repo provinces a starter recipe:

tpu-recipes/inference/trillium/vLLM/Gemma4 at main · AI-Hypercomputer/tpu-recipes

The Official vLLM repo also has Gemma4 specific information:

Release v0.19.1 · vllm-project/vllm

TPU Deployment

A lower cost entry point for TPU deployment is Queued Resources. This approach allows TPU reservations to be requested in real-time and provides an easy path to allocate TPU — with some additional complexity:

Manage queued resources | Cloud TPU | Google Cloud Documentation

There are a few options to deploy vLLM on TPU- but the simplest is to use the generated docker instance:

tpu-recipes/inference/trillium/vLLM/Gemma4/docker-compose-gemma4-31B.yml at main · AI-Hypercomputer/tpu-recipes

vLLM Lifecycle Management via MCP

The MCP tools provide a complete suite of agent-oriented operations for managing vLLM deployment on Cloud Run or a TPU.

Overview of MCP tools :

🟢 vllm-tpu-agent - Ready (21 tools)
  Tools:
  - mcp_vllm-tpu-agent_check_tpu_availability
  - mcp_vllm-tpu-agent_describe_queued_resource
  - mcp_vllm-tpu-agent_destroy_queued_resource
  - mcp_vllm-tpu-agent_estimate_deployment_cost
  - mcp_vllm-tpu-agent_get_cloud_logging_logs
  - mcp_vllm-tpu-agent_get_deployed_endpoint
  - mcp_vllm-tpu-agent_get_model_details
  - mcp_vllm-tpu-agent_get_reservation_status
  - mcp_vllm-tpu-agent_get_system_status
  - mcp_vllm-tpu-agent_get_tpu_system_logs
  - mcp_vllm-tpu-agent_get_vllm_deployment_config
  - mcp_vllm-tpu-agent_get_vllm_docker_logs
  - mcp_vllm-tpu-agent_get_vllm_endpoint
  - mcp_vllm-tpu-agent_list_queued_resources
  - mcp_vllm-tpu-agent_manage_queued_resource
  - mcp_vllm-tpu-agent_manage_vllm_docker
  - mcp_vllm-tpu-agent_query_queued_gemma4
  - mcp_vllm-tpu-agent_query_queued_gemma4_with_stats
  - mcp_vllm-tpu-agent_run_vllm_benchmark
  - mcp_vllm-tpu-agent_save_hf_token
  - mcp_vllm-tpu-agent_verify_model_health

Request Queued TPU Resources

First — use the MCP tool to request TPU resources:

The status can be checked on the TPU status page on the Google Cloud Console:

with detailed information:

vLLM Deployment to Docker

Once the TPU has been activated- the MCP tools can check the Gemma deployment status:

Then the status can be checked:

And active:

Checking vLLM status

The status can be checked with an MCP tool:

 > get_system_status

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_system_status (vllm-tpu-agent MCP Server) {} │
│ │
│ 🌀 System Status (southamerica-east1-c) │
│ - vLLM Health: 🟢 Online (http://34.39.230.66:8000) │
│ 📋 Queued Resources in southamerica-east1-c │
│ 1 NAME STATE NODE_ID ACCELERATOR_TYPE CREATE_TIME │
│ 2 vllm-gemma4-qr ACTIVE 2026-04-27T16:35:53.683050645Z │
│ 👉 Next Step: Use query_queued_gemma4 to interact with the model. │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ I've received the system status. The vLLM service is online and a queued resource is active.

Query the Model with Stats

Once everything is online — you can send queries to the Model:

 > queued_gemma4_with_stats the battle of hastings

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ query_queued_gemma4_with_stats (vllm-tpu-agent MCP Server) {"prompt":"the battle of hastings"} │
│ │
│ 📊 Performance Stats │
│ - Time to First Token (TTFT): 0.764s │
│ - Total Generation Time: 15.709s │
│ - Tokens per Second: 68.19 tokens/s │
│ - Total Tokens (approx.): 1019 │
│ │
│ 💬 Model Response │
│ The Battle of Hastings was one of the most consequential events in European history. Fought on October 14, 1066, it marked the beginning │
│ of the Norman Conquest of England, fundamentally altering the English language, culture, and political structure. │
│ │
│ Here is a detailed breakdown of the battle: │
│ │
│ --- │
│ │
│ 1. The Cause: A Crisis of Succession │
│ The battle was the result of a power struggle following the death of Edward the Confessor, the King of England, who died childless in │
│ January 1066. Three main contenders claimed the throne: │
│ │
│ * Harold Godwinson: The most powerful earl in England and Edward’s brother-in-law. He was crowned king immediately after Edward's death. │
│ * William, Duke of Normandy: A distant cousin of Edward. He claimed that Edward had promised him the throne years earlier and that Harold │
│ had sworn an oath to support him. │
│ * Harald Hardrada: The King of Norway, who believed he had a hereditary right to the throne through his ancestors. │
│ │
│ 2. The Prelude: A Year of Two Invasions │
│ Before facing William, King Harold had to deal with the Vikings. In September 1066, Harald Hardrada invaded Northern England. Harold │
│ Godwinson marched his army 185 miles in just a few days and defeated the Vikings at the Battle of Stamford Bridge. │
│ │
│ However, while Harold was celebrating in the north, the wind changed in the English Channel. William of Normandy landed his invasion force │
│ at Pevensey on the south coast. Harold had to march his exhausted army all the way back down south to meet the new threat. │
│ │
│ 3. The Battle (October 14, 1066) │
│ The two armies met at Senlac Hill, about seven miles from Hastings. │
│ │
│ The Opposing Forces: │
│ * The English (Anglo-Saxons): Comprised mostly of infantry. Their primary tactic was the "Shield Wall"—soldiers stood │
│ shoulder-to-shoulder with overlapping shields, creating an almost impenetrable barrier of wood and steel. │
│ * The Normans: A more diverse army consisting of archers, infantry, and—most crucially—heavy cavalry (knights on horseback). │
│ │
│ The Course of the Fight: │
│ * The Stalemate: For most of the day, the English shield wall held firm atop the ridge. The Norman archers fired upward, but their arrows │
│ mostly flew over the English heads or bounced off the shields. The Norman cavalry charges failed to break the line. │
│ * The Turning Point (The Feigned Retreat): Seeing that the shield wall was unbreakable, William ordered his troops to pretend to panic │
│ and retreat. Some English soldiers, thinking they had won, broke formation and chased the Normans down the hill. Once the English were │
│ out in the open and disorganized, the Norman cavalry wheeled around and slaughtered them. │
│ * The End: By late afternoon, the English line was thinned and exhausted. King Harold was killed—traditionally believed to have been hit │
│ in the eye with an arrow, though some sources suggest he was hacked to death by Norman knights. │
│ │
│ 4. The Outcome and Aftermath │
│ With the death of King Harold and much of the English nobility, organized resistance collapsed. │
│ │
│ * Coronation: William marched to London and was crowned King of England on Christmas Day, 1066, at Westminster Abbey. He became known as │
│ William the Conqueror. │
│ * The Feudal System: William replaced the English nobility with Norman lords, introducing a rigid feudal system. │
│ * Language: French became the language of the court, administration, and law for centuries. This is why Modern English is a hybrid of Old │
│ English (Germanic) and French (Latinate). │
│ * Architecture: To secure his hold on the land, William built massive stone castles across England, including the Tower of London. │
│ │
│ 5. Historical Legacy: The Bayeux Tapestry │
│ Much of what we know about the battle comes from the Bayeux Tapestry. This 70-meter-long embroidered cloth depicts the events leading up │
│ to the battle and the battle itself. While created from a Norman perspective (and thus biased), it remains one of the most important │
│ visual records of the Middle Ages. │
│ │
│ Summary Table │
│ ┌────────────┬─────────────────────────────┬────────────────────────────────┐ │
│ │ Feature │ Anglo-Saxons │ Normans │ │
│ ├────────────┼─────────────────────────────┼────────────────────────────────┤ │
│ │ Leader │ King Harold Godwinson │ William, Duke of Normandy │ │
│ │ Key Tactic │ Shield Wall │ Cavalry & Archers │ │
│ │ Terrain │ Defensive (Top of the hill) │ Offensive (Bottom of the hill) │ │
│ │ Outcome │ Defeat / Death of King │ Victory / Conquest of England │ │
│ └────────────┴─────────────────────────────┴────────────────────────────────┘ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ The model has provided a detailed response about the Battle of Hastings, including performance statistics for the query.

Deploying MCP Server to Cloud Run

Once the local stdio MCP server has been tested- it can be deployed to Google Cloud Run.

First switch to the MCP server directory and deploy:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent/mcp-https-python$ make deploy
Submitting build to Google Cloud Build...
Creating temporary archive of 13 file(s) totalling 36.7 KiB before compression.
Some files were not included in the source upload.

Check the gcloud log [/home/xbill/.config/gcloud/logs/2026.04.27/20.26.23.215852.log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).

After the build- the MCP server will be on a well known endpoint. The settings.json will have an entry:

 {
    "mcpServers": {
    "gemma4": {
      "httpUrl": "https://mcp-https-python-wgcq55zbfq-rj.a.run.app/mcp"
    }
  }
}

The MCP tools are available from the Cloud Run service:

 > /mcp list
Configured MCP servers:

🟢 gemma4 - Ready (20 tools)
  Tools:
  - mcp_gemma4_check_tpu_availability
  - mcp_gemma4_describe_queued_resource
  - mcp_gemma4_destroy_queued_resource
  - mcp_gemma4_estimate_deployment_cost
  - mcp_gemma4_get_cloud_logging_logs
  - mcp_gemma4_get_deployed_endpoint
  - mcp_gemma4_get_model_details

To test the MCP Tool:

 > get model details
✦ I will retrieve the detailed information for the currently running Gemma 4 model and vLLM engine.

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Action Required │
│ │
│ ? get_model_details (gemma4 MCP Server) {} │
│ │
│ MCP Server: gemma4 │
│ Tool: get_model_details │
│ │
│ MCP Tool Details: │
│ (press Ctrl+O to expand MCP tool details) │
│ Allow execution of MCP tool "get_model_details" from server "gemma4"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. Allow tool for all future sessions ~/.gemini/policies/auto-saved.toml │
│ 5. No, suggest changes (esc) │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ I will retrieve the detailed information for the currently running Gemma 4 model and vLLM engine.

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_model_details (gemma4 MCP Server) {} │
│ │
│ 🧩 Model & vLLM Engine Details (http://34.39.243.194:8000) │
│ │
│ Model Information (/v1/models): │
│ 1 { │
│ 2 "object": "list", │
│ 3 "data": [ │
│ 4 { │
│ 5 "id": "google/gemma-4-31B-it", │
│ 6 "object": "model", │
│ 7 "created": 1777336641, │
│ 8 "owned_by": "vllm", │
│ 9 "root": "google/gemma-4-31B-it", │
│ 10 "parent": null, │
│ 11 "max_model_len": 16384, │
│ 12 "permission": [ │
│ 13 { │
│ 14 "id": "modelperm-aaefbddc518584d8", │
│ 15 "object": "model_permission", │
│ 16 "created": 1777336641, │
│ 17 "allow_create_engine": false, │
│ 18 "allow_sampling": true, │
│ 19 "allow_logprobs": true, │
│ 20 "allow_search_indices": false, │
│ 21 "allow_view": true, │
│ 22 "allow_fine_tuning": false, │
│ 23 "organization": "*", │
│ 24 "group": null, │
│ 25 "is_blocking": false │
│ 26 } │
│ 27 ] │
│ 28 } │
│ 29 ] │
│ 30 } │
│ vLLM Version (/version): │
│ - Version: 0.19.2rc1.dev215+g32e45636e │
│ │
│ Health Status (/health): │
│ - Status: Healthy ✅ │
│ │
│ Key vLLM Metrics (/metrics): │
│ 1 # HELP process_resident_memory_bytes Resident memory size in bytes. │
│ 2 # TYPE process_resident_memory_bytes gauge │
│ 3 process_resident_memory_bytes 2.460672e+09 │
│ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ The system is currently running Gemma 4 (31B-it) via vLLM version 0.19.2rc1. The model is healthy and configured with a maximum sequence length
  of 16,384 tokens.

But Wait! There’s More!

First — get the TPU deployed Gemma 4 URL:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent$ gemini

 ▝▜▄ Gemini CLI v0.39.1
   ▝▜▄
  ▗▟▀ Signed in with Google /auth
 ▝▀ Plan: Gemini Code Assist Standard /upgrade

 > get model url

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_vllm_endpoint (vllm-tpu-agent MCP Server) {} │
│ │
│ 🟢 vLLM is Online at: http://34.39.243.194:8000 │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ I have found the vLLM endpoint. It is running at http://34.39.243.194:8000.

save the endpoint:

export MODEL_URL=http://34.39.243.194:8000

then test with the ADK CLI:

xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent/agents$ adk run gemma4vllm
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
Log setup complete: /tmp/agents_log/agent.20260427_205922.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/cli/cli.py:204: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
Running agent vllm_agent, type exit to exit.
[user]: what do you do
20:59:32 - LiteLLM:INFO: utils.py:3995 - 
LiteLLM completion() model= google/gemma-4-31B-it; provider = openai
[vllm_agent]: * User asks: "what do you do"
    * Context: I am a helpful assistant running on a self-hosted vLLM endpoint. My internal name is "vllm_agent".

    * I am a Large Language Model (LLM).
    * I process text inputs and generate text outputs.
    * I can perform various tasks: answering questions, writing code, summarizing text, creative writing, analysis, etc.
    * I am hosted via vLLM (an inference engine for LLMs).

    * *Who am I?* A helpful AI assistant (internally known as `vllm_agent`).
    * *What are my capabilities?*
        * Answering questions (knowledge retrieval).
        * Writing and debugging code.
        * Summarization and analysis.
        * Content creation (emails, stories, essays).
        * Translation.
        * General conversation.
    * *How do I operate?* I process patterns in data to provide coherent and useful responses based on the prompts I receive.

    * Keep it helpful, clear, and concise.
    * Acknowledge the "agent" persona if appropriate, but focus on the functional utility.I am a helpful AI assistant (internally known as `vllm_agent`) designed to process information and generate human-like text. Because I am powered by a large language model running on a vLLM endpoint, I can help you with a wide variety of tasks, including:

**1. Information & Learning**
* **Answering questions:** From general knowledge to complex technical explanations.
* **Summarization:** Taking long articles or documents and condensing them into key points.
* **Research:** Helping you explore a topic or brainstorming ideas.

**2. Writing & Content Creation**
* **Drafting:** Writing emails, essays, blog posts, or reports.
* **Creative Writing:** Creating stories, poems, or scripts.
* **Editing:** Checking grammar, improving tone, or rewriting text for clarity.

**3. Technical & Analytical Tasks**
* **Coding:** Writing code in various programming languages, debugging errors, and explaining how a piece of code works.
* **Data Analysis:** Helping you organize information or interpret complex data.
* **Translation:** Translating text between dozens of different languages.

**4. Problem Solving & Brainstorming**
* **Planning:** Creating itineraries, study plans, or project outlines.
* **Ideation:** Generating names for a business, gift ideas, or marketing slogans.
* **Logic:** Solving puzzles or working through mathematical problems.

**In short: If it involves processing, generating, or analyzing text and code, I can likely help you with it! How can I assist you today?**



and the ADK Web interface:



  
  
  MCP Operations from an ADK Agent with Gemma 4 TPU


The final validation uses an ADK Agent to call the Cloud Run MCP endpoint to allow model operations over MCP calls from an agentic perspective:



xbill@penguin:~/aisprintapr2026/tpu-vllm-devops-agent/agents$ adk run gemma4mcp
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
Log setup complete: /tmp/agents_log/agent.20260427_210657.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/cli/cli.py:204: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
Running agent devops, type exit to exit.
[user]: get model stats
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.BASE_AUTHENTICATED_TOOL is enabled.
  check_feature_enabled()
[devops]: The model currently deployed is `google/gemma-4-31B-it`. The vLLM version is `0.19.2rc1.dev215+g32e45636e` and its health status is `Healthy` ✅. The process resident memory is `2.46 GB`.



and from the ADK Web interface:



Detailed information can pulled directly into the Agent:



  
  
  One Last Code Review with Gemini CLI


Gemini CLI was used to summarize the project:



✦ This project is a TPU vLLM DevOps Agent, designed to function as an expert Site Reliability Engineer (SRE) for managing a self-hosted Gemma 4 AI
  model running on Google's Tensor Processing Units (TPUs).

  In simple terms, it's a control panel and automation layer for running your own powerful AI model, making it easier to deploy, monitor, and
  interact with.

  Here’s a breakdown of its key functionalities:

  Core Components

   1. Inference Stack: The project is built to manage a specific AI setup: the google/gemma-4-31B-it model running on a vLLM/vllm-tpu container,
      which is a specialized environment for serving models on TPUs. It's designed for high-performance inference on TPU v6e hardware.

   2. MCP Server (server.py): This is the heart of the project. It's an agent that exposes a set of tools (as an API) to manage the inference stack.
      These tools allow you to:
       * Deploy and Manage Infrastructure: Programmatically create, delete, and inspect the status of TPU resources (Queued Resources) needed to run
         the model.
       * Monitor and Observe: Check the health of the vLLM service, monitor TPU utilization (like HBM and Tensor Core usage), and fetch logs.
       * Benchmark Performance: Run load tests and benchmarks to measure the model's throughput and latency.
       * Interact with the Model: Query the self-hosted Gemma 4 model.

  Key Features

   * Turnkey Deployment: The orchestrate_gemma4_stack tool simplifies the entire process of provisioning a TPU and deploying the Gemma 4 model with
     all the necessary optimizations.
   * Cost Efficiency: It's designed to use Google Cloud's Flex-start VMs, which are lower-cost, preemptible TPUs, making it more affordable to run a
     large model.
   * Gemini CLI Integration: The project includes instructions for setting up a LiteLLM proxy. This proxy translates requests from the standard
     Gemini CLI, so you can use the gemini command on your terminal, and have the requests be served by your private, self-hosted Gemma 4 model
     instead of the public Google API.
   * Benchmarking and Testing: The project includes scripts (benchmarking_suite.py and load_test.py) to systematically measure the performance of
     your self-hosted model under various conditions.

  In summary, this project provides the automation and tooling necessary for a DevOps engineer or researcher to run, manage, and analyze a powerful,
  private instance of the Gemma 4 model on Google's TPU infrastructure.








  
  
  Summary


The strategy for using MCP for vLLM Gemma 4 deployment on TPU with Gemini CLI was validated with a incremental step by step approach.

A minimal stdio transport MCP Server was started from Python source code and validated with Gemini CLI running as a MCP client in the same local environment. This Python server provided all of the management tools to deploy and troubleshoot vLLM deployments.

Then this MCP server was deployed to Cloud Run.

Finally ADK agents were configured to use the MCP server and TPU deployed Gemma4 vLLM server.

ML acceleration guide: TPUs vs GPUs

Glen Yu — Tue, 28 Apr 2026 00:16:10 +0000

There’s a lot of hype around GPUs and NVIDIA, but how much do you know about TPUs?

Article includes code examples you can find near the end

Rise of GPUs

Graphics Processing Units have been around for quite some time and their job is to render 2D and 3D graphics in to millions of pixels, calculating their colour, texture, lighting, in parallel to send to your monitor. For a 60Hz monitor that means producing rendered frames 60 times every second.

Rendering graphics is one thing, but developing code for handling GPUs was a little more difficult. That is, until NVIDIA launched CUDA (Compute Unified Device Architecture) in 2006, which allowed scientific researchers and developers who work in fields that require massive parallel math to take advantage of a GPU’s capabilities. With the rise of machine learning in the early 2010’s, it was discovered that the massive parallel math was exactly what ML engineers needed to train deep neural networks. Since then, the focus of CUDA has been shifting more towards optimizing for machine learning and AI workloads.

Because GPUs were commercially available and relatively inexpensive at the time, the barrier to entry was low. An ML engineer could train models on their NVIDIA graphics card during the day and jump into a game of League of Legends at night on the same hardware.

Honourable mention

AMD’s GPUs with Radeon Open Compute (ROCm) in an open-source software stack designed to compete in the AI ecosystem. Though it’s not as popular as CUDA, this gap is closing with Meta recently signing a deal to expand its existing partnership with AMD.

Tensor Processing Unit

In the early 2010s, Google projected that the growing demands of its AI workloads, particularly the rapid adoption of deep learning across products like Search and Photos, would require doubling its data center computing capacity roughly every year and a half. Rather than scale generic hardware indefinitely, Google sought a more efficient solution purpose-built for neural network computation, and thus the Tensor Processing Unit (TPU) was born. The TPU is a custom application-specific integrated circuit (ASIC) designed by Google specifically to accelerate AI workloads, deployed internally starting in 2015. By specializing the hardware for the dense matrix operations at the heart of neural networks, TPUs achieve dramatically better performance per watt than general-purpose CPUs or GPUs, reducing both energy consumption and cooling demands at data center scale.

Google has a tradition of making tools it uses internally available to the broader world, and TPUs are another example of this. The existence of TPUs was first publicly announced at Google I/O in 2016. In 2018, Cloud TPU v2 became available for external users through Google Cloud, marking the first time developers outside Google could harness the same accelerators powering Google’s own AI systems. TPUs also come in two performance flavours: efficiency and performance to meet different market needs.

NOTE: As of the 8th generation of TPUs announced during Google Next 2026, efficiency and performance TPUs will be renamed inference and training respectively in favour of a more descriptive, workload-based naming convention.

Architecture layout

From an architectural standpoint, GPUs can be thought of as being individual computers with accelerators (picture your home gaming PC). If you want to connect them into a cluster, it would be over network, but no matter how fast the network is, it still has to cross node boundaries, and bandwidth drops as a result.

TPUs are designed from the ground up to be interconnected at a massive scale with a physical layout that involves thousands of TPU chips in a torus topology which gives every chip 6 neighbours (two per axis, one on each side). Recognize that interconnect bandwidth would be the main bottleneck at this scale, Google designed their own proprietary Inter-Chip Interconnect (ICI) network which provides uniform, high-bandwidth, low-latency connections between all the chips in a slice regardless of physical location. With torus topology, there is no concept of crossing a node boundary. When you request TPUs, you do not get the entire TPU cluster or pod. Rather, you get only a small subset or slice. To make this possible, Google developed Optical Circuit Switch (OCS) to be able to rewire physical connections on the fly (entirely in software), allowing the same hardware to serve different workload shapes without any physical reconfiguration.

NOTE: Efficiency TPU versions use a 2D torus topology, while Performance TPUs leverage a 3D torus architecture to give you maximum performance with minimum latency.

Precision and range

A floating-point number consists of three parts:

Sign: Positive or negative (represented by the first bit)
Exponent: Determines the range of the number
Mantissa: Significant digits of a floating-point number, which determines the accuracy

Traditionally, the standard for high-performance computing was FP32. When AI researchers moved to FP16 to save memory, they lost more than just accuracy: they also lost range. FP32 uses 8 bits for the exponent, while FP16 uses only 5. The 3-bit difference in the exponent bits amount to an almost 10³⁴ difference in range (FP32 has a range of 3.4 x 10³⁸, while FP16 only has a range of 6.5 x 10⁴). In deep learning, where gradients can be incredibly tiny, FP16 often suffers from underflow (meaning numbers are being rounded to 0 because it is too small for FP16’s range to represent), requiring a technical workaround called “loss scaling” to keep the math stable.

Google Brain (now part of Google DeepMind) solved this invented Brain Floating Point (bfloat16), which simply shifted 3 bits from the mantissa to exponents:

Format	Total Bits	Exponent Bits	Mantissa Bits
FP32	32	8	23
FP16	16	5	10
bfloat16	16	8	7

By sacrificing precision for range, bfloat offers the same massive range as FP32, but with the reduced memory and bandwidth of FP16. A huge reason for why this works is that deep learning models are surprisingly noise-tolerant and having more training stability is for more important than having a few extra decimal places of precision. Today, bfloat16 is the de facto standard for training modern LLMs on NVIDIA’s GPUs and Google’s TPUs.

Why XLA matters

Standard Python execution typically takes an eager approach. This means it executes each step as it is being encountered. This is great for debugging because you can insert print statements to inspect variables at any point.

XLA (Accelerated Linear Algebra), on the other hand, is a domain-specific JIT compiler. Instead of executing steps one by one, it analyzes the entire execution graph to optimize and fuse operations before they run. This lazy approach creates an initial warm-up delay, but once the training starts, it is significantly faster than standard methods. The tradeoff is transparency: your step-by-step Python code becomes an optimized “black box”, making traditional debugging strategies more difficult. This is why TPUs are powerhouses for massive enterprise training, while GPUs remain the flexible choice for quick experimentation.

NOTE: Though XLA was built for TPUs, it’s also made its way into the NVIIA GPU ecosystem via tools such as JAX and torch.compile since PyTorch 2.0.

TorchTPU

Google is engineering a TorchTPU stack that will provide native PyTorch support. This would allow you to run models in TPUs as they are with full support for native PyTorch features. TorchTPU is currently in preview, and once it becomes GA, you can be sure I’ll be diving deeper into it!

Code example

I’m including a couple of Jupyter notebooks that I ran via Antigravity + Colab plugin for you to try yourself:

As you will see from the results below, TPU is indeed faster. However, my example isn’t large enough or complex enough to really showcase the true speeds that TPU can bring.

NOTE: I have a Colab Pro account which affords me access to additional GPUs and TPUs. The Colab free tier only includes NVIDIA T4 and TPU v5e-1

Interpreting training results

These are some benchmark trainings (epochs: 50, batch size: 512) in which I used a NVIDIA T4 GPU with (default) FP32 vs Google TPU v5e-1 (single chip TPU) with bfloat16. As expected, TPUs were faster but with lower precision:

I then trained the same model using the T4 GPU using bfloat16 but noticed a massive performance drop. This was due to the T4 being an older generation GPU that did not support bfloat16 natively and had to emulate which added a lot of overhead. Switching to a newer L4 GPU, I was able to see the (tiny) performance gain along with the reduced precision:

Finally, I thought I’d see how the training would perform on a newer TPU v6e-1 and I was blown away by the improvement:

Conclusion

Comparing GPUs and TPUs isn’t exactly apples-to-apples. They represent fundamentally different philosophies in architecture, memory management, and execution.

In the modern enterprise, it isn’t usually a matter of choosing one over the other, but rather using each where it shines. For rapid iteration and smaller workloads, the flexibility of GPUs is unmatched. However, once a project hits a certain scale, the domain-specific architecture of the TPU becomes the clear winner in efficiency and throughput.

TPUs are as fast as they are because they are a specialized one-trick pony, but to truly harness that power requires a deeper understanding of the stack. The biggest challenge isn’t often the compute itself, but rather: “How do I feed data to the TPUs fast enough and efficiently enough so that it doesn’t become the bottleneck?” and ensuring your input pipeline is fast enough so that the hardware doesn’t sit idle.

In future posts, I'll dive deeper into these advanced concepts to show how you can optimizing data pipelines to get the most out of your TPUs.

BONUS: Google’s 8th-generation TPUs announced at Google Next

Fine-Tune Any HuggingFace Model like Gemma on TPUs with TorchAX

Ahmed Elnaggar — Mon, 27 Apr 2026 08:45:25 +0000

What if you could fine-tune any HuggingFace model on TPUs — using PyTorch code?

Here is what the end result looks like:

import torchax as tx
import torchax.train

# One function: forward → loss → gradients → optimizer update
step_fn = tx.train.make_train_step(model_fn, loss_fn, optimizer)

# Training loop
for batch in dataloader:
    loss, params, opt_state = step_fn(params, buffers, opt_state, batch, batch["labels"])

Your PyTorch model. JAX's training primitives. Running on TPU. No rewrite needed.

In the first part of this series, we ran HuggingFace models on JAX for fast inference. Now we take the next step: training. We will instruction-tune Gemma 3 1B on the Databricks Dolly 15k dataset using LoRA and torchax's functional training API — all on a free Colab TPU.

Why Train on TPUs?

Google's Tensor Processing Units (TPUs) are purpose-built for matrix operations — the bread and butter of deep learning. Free Colab gives you access to a TPU v2-8 with ~15GB of high-bandwidth memory. That is enough to fine-tune a 1B parameter model with LoRA.

But training on TPUs traditionally meant rewriting your model in JAX (Flax, Equinox) or using PyTorch/XLA. torchax offers a third path: keep your PyTorch model, but use JAX's functional training primitives.

How torchax Training Differs from Standard PyTorch

Standard PyTorch	torchax
`loss.backward()`	`jax.value_and_grad(loss_fn)(params, ...)`
`optimizer.step()`	`optax.apply_updates(params, updates)`
Model holds its own state	Params and buffers are separate pytrees
Eager execution	JIT-compiled training steps

The key difference: functional training. Instead of calling loss.backward() and optimizer.step() on a stateful model, torchax separates the model into immutable weight pytrees and passes them through pure functions. This is what enables JAX's jax.jit to compile the entire training step into a single optimized program.

Prerequisites & Setup

What you need:

Python 3.10+
Basic familiarity with PyTorch and HuggingFace transformers
A Google Colab account (free tier works with LoRA)

Zero-setup option: Click the Colab badge above. The notebook handles all installation automatically.

Local setup:

# PyTorch CPU (torchax handles the accelerator via JAX)
pip install torch --index-url https://download.pytorch.org/whl/cpu

# JAX + all training dependencies in a single pip call
pip install -U 'jax[tpu]' torchax transformers flax peft datasets optax   # TPU
# pip install -U 'jax[cuda12]' torchax transformers flax peft datasets optax  # GPU

Colab note: The notebook installs packages and automatically restarts the runtime, since Colab pre-loads an older JAX that stays cached in memory until restart.

Key Concepts for Training

Before writing code, let's understand the four concepts that make torchax training work.

1. Param/Buffer Separation

JAX's jax.value_and_grad needs to know which inputs to differentiate. In standard PyTorch, the model owns its weights. In torchax training, we explicitly separate:

params — trainable parameters (get gradients)
buffers — everything else (frozen weights, running stats, constants)

params = {n: p for n, p in model.named_parameters() if p.requires_grad}
frozen = {n: p for n, p in model.named_parameters() if not p.requires_grad}
buffers = dict(model.named_buffers())
buffers.update(frozen)

For LoRA, params contains only the tiny adapter weights (~0.5% of the model). For full fine-tuning, it contains everything.

2. optax Optimizers

Unlike PyTorch optimizers (which carry hidden mutable state), optax optimizers are pure functions:

# PyTorch: hidden state inside optimizer
optimizer.step()

# optax: explicit state, no hidden pockets
updates, new_opt_state = optimizer.update(grads, opt_state, params)
new_params = optax.apply_updates(params, updates)

This functional design means the optimizer state is just another pytree that flows through the training step — perfect for jax.jit.

3. make_train_step

torchax.train.make_train_step() is the central API. It composes three pieces into a single JIT-compilable function:

model_fn — a pure function: (weights, buffers, batch) → output
loss_fn — extracts the scalar loss: (output, labels) → loss
optimizer — an optax optimizer

The result is step_fn(params, buffers, opt_state, batch, labels) → (loss, new_params, new_opt_state).

Under the hood, this uses jax.value_and_grad for efficient gradient computation and optax.apply_updates for weight updates — all compiled into a single XLA program.

4. Full Fine-Tuning vs LoRA

	Full Fine-Tuning	LoRA
Trainable params	All (~2B)	Tiny adapters (~0.5%)
Memory	~18-20 GB	~5-7 GB
Speed	Slower	Faster
Quality	Higher ceiling	Nearly as good
Free Colab TPU	Tight / may OOM	Fits comfortably

LoRA (Low-Rank Adaptation) freezes the base model and adds small trainable matrices to attention layers. Instead of updating the full weight matrix W, it learns a low-rank decomposition: W + (α/r) × B·A where A and B are tiny matrices.

For free Colab, LoRA is the recommended path.

Step 1: Load and Prepare the Dataset

We use Databricks Dolly 15k — 15,000 human-written instruction-response pairs across 7 categories (QA, summarization, brainstorming, etc.).

import datasets as hf_datasets
from transformers import AutoTokenizer

MODEL_NAME = "google/gemma-3-1b-it"
DATASET_NAME = "databricks/databricks-dolly-15k"

tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
if tokenizer.pad_token is None:
    tokenizer.pad_token = tokenizer.eos_token

raw_dataset = hf_datasets.load_dataset(DATASET_NAME, split="train")

Each example has an instruction, optional context, response, and category. We format these into Gemma's chat template:

def format_example(example):
    user_content = example["instruction"]
    if example.get("context", ""):
        user_content += f"\n\nContext: {example['context']}"

    messages = [
        {"role": "user", "content": user_content},
        {"role": "assistant", "content": example["response"]},
    ]
    text = tokenizer.apply_chat_template(messages, tokenize=False)
    return {"text": text}

Then tokenize and create dataloaders:

from torch.utils.data import DataLoader
from transformers import DataCollatorForLanguageModeling

# Subset, split, tokenize
subset = raw_dataset.shuffle(seed=42).select(range(2200))
split = subset.train_test_split(test_size=200, seed=42)

def tokenize_example(example):
    formatted = format_example(example)
    return tokenizer(formatted["text"], padding="max_length", max_length=512, truncation=True)

train_tokenized = split["train"].map(tokenize_example, remove_columns=split["train"].column_names)
eval_tokenized = split["test"].map(tokenize_example, remove_columns=split["test"].column_names)

collator = DataCollatorForLanguageModeling(tokenizer=tokenizer, mlm=False)
train_dataloader = DataLoader(train_tokenized, shuffle=True, collate_fn=collator, batch_size=2)
eval_dataloader = DataLoader(eval_tokenized, shuffle=False, collate_fn=collator, batch_size=2)

Step 2: Load the Model and Apply LoRA

Here is where the torchax pattern matters: load the model with torchax disabled, then enable it before moving to JAX.

import torch
import torchax as tx
import peft

# Load model with torchax disabled to avoid intercepting init ops
with tx.disable_temporarily():
    model = transformers.AutoModelForCausalLM.from_pretrained(
        MODEL_NAME, torch_dtype=torch.bfloat16
    )

# Sync pad_token_id so loss computation properly ignores padding
model.config.pad_token_id = tokenizer.pad_token_id

Why disable? HuggingFace model initialization uses operations (like in-place tensor filling) that torchax does not support. Disabling torchax during loading keeps everything on CPU, then we move to JAX after.

Now apply LoRA:

peft_config = peft.LoraConfig(
    task_type=peft.TaskType.CAUSAL_LM,
    inference_mode=False,
    r=8,                             # Rank of the LoRA matrices
    lora_alpha=16,                   # Scaling factor
    lora_dropout=0.0,                # 0.0 for bfloat16 numerical stability
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],  # All attention layers
)
model = peft.get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Output: trainable params: 5,767,168 || all params: 2,619,206,656 || trainable%: 0.22%

Only 0.22% of parameters are trainable — that is the power of LoRA.

Finally, enable torchax and move to the JAX device:

tx.enable_accuracy_mode()  # Float32 accumulation for bfloat16 stability
tx.enable_globally()
device = torch.device("jax")
model.to(device)
model.train()

Step 3: Baseline Evaluation

Before training, we measure the model's performance to compare against later:

import math

def evaluate_loss(model, dataloader, device, max_batches=50):
    model.eval()
    total_loss, total_batches = 0.0, 0
    with torch.no_grad():
        for i, batch in enumerate(dataloader):
            if i >= max_batches:
                break
            # Drop attention_mask — Gemma's sliding window attention produces NaN
            # with padded masks on torchax/JAX. Labels already mask padding with -100.
            batch = {k: v.to(device) for k, v in batch.items() if k != "attention_mask"}
            outputs = model(**batch)
            total_loss += outputs.loss.item()
            total_batches += 1
    model.train()
    avg_loss = total_loss / max(total_batches, 1)
    return avg_loss, math.exp(min(avg_loss, 100))

baseline_loss, baseline_ppl = evaluate_loss(model, eval_dataloader, device)
print(f"Baseline loss: {baseline_loss:.4f}, perplexity: {baseline_ppl:.2f}")

We also generate sample responses for qualitative comparison. For fast generation, we register StaticCache as a JAX pytree and use KV-cached decoding — only the new token is processed each step instead of the full sequence (~50x faster):

from transformers.cache_utils import StaticCache
from jax.tree_util import register_pytree_node

def _flatten_static_cache(cache):
    return (cache.key_cache, cache.value_cache), (
        cache.config, cache.max_batch_size, cache.max_cache_len,
        getattr(cache, "device", None), getattr(cache, "dtype", None),
    )

def _unflatten_static_cache(aux, children):
    config, max_batch_size, max_cache_len, dev, dtype = aux
    kwargs = {}
    if dev is not None: kwargs["device"] = dev
    if dtype is not None: kwargs["dtype"] = dtype
    sc = StaticCache(config, max_batch_size, max_cache_len, **kwargs)
    sc.key_cache, sc.value_cache = children
    return sc

register_pytree_node(StaticCache, _flatten_static_cache, _unflatten_static_cache)

The generation function uses prefill (process full prompt) then per-token decode with the cache and a tqdm progress bar:

from tqdm.auto import tqdm

def generate_response(model, tokenizer, instruction, device, max_new_tokens=100):
    messages = [{"role": "user", "content": instruction}]
    prompt = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
    input_ids = tokenizer(prompt, return_tensors="pt")["input_ids"].to(device)
    seq_len = input_ids.shape[1]

    kv = StaticCache(config=model.config, max_batch_size=1,
                     max_cache_len=seq_len + max_new_tokens,
                     device=device, dtype=torch.bfloat16)
    pos = torch.arange(seq_len, device=device)

    model.eval()
    with torch.no_grad():
        # Prefill: process full prompt, populate cache
        logits, kv = model(input_ids, cache_position=pos, past_key_values=kv,
                           return_dict=False, use_cache=True)
        tok = torch.argmax(logits[:, -1], dim=-1)[:, None]
        generated = [tok[:, 0].item()]
        pos = torch.tensor([seq_len], device=device)

        # Decode: one token at a time using cached keys/values
        for _ in tqdm(range(max_new_tokens - 1), desc="Generating", leave=False):
            logits, kv = model(tok, cache_position=pos, past_key_values=kv,
                               return_dict=False, use_cache=True)
            tok = torch.argmax(logits[:, -1], dim=-1)[:, None]
            tid = tok[:, 0].item()
            if tid == tokenizer.eos_token_id:
                break
            generated.append(tid)
            pos += 1

    model.train()
    return tokenizer.decode(generated, skip_special_tokens=True)

Step 4: Set Up Functional Training

This is where torchax diverges from standard PyTorch. We separate the model, create an optax optimizer, and compose everything into a JIT-compiled training step.

Separate params and buffers

import optax
import torchax.train

params = {n: p for n, p in model.named_parameters() if p.requires_grad}
buffers = dict(model.named_buffers())
frozen_params = {n: p for n, p in model.named_parameters() if not p.requires_grad}
buffers.update(frozen_params)

Create the optimizer

schedule = optax.warmup_cosine_decay_schedule(
    init_value=0.0, peak_value=1e-4, warmup_steps=50, decay_steps=500
)
optimizer = optax.chain(
    optax.clip_by_global_norm(1.0),
    optax.adamw(learning_rate=schedule, weight_decay=0.01),
)
opt_state = tx.interop.call_jax(optimizer.init, params)

Note tx.interop.call_jax — this bridges optax's JAX calls with torchax tensors.

Define model_fn and loss_fn

def model_fn(weights, buffers, batch):
    """Stateless forward pass using functional_call."""
    return torch.func.functional_call(
        model, {**weights, **buffers}, args=(), kwargs=batch
    )

def loss_fn(model_output, labels):
    """Extract loss from HuggingFace model output."""
    return model_output.loss

torch.func.functional_call runs the model as a pure function — no hidden state, just inputs and outputs. This is what enables JAX to trace and compile it.

Compose into a training step

step_fn = tx.train.make_train_step(model_fn, loss_fn, optimizer)

That single line creates a function that does: forward pass → loss computation → gradient calculation → optimizer update — all compiled into one XLA program.

Step 5: The Training Loop

import time
from tqdm.auto import tqdm

torch.manual_seed(42)
train_losses = []
start_time = time.time()

for epoch in range(1):
    pbar = tqdm(enumerate(train_dataloader), total=len(train_dataloader))
    for step, batch in pbar:
        # Drop attention_mask — Gemma's sliding window attention produces NaN with
        # padded masks on torchax/JAX. Labels already mask padding with -100.
        batch = {k: v.to(device) for k, v in batch.items() if k != "attention_mask"}

        loss, params, opt_state = step_fn(
            params, buffers, opt_state, batch, batch["labels"]
        )

        train_losses.append(loss.item())
        pbar.set_postfix({"loss": f"{loss.item():.4f}"})

elapsed = time.time() - start_time
print(f"Training complete! {len(train_losses)} steps in {elapsed:.0f}s")

What to expect:

Step 1: ~30-60 seconds (JAX compiles the entire training step)
Steps 2+: ~1-3 seconds each (running the compiled program)
Total: ~20-40 minutes for 2000 samples with LoRA on free Colab TPU

The first step is slow because JAX traces through the entire model, loss computation, gradient calculation, and optimizer update — then compiles it all into a single optimized XLA program. Every subsequent step reuses this compiled program.

Step 6: Evaluate the Improvement

After training, we compare against our baseline:

# Load trained params back into model
with torch.no_grad():
    for name, param in params.items():
        parts = name.split(".")
        obj = model
        for part in parts[:-1]:
            obj = getattr(obj, part)
        setattr(obj, parts[-1], torch.nn.Parameter(param))

final_loss, final_ppl = evaluate_loss(model, eval_dataloader, device)

print(f"{'Metric':<20} {'Before':>10} {'After':>10}")
print(f"{'Loss':<20} {baseline_loss:>10.4f} {final_loss:>10.4f}")
print(f"{'Perplexity':<20} {baseline_ppl:>10.2f} {final_ppl:>10.2f}")

You should see loss decrease and perplexity improve after training. The qualitative comparison (generated responses before vs. after) is even more telling — the fine-tuned model produces more focused, instruction-following responses.

Step 7: Save and Reload

Save

Convert JAX arrays back to CPU tensors and save using HuggingFace's standard format:

import numpy as np

save_dir = "./fine_tuned_model"

with torch.no_grad():
    cpu_state_dict = {
        name: torch.tensor(np.array(p)).contiguous()
        for name, p in params.items()
    }
    # safe_serialization=False avoids a safetensors/torchax C-extension conflict on reload
    model.save_pretrained(save_dir, state_dict=cpu_state_dict, safe_serialization=False)

tokenizer.save_pretrained(save_dir)

For LoRA, this saves only the tiny adapter weights (~20MB). For full fine-tuning, it saves the entire model (~4GB).

Reload

with tx.disable_temporarily():
    # For LoRA: load base model + adapters separately
    reloaded_model = transformers.AutoModelForCausalLM.from_pretrained(
        MODEL_NAME, torch_dtype=torch.bfloat16
    )
    # torch_device="cpu" forces PEFT to load adapter weights on CPU,
    # avoiding a safetensors/torchax C-extension conflict.
    reloaded_model = peft.PeftModel.from_pretrained(reloaded_model, save_dir, torch_device="cpu")

reloaded_model.to(device)
reloaded_model.eval()

The pattern is the same as loading: disable torchax, load on CPU, then move to JAX. For LoRA models, you load the base model first, then attach the saved adapters with PeftModel.from_pretrained(). The torch_device="cpu" ensures PEFT loads weights through PyTorch's standard path rather than safetensors' C extension, which conflicts with torchax.

Full Fine-Tuning: When LoRA Is Not Enough

The notebook supports full fine-tuning by changing one setting:

TRAINING_MODE = "full"

This trains all parameters instead of just the LoRA adapters. The trade-off is much higher memory usage. To make it fit on free Colab TPU:

AdaFactor optimizer — uses ~50% less memory than AdamW (stores only row/column statistics instead of per-parameter moments)
Reduced sequence length — MAX_SEQ_LEN = 256 halves activation memory
Smaller batch size — BATCH_SIZE = 1 with higher gradient accumulation steps

USE_ADAFACTOR = True
USE_GRADIENT_CHECKPOINTING = True

if TRAINING_MODE == "full" and USE_ADAFACTOR:
    optimizer = optax.chain(
        optax.clip_by_global_norm(1.0),
        optax.adafactor(learning_rate=schedule),
    )
else:
    optimizer = optax.chain(
        optax.clip_by_global_norm(1.0),
        optax.adamw(learning_rate=schedule, weight_decay=0.01),
    )

Full fine-tuning gives a higher quality ceiling but LoRA gets you 90%+ of the way with a fraction of the compute.

Troubleshooting

Error	Cause	Fix
`OutOfMemoryError`	Model + optimizer too large	Switch to LoRA, reduce `BATCH_SIZE` or `MAX_SEQ_LEN`
`TypeError: not a valid JAX type`	Custom HuggingFace type not registered	Register with `jax.tree_util.register_pytree_node()`
`Loss is NaN`	Numerical instability in bfloat16	1. Call `tx.enable_accuracy_mode()` before `tx.enable_globally()`. 2. Reduce LR (try 1e-4). 3. Set `lora_dropout=0.0`. 4. Add `optax.clip_by_global_norm(1.0)`.
`Slow first step`	Normal — JAX JIT compilation	Wait ~30-60s; subsequent steps are fast
`make_train_step error`	API mismatch	Update: `pip install -U torchax`

The Big Picture: Inference + Training

With the inference tutorial and this training tutorial, you now have the complete torchax story:

Run any HuggingFace model on TPU (model.to("jax"))
Benchmark with JIT compilation (10-100x speedup)
Fine-tune with LoRA or full training (make_train_step)
Save and reload for production inference

All using PyTorch code. No JAX rewrite needed.

Resources

Notebooks:
- Full training tutorial — all the code from this post, ready to run
- Training quickstart — same pipeline in ~10 cells
- Inference tutorial — Part 1 of this series
Libraries:
References:
- torchax PEFT LoRA example — the official example this tutorial builds on
- Han Qi's tutorial series — the original 3-part series on torchax + HuggingFace

Credits

Han Qi (@qihqi) — author of torchax, PEFT training example, and the original tutorial series
torchax team at Google — library development
HuggingFace — transformers, PEFT, and datasets ecosystem
Databricks — Dolly 15k dataset
JAX team at Google — JAX, XLA, and TPU support

Next-Generation Google Workspace Automation

Tanaike — Mon, 27 Apr 2026 01:52:43 +0000

A Comparative Study of Agentic Frameworks and Multi-Agent Orchestration

Abstract

The transition from passive chatbots to autonomous execution environments was cemented at Google Cloud Next '26 with the introduction of the Gemini Enterprise Agent Platform. This paper evaluates four cutting-edge AI agent methodologies for Google Workspace automation, developed by leading developers Martin Hawksey, Bruce Mcpherson, and Kanshi Tanaike. We deconstruct their structural approaches—CLI skill chaining, advanced emulation sandboxing, dynamic code generation, and A2A remote delegation—demonstrating how these community-driven innovations anticipated native Next '26 features like the official Agent Skills repository and Model Context Protocol (MCP) support. Building upon these foundations, we propose two novel frameworks: the Federated Context-Aware Routing Architecture (Federated CARA) for zero-trust, multi-cloud task routing, and the Self-Optimizing Tool Caching Network (SOTCN) to eliminate Tool Space Interference using dynamic semantic caching. This comparative synthesis maps existing and proposed models against Google's new enterprise standards, offering a scalable roadmap for secure, highly dynamic multi-agent orchestration.

1. Introduction

Historically, automating tasks within Google Workspace relied heavily on static, hardcoded macros defined via Google Apps Script (GAS) and rigidly scheduled cloud triggers. While highly effective for predictable workflows, this paradigm lacked the adaptability required for complex, context-dependent enterprise operations. The advent of Large Language Models (LLMs) catalyzed the transition toward the "Agentic Enterprise," wherein AI entities act as autonomous orchestration layers capable of interacting dynamically with vast API ecosystems. At Google Cloud Next '26, this shift was cemented through the introduction of Workspace Intelligence, a semantic unifying layer that allows agents to autonomously execute multi-step tasks across Gmail, Docs, Sheets, and Drive without manual context provisioning.

However, bridging LLM reasoning engines with Google Workspace APIs introduces profound architectural challenges, notably regarding execution latency, security perimeters, and Tool Space Interference (TSI). TSI—officially recognized by Google as "context bloat"—is a phenomenon where an agent's reasoning accuracy degrades, and token costs skyrocket, when its context window is overloaded with a massive library of predefined functions.

This paper analyzes four prominent, recently published developer methodologies that sought to solve these challenges before they were addressed natively. By evaluating these frameworks against Next '26 announcements like the GKE Agent Sandbox , native Agent Registry , and the Agent Gateway, we identify key strengths and limitations. Subsequently, we propose advanced hybrid frameworks—Federated CARA and SOTCN—tailored to leverage Google's new native security and orchestration layers for the next generation of highly secure, scalable enterprise deployment.

2. Architectural Analysis of Existing Methodologies

The automation of Google Workspace using AI agents is an emerging field characterized by highly divergent architectural philosophies. The following sections provide an exhaustive deconstruction of four primary paradigms.

2.1 Skill-Based Prototyping Using CLI Integrations (Martin Hawksey)

Ref: Exploring Workspace Intelligence Skills using the Workspace CLI and Gemini CLIs with Apps Script API Executables

Ref: gws-web-to-doc

Martin Hawksey’s project (gws-web-to-doc) demonstrates how discrete, legacy command-line tools can be wrapped into modular AI skills. By combining local Node.js execution with the Google Workspace CLI (gws) and remote GAS deployment, Hawksey creates a linear execution pipeline. For instance, in his "Web-to-Doc" workflow, local scripts extract web content, the CLI natively converts the Markdown to a Google Document, and an API Executable GAS script (resizer.gs) handles precise image formatting.

Primary Strength: Excellently bridges legacy scripting and modern LLM orchestration, making isolated tasks readily accessible to AI.

2.2 Local Natural Language Execution via Emulation (Bruce Mcpherson)

Ref: gas-fakes agent: local natural language requests against workspace resources

Ref: gf_agent - Google Apps Script Local Automation Agent

Bruce Mcpherson addresses iteration latency and cloud security through his gas-fakes-agent framework. By utilizing the gas-fakes emulation layer, Mcpherson enables an LLM to dynamically generate GAS syntax and execute it within a Node.js environment that can be run locally or containerized in any cloud platform. Because it uses Google APIs under the hood, standard network and API latencies still apply, and the files manipulated remain cloud-based just like native GAS. The framework is highly versatile—it can be deployed across multiple cloud platforms (aligning with the modern emphasis on sovereign clouds) and can operate and mix multiple backends, such as Microsoft OneDrive and Office files. Crucially, the gf_agent approach is made possible by continuous learning from over 10,000 tests that gas-fakes uses to ensure its consistency with live Apps Script. This foundation allows the agent to self-augment through continuous cyclical feedback as new methods are introduced.

Primary Strength: Advanced execution sandboxing and robust permission management. Its security paradigm emphasizes secure sandboxing rather than authentication per se. While it utilizes the same authentication mechanisms available to any OAuth2 protected app—such as Application Default Credentials (ADC), Domain Wide Delegation (DWD), and keyless workload identity federation—it uniquely takes care of the permission complications associated with them. Furthermore, its native compatibility with the Model Context Protocol (MCP) sets a standardized foundation for AI-to-tool interfacing.

2.3 Dynamic Tool Creation to Combat Tool Space Interference (Kanshi Tanaike)

Ref: Empowering Autonomous AI Agents through Dynamic Tool Creation

Ref: autonomous-google-workspace-agent

To solve the cognitive bottleneck of Tool Space Interference (TSI) in enterprise LLMs, Kanshi Tanaike’s autonomous-google-workspace-agent introduces a fully autonomous, self-healing multi-agent architecture. When faced with an edge case lacking a predefined solution, a Senior Orchestrator coordinates five sub-agents (Environment Checker, Script Writer, Script Executor, Script Uploader, and Summary Agent) to write, sandbox-test (using gas-fakes), deploy (via clasp), and execute custom tools in real-time.

Primary Strength: Fundamentally eliminates TSI by relying on dynamic tool generation rather than a saturated context window. It serves as a secure "kill switch" against reasoning drift by isolating untrusted code generation within a sandbox before cloud deployment.

2.4 Remote Subagent Integration via the A2A Protocol (Kanshi Tanaike)

Ref: Integrating Remote Subagents Built by Google Apps Script with Gemini CLI

Ref: gemini-cli-gas-a2a-subagents

In a subsequent approach (gemini-cli-gas-a2a-subagents), Tanaike solves TSI through remote delegation rather than dynamic generation. A primary LLM offloads a massive repository of over 160 established Workspace skills to a specialized Google Apps Script Web App using the Agent-to-Agent (A2A) protocol. Tanaike elegantly bypasses strict Google Cloud cross-domain (CORS) authentication hurdles by predefining "agent cards" locally within the Gemini CLI.

Primary Strength: Preserves the primary agent's reasoning stability without the compute overhead of writing new code, allowing frictionless access to massive legacy macro libraries.

3. Proposed Novel Methodologies for Advanced Workspace Automation

Based on the strengths and limitations of the analyzed frameworks, and aligning with the latest native paradigms introduced at Google Cloud Next '26, we propose two novel architectural approaches intended for advanced enterprise use cases.

3.1 Federated Context-Aware Routing Architecture (Federated CARA)

Concept: A zero-trust hybrid orchestration network that dynamically routes AI tasks based on a real-time assessment of data sensitivity, computational demand, and cross-platform interoperability requirements.
Architecture: A central LLM routing agent acts as a security triage engine. If a natural language prompt involves sensitive organizational data or requires orchestration across mixed backends (e.g., interacting simultaneously with Google Workspace and Microsoft OneDrive), the orchestrator routes the execution to an advanced sandboxed emulation layer. Synthesizing Mcpherson's gas-fakes approach, this layer utilizes keyless workload identity federation and Application Default Credentials (ADC) to securely manage complex permissions. It natively supports multi-cloud deployments—including sovereign clouds—ensuring that while external APIs are accessed under the hood, the execution environment itself remains strictly controlled and continuously validated through self-augmenting feedback loops. Conversely, if the task requires heavy bulk processing over established legacy macros, the execution is delegated to a remote A2A subagent (synthesizing Tanaike's Web App protocol).
Enterprise Value: Maximizes cross-platform versatility and infrastructure flexibility while enforcing strict compliance and data governance perimeters. By focusing on advanced execution sandboxing rather than relying solely on traditional authentication barriers, it securely bridges distinct enterprise ecosystems.

3.2 Self-Optimizing Tool Caching Network (SOTCN)

Concept: An advanced solution to Tool Space Interference (TSI) that bridges the gap between dynamic code creation, static remote delegation, and newly standardized enterprise skill registries.
Architecture: Instead of writing code from scratch (which incurs API latency) or loading 160+ tools simultaneously (which inevitably degrades LLM reasoning), the SOTCN utilizes a massive "cold storage" repository of pre-validated scripts. Crucially, this architecture is designed to integrate seamlessly with Google's newly announced official Agent Skills repository. By treating both officially published Agent Skills and custom-built Workspace scripts as modular assets, SOTCN acts as a dynamic curator. When a user issues a command, an ultra-fast semantic vector search identifies the top 3–5 most relevant skills. A local "Injection Agent" then dynamically injects only those specific functions into the primary LLM's active Model Context Protocol (MCP) context window for the duration of that specific session.
Enterprise Value: Eliminates TSI entirely by maintaining a pristine, minimal active context window. By leveraging both community-driven repositories and official Google Agent Skills, SOTCN avoids the latency and debugging failure rates of real-time code generation while effectively future-proofing enterprise deployments against evolving native ecosystem standards.

4. Comparative Analysis

The table below synthesizes the structural and functional nuances of the four original methodologies alongside our two newly proposed frameworks.

5. Discussion and Conclusion

The evolution of Google Workspace automation reflects a broader industry shift toward "Agentic" design. Hawksey’s foundational work establishes how legacy scripts can be seamlessly bridged to LLMs, preempting Google's recent Next '26 announcement of the official Agent Skills repository. Mcpherson's integration of the gas-fakes emulation layer combined with the Model Context Protocol (MCP) redefines enterprise security and interoperability. Rather than simply isolating execution, Mcpherson demonstrates how advanced sandboxing, managed via mechanisms like keyless workload identity federation, enables multi-cloud versatility (supporting sovereign clouds) and cross-platform backend integration (e.g., Microsoft OneDrive). Furthermore, powered by continuous learning from over 10,000 tests, this approach proves that agents can reliably self-augment through cyclical feedback. Tanaike pushes the envelope of scalability; his dual approaches to Tool Space Interference (TSI) demonstrate that AI systems must either possess the autonomy to self-generate capabilities or the communicative protocols (A2A) to delegate them.

The proposed frameworks, Federated CARA and SOTCN, represent the logical next steps in this evolution, deeply aligning with the latest native Google Cloud capabilities. In particular, the SOTCN methodology provides a powerful extension to Google's newly introduced Agent Skills paradigm by offering a semantic caching mechanism that programmatically eliminates context bloat while standardizing tool invocation. By optimizing for latency, context window preservation, multi-cloud versatility, and strict data compliance, these advanced methodologies outline a robust, future-proof roadmap for deploying enterprise-grade, autonomous AI coworkers that are as reliable as they are dynamic.

6. Summary

Evolution of Automation: Workspace automation has officially shifted from rigid Google Apps Script macros to the "Agentic Era," powered by the new Gemini Enterprise Agent Platform, which natively supports the building, scaling, and governance of autonomous agents.
Skill Chaining (Hawksey): Utilizes the Workspace CLI to combine local Node.js execution with remote GAS deployment. This foundational approach preempted Google's newly announced Agent Skills repository, which formalizes skills as compact, agent-first documentation to mitigate context bloat.
Local Sandboxing (Mcpherson): Employs the gas-fakes emulation layer and MCP to securely execute LLM-generated code locally or containerized in any cloud platform. This focus on secure isolation and standardized tooling is now mirrored at the enterprise level by Google's native MCP support and the highly secure GKE Agent Sandbox utilizing gVisor.
Dynamic Generation (Tanaike): Utilizes a sophisticated 5-agent orchestrator to write, sandbox-test, and cloud-deploy custom tools in real-time, effectively solving Tool Space Interference (TSI). This mirrors the capabilities of Google's newly announced Long-running agents, which autonomously execute multi-step workflows inside secure cloud sandboxes.
Remote Delegation (Tanaike): Leverages the A2A protocol to offload massive libraries of over 160 predefined skills to remote GAS Web Apps. This community-built solution directly anticipated Google's native A2A (Agent-to-Agent) Orchestration and Agent Registry, which now allow enterprise agents to natively discover and delegate tasks to one another.
Proposed Method 1 (Federated CARA): A zero-trust architecture that routes AI tasks to either containerized emulation or remote A2A subagents based on the data's security classification. This framework is perfectly positioned to integrate with the newly announced Agent Gateway and Agent Identity, natively enforcing IAM access control policies and guarding against data exfiltration.
Proposed Method 2 (SOTCN): A semantic caching network that stores predefined tools in "cold storage" and dynamically injects only the most relevant functions into the agent's active context window. This architecture enhances Google's new Agent Skills paradigm by programmatically eliminating context bloat without the latency of generative code writing.

7. Explanatory video

Multi-Agent A2A with the Agent Development Kit(ADK), AWS Lambda, and Gemini CLI

xbill — Sat, 25 Apr 2026 22:16:28 +0000

Leveraging the Google Agent Development Kit (ADK) and the underlying Gemini LLM to build Multi-Agent Applications with A2A protocol support using the Python programming language deployed to AWS Lambda.

Aren’t There a Billion Python ADK Demos?

Yes there are.

Python has traditionally been the main coding language for ML and AI tools. The goal of this article is to provide a multi-agent test bed for building, debugging, and deploying multi-agent applications.

Say It Ain’t So

So what is different about this lab compared to all the others out there?

This is one of the first deep dives into a Multi-Agent application leveraging the advanced tooling of Gemini CLI. The starting point for the demo was an existing Codelab- which was updated and re-engineered with Gemini CLI.

The original Codelab- is here:

Building a Multi-Agent System | Google Codelabs

Python Version Management

One of the downsides of the wide deployment of Python has been managing the language versions across platforms and maintaining a supported version.

The pyenv tool enables deploying consistent versions of Python:

GitHub - pyenv/pyenv: Simple Python version management

As of writing — the mainstream python version is 3.13. To validate your current Python:

python --version
Python 3.13.13

Amazon Lambda

AWS Lambda is a serverless, event-driven compute service that enables users to run code without provisioning or managing servers. With Lambda, developers can focus solely on their code (functions), while AWS handles all underlying infrastructure management, including capacity provisioning, automatic scaling, and operating system maintenance.

Full details are here:

Serverless Computing Service - Free AWS Lambda - AWS

Gemini CLI

If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:

npm install -g @google/gemini-cli

Testing the Gemini CLI Environment

Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:

▝▜▄ Gemini CLI v0.33.1
    ▝▜▄
   ▗▟▀ Logged in with Google /auth
  ▝▀ Gemini Code Assist Standard /upgrade no sandbox (see /docs) /model Auto (Gemini 3) | 239.8 MB

Node Version Management

Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:

GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Agent Development Kit

The Google Agent Development Kit (ADK) is an open-source, Python-based framework designed to streamline the creation, deployment, and orchestration of sophisticated, multi-agent AI systems. It treats agent development like software engineering, offering modularity, state management, and built-in tools (like Google Search) to build autonomous agents.

The ADK can be installed from here:

Agent Development Kit (ADK)

Agent Skills

Gemini CLI can be customized to work with ADK agents. Both an Agent Development MCP server, and specific Agent skills are available.

More details are here:

Agent Development Kit (ADK)

To get the Agent Skills in Gemini CLI:

> /skills list
Available Agent Skills:

and the ADK documentation:

> /mcp list
Configured MCP servers:
🟢 adk-docs-mcp (from adk-docs-ext) - Ready (2 tools)
  Tools:
  - mcp_adk-docs-mcp_fetch_docs
  - mcp_adk-docs-mcp_list_doc_sources

Where do I start?

The strategy for starting multi agent development is a incremental step by step approach.

First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.

Then, ADK Multi-Agent is built, debugged, and tested locally. Finally — the entire solution is deployed to AWS Lambda.

Setup the Basic Environment

At this point you should have a working Python environment and a working Gemini CLI installation. All of the relevant code examples and documentation is available in GitHub.

The next step is to clone the GitHub repository to your local environment:

cd ~
git clone https://github.com/xbill9/gemini-cli-aws
cd multi-lambda

Then run init2.sh from the cloned directory.

The script will attempt to determine your shell environment and set the correct variables:

source init2.sh

If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:

source set_env.sh

Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.

aws login --remote

Finally install the packages and dependencies:

make install

Verify The ADK Installation

To verify the setup, run the ADK CLI locally with the researcher agent:

xbill@penguin:~/gemini-cli-aws/multi-lambda/agents$ adk run researcher
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/authlib/_joserfc_helpers.py:8: AuthlibDeprecationWarning: authlib.jose module is deprecated, please use joserfc instead.
It will be compatible before version 2.0.0.
  from authlib.jose import ECKey
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
Log setup complete: /tmp/agents_log/agent.20260422_134822.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
{"asctime": "2026-04-22 13:48:23,011", "name": "root", "levelname": "INFO", "message": "Logging initialized for researcher", "filename": "logging_config.py", "lineno": 54, "service": "researcher", "log_level": "INFO"}
{"asctime": "2026-04-22 13:48:23,013", "name": "researcher.agent", "levelname": "INFO", "message": "Initialized researcher agent with model: gemini-2.5-flash", "filename": "agent.py", "lineno": 85}
{"asctime": "2026-04-22 13:48:23,015", "name": "google_adk.google.adk.cli.utils.envs", "levelname": "INFO", "message": "Loaded .env file for researcher at /home/xbill/gemini-cli-aws/multi-lambda/.env", "filename": "envs.py", "lineno": 83}
{"asctime": "2026-04-22 13:48:23,016", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Using per-agent session storage rooted at /home/xbill/gemini-cli-aws/multi-lambda/agents", "filename": "local_storage.py", "lineno": 84}
{"asctime": "2026-04-22 13:48:23,016", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Using file artifact service at /home/xbill/gemini-cli-aws/multi-lambda/agents/researcher/.adk/artifacts", "filename": "local_storage.py", "lineno": 110}
{"asctime": "2026-04-22 13:48:23,017", "name": "google_adk.google.adk.cli.utils.service_factory", "levelname": "INFO", "message": "Using in-memory memory service", "filename": "service_factory.py", "lineno": 266}
{"asctime": "2026-04-22 13:48:23,047", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Creating local session service at /home/xbill/gemini-cli-aws/multi-lambda/agents/researcher/.adk/session.db", "filename": "local_storage.py", "lineno": 60}
Running agent researcher, type exit to exit.
[user]:

Test The ADK Web Interface

This tests the ADK agent interactions with a browser:

xbill@penguin:~/gemini-cli-aws/multi-lambda/agents$ adk web --host 0.0.0.0
/home/xbill/.local/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
2026-04-12 16:43:14,152 - INFO - service_factory.py:266 - Using in-memory memory service
2026-04-12 16:43:14,153 - INFO - local_storage.py:84 - Using per-agent session storage rooted at /home/xbill/gemini-cli-aws/multi-eks/agents
2026-04-12 16:43:14,153 - INFO - local_storage.py:110 - Using file artifact service at /home/xbill/gemini-cli-aws/multi-eks/agents/.adk/artifacts
/home/xbill/.local/lib/python3.13/site-packages/google/adk/cli/fast_api.py:198: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.local/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
INFO: Started server process [32675]
INFO: Waiting for application startup.

Then use the web interface — either on the local interface 127.0.0.1 or the catch-all web interface 0.0.0.0 -depending on your environment:

Special note for Google Cloud Shell Deployments- add a CORS allow_origins configuration exemption to allow the ADK agent to run:

adk web --host 0.0.0.0 --allow_origins 'regex:.*'

Multi Agent Design

The multi-agent deployment consists of 5 agents:

Researcher
Judge
Orchestrator
Content Builder
Course Builder

For a detailed analysis of the multi-agent architecture- this article provides the background information:

Multi-Agent A2A with the Agent Development Kit(ADK), Cloud Run, and Gemini CLI

Running/Testing/Debugging Locally

The main Makefile has been extended with extensive targets for managing the agents on the local development environment.

The key targets include:

First check for local running agents:

xbill@penguin:~/gemini-cli-aws/multi-lambda$ make status
Checking status of locally running agents and servers...
--- Network Status ---
No services listening on expected ports (8000-8004, 5173).
--- Process Status ---
No matching processes found.

Then all the agents can be started together:

✦ The frontend has been built and all local services (Researcher, Judge, Content Builder, Orchestrator, App Backend, and Frontend dev server) have
  been started in the background.

   - Frontend: [http://localhost:5173](http://localhost:5173) (http://localhost:5173)
   - Backend: [http://localhost:8000](http://localhost:8000) (http://localhost:8000)

  Logs for each service are available in the project root: researcher.log, judge.log, content_builder.log, orchestrator.log, backend.log, and
  frontend.log.

Then connect to the front end locally:

And the entire agent system will run in the local environment:

Local Logging / Debugging

Gemini CLI has full access to the local agent logs for debugging and troubleshooting:

> review the local logs for the multi-agent run
✦ I will check run_local.sh and the project structure to determine where logs are stored or how they are generated.

This will verify the local operation of the code:

✦ The local logs confirm a successful multi-agent run for the topic "the history of the internet." Here is a summary of the execution flow:

* Orchestrator (orchestrator.log): Successfully managed the pipeline. It captured the topic, coordinated the Research-Judge loop, and escalated to
     content generation after the first iteration.
   * Researcher (researcher.log): Gathered approximately 9.2KB of research data using the google_search tool. It completed its task with a 200 OK
     response.
   * Judge (judge.log): Evaluated the findings and gave a "pass" status. The judge noted that the research was "comprehensive, accurate, and
     well-structured," making it an "excellent foundation for educational content."
   * Content Builder (content_builder.log): Successfully transformed the validated research into a structured Markdown course module and finished
     execution.
   * Backend & Frontend (backend.log, frontend.log): The FastAPI backend (port 8000) and Vite frontend (port 5173) are running and communicating with
     the orchestrator as expected.

Notable Observation:
   * A minor warning appeared in researcher.log: Researcher callback: 'response' not found or has no parts. However, this did not impact the
     successful completion of the research or the overall pipeline.

All services are currently active and logged at the DEBUG level as specified in run_local.sh.

Deploying to Amazon Lambda

The project level Makefile has targets for managing the Agent deployment to serverless endpoints. You can submit the build for Lamba deployment:

xbill@penguin:~/gemini-cli-aws/multi-lambda$ make deploy
chmod +x lambda/deploy-lambda.sh
./lambda/deploy-lambda.sh
Ensuring IAM role McpLambdaExecutionRole exists...
Logging in to Amazon ECR...

Once the containers are deployed- you can then get the endpoint:

xbill@penguin:~/gemini-cli-aws/multi-lambda$ make endpoint
https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/

xbill@penguin:~/gemini-cli-aws/multi-lambda$ make status
Course Creator Lambda Status:
-----------------------------------------------------
---------------------------------------------
| GetFunction |
+---------------------------------+---------+
| Name | Status |
+---------------------------------+---------+
| course-creator-course-builder | Active |
+---------------------------------+---------+
URL: https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
-------------------------------------------
| GetFunction |
+-------------------------------+---------+
| Name | Status |
+-------------------------------+---------+
| course-creator-orchestrator | Active |
+-------------------------------+---------+
URL: https://q5bciiujjktr6wris6tple6fra0yyrqc.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
-----------------------------------------
| GetFunction |
+----------------------------+----------+
| Name | Status |
+----------------------------+----------+
| course-creator-researcher | Active |
+----------------------------+----------+
URL: https://gfhdoxhiiznflcz2cdhc65z2eq0cwimd.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
------------------------------------
| GetFunction |
+-----------------------+----------+
| Name | Status |
+-----------------------+----------+
| course-creator-judge | Active |
+-----------------------+----------+
URL: https://kaen6rupkl5ph5kde2g6h7wgr40sirch.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
----------------------------------------------
| GetFunction |
+----------------------------------+---------+
| Name | Status |
+----------------------------------+---------+
| course-creator-content-builder | Active |
+----------------------------------+---------+
URL: https://k5wt4o6vrdao3w4zjiabszdeue0kauxp.lambda-url.us-east-1.on.aws/

The service will be visible in the AWS console:

And the entire system can be tested:

xbill@penguin:~/gemini-cli-aws/multi-lambda$ make e2e-test-lambda
Fetching Lambda endpoint...
make[1]: Entering directory '/home/xbill/gemini-cli-aws/multi-lambda'
Running end-to-end test against https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/...
Temporary JSON file content: {"message": "Create a short course about the history of the internet", "user_id": "e2e_test_user"}
Executing: curl -s -X POST https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/api/chat_stream -H "Content-Type: application/json" -d @/tmp/tmp.vmxl0Dsf88 --no-buffer
{"type": "progress", "text": "\ud83d\ude80 Connected to backend, starting research..."}
{"type": "progress", "text": "\ud83d\ude80 Starting the course creation pipeline..."}
{"type": "progress", "text": "\ud83d\udd0d Research is starting..."}
{"type": "progress", "text": "\ud83d\udd0d Researcher is gathering information..."}
{"type": "progress", "text": "\u2696\ufe0f Judge is evaluating findings..."}
{"type": "progress", "text": "\u2696\ufe0f Judge is evaluating findings..."}
{"type": "progress", "text": "\u270d\ufe0f Building the final course content..."}

Running the Web Interface

Start a connection to the deployed app:

https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/

Then connect to the app :

Then use online course generator:

Final Gemini CLI Code Review

As a final step — Gemini CLI was used for a full code review of the project:

✦ The multi-lambda project is a well-engineered, distributed multi-agent system that effectively leverages the
  Google Agent Development Kit (ADK) and the A2A protocol within an AWS Lambda environment. The architecture is
  modular, resilient, and optimized for streaming AI interactions.

  Key Strengths

   * Robust Orchestration: The use of SequentialAgent and LoopAgent in agents/orchestrator/agent.py creates a
     sophisticated Research-Judge pipeline. Custom components like StateCapturer and EscalationChecker provide
     fine-grained control over the agent loop and state persistence.
   * Infrastructure-Aware A2A: The middleware in shared/a2a_utils.py dynamically rewrites agent card URLs based on
     x-forwarded-* headers, a critical feature for services running behind proxies or as Lambda Function URLs.
   * Intelligent Agent Callbacks: Each sub-agent (researcher, judge, content_builder) utilizes
     before_agent_callback to sanitize inputs and recover topics/findings from session history. This makes the
     agents highly resilient to the "noise" of accumulated conversation history.
   * Unified Deployment: The project employs a single Docker image (using the aws-lambda-adapter) for all
     services. The deploy-lambda.sh script automates the complex task of deploying five distinct services,
     managing their Function URLs, and wiring them together via environment variables.
   * Modern Python Stack: The use of Python 3.13 and uvicorn ensures high performance, while the gateway's
     merge_strings logic gracefully handles the complexities of streaming deduplication.

  Observations & Recommendations

   * Session Persistence: Currently, the system appears to use ADK's default in-memory session storage. In a
     Lambda environment, sessions may be lost across cold starts or scaling events. For production use,
     integrating a persistent session store (e.g., DynamoDB or Redis) via the session_service_uri option is
     recommended.
   * Security: Inter-agent communication currently bypasses IAM authentication (using NONE auth type) and relies
     on the authenticated_httpx.py bypass logic. While acceptable for a demo, production environments should
     leverage AWS IAM or Google Identity Tokens for service-to-service authorization.
   * State Management: The orchestrator's StateCapturer effectively "syncs" findings from the event stream into
     the session state. This is a clever approach to distributed state management, ensuring the Orchestrator
     remains the source of truth even when sub-agents are remote.

  Overall, this is a sophisticated implementation that successfully bridges Google's AI agent framework with AWS's
  serverless infrastructure.

Summary

The Agent Development Kit (ADK) was used to build a multi-agent system with A2A support using the Gemini Flash LLM Model. This application was tested locally with Gemini CLI and then deployed to AWS Lambda. Finally, Gemini CLI was used for a complete project code review.

Instructions. Skills. Tools. How Google Embedded Skills Into Every Layer of Its Agent Stack

Sonika Janagill — Sat, 25 Apr 2026 18:30:55 +0000

Agent Skills Adoption

Prompt Bloat has a name and a fix. Skills are now load-bearing across Google’s agent stack: from on-device Gemma 4 to enterprise Gemini, from coding assistants to the official Cloud repository

It usually starts with good intentions.

A team builds an agent. It works, mostly, until it misses a naming convention or ignores an approval workflow. So, you add a paragraph to the system prompt. Then another to handle an edge case. Then three more for stakeholder rules.

Six months in, the prompt is a 4,000-word monolith. Nobody knows what is still relevant, but everyone is afraid to touch it. The agent is now slower and less reliable than when it had 200 words of instructions. Every “fix” risks a regression.

This is the reality of Prompt Bloat : the silent technical debt of enterprise AI.

This has been the enterprise agent bottleneck for two years. I recently spoke with a practitioner managing 100+ production skills; they described a marketing auditor that loaded 15,000 tokens of instructions on every invocation. It left almost no context window for the actual content being audited. The agent “worked,” but it was drowning in its own instructions. The output was mediocre because the reasoning tax was too high.

At Google Cloud Next ’26, Google productized the solution: Skills.

The core thesis is that Skills are the “settled” abstraction for agentic workflows. They occupy the vital middle ground:

Better than Prompts: Because they are reusable and persistent.
Lighter than Fine-tuning: Because they iterate at the speed of business logic.
Smarter than RAG: Because they are active expertise, not just passive retrieval.
Richer than Tools: Because they encode “how” and “why,” not just “do.”

Skills are small, named, dynamically loaded units of expertise. With Google shipping them across three distinct surfaces, the industry debate over what to call this pattern is over. The real question begins: who is responsible for governing yours?

The Pattern: How Google Embeds Open Abstractions

Google’s shipping strategy follows a consistent “Adoption Flywheel” : observe the abstractions the developer community is independently building, adopt the open standard, and embed it as a first-class primitive across the stack.

Recognising this pattern tells you exactly where to invest your time:

MCP. Anthropic released the Model Context Protocol as a lightweight standard for connecting agents to external tools and data sources. Google’s response was not to build a competing standard. Within months, managed MCP servers were shipping for Cloud Run, BigQuery, AlloyDB, Cloud SQL, and the full Workspace suite. Google adopted the standard and built infrastructure around it.

A2A. Google co-authored the Agent-to-Agent protocol for cross-agent communication, then handed governance to the Linux Foundation’s Agentic AI Foundation rather than keeping it proprietary. It now has 150 organisations in production.

Skills. The ecosystem independently discovered that agents need loadable expertise. Google productized it, kept the open agentskills.io name, and moved it from a “sidebar feature” to “load-bearing” infrastructure.

The practical implication: When Google adopts an open abstraction, the format stabilises, but the complexity shifts. You can stop worrying about the file format and start worrying about the governance. Invest in the abstraction, not the vendor-specific implementation.

Three Surfaces Where Skills Have Now Shipped

1. Gemini Enterprise: Skills as a First-Class Product Feature

The announcement of Skills inside the Gemini Enterprise marks a shift from “Linear Context Loading” to “Dynamic Skill Dispatching”.

The technical cost of large system prompts is the “Lost in the Middle” phenomenon. When irrelevant instructions saturate the context window, reasoning degrades. The model spends so much of its “cognitive overhead” parsing the prompt that it has little capacity left for the actual task.

Skills solve this via Progressive Disclosure in three stages:

Discovery: The agent knows the skill exists via a minimal metadata footprint.
Activation: The full instructions load only when the task requires that specific expertise.
Execution: The agent follows the structured Markdown and templates to complete the work.

By preserving the reasoning budget for the task rather than the instructions, you get the breadth of a deeply specialised agent without the context tax on every invocation.

For enterprise teams, Skills are not a standalone feature; they are part of a coherent operating model. They sit alongside Agent Designer , secure execution sandboxes, and a central Inbox for monitoring activity. This is Google providing the infrastructure to manage agents at an organisational scale, rather than just building better chatbots.

2. Agents CLI: Skills for Your Coding Assistant

The second surface is where the engineering actually happens: the terminal and their coding assistant. Polong Lin, Google’s Staff DevRel Manager for ADK, has positioned the Agents CLI as the bridge between a cool demo and a production-ready AI workforce. It is pre-GA and available now:

# Preferred: uvx handles an ephemeral environment
uvx google-agents-cli setup 

# Alternative: install specific skills 
npx skills add google/agents-cli

The Agents CLI turns assistants like Claude Code or Gemini CLI into ADK specialists. At launch, seven “Workflow Skills” ship out of the box to handle the end-to-end development lifecycle:

What this means in practice: when you invoke google-agents-cli-scaffold, inside Claude Code, your coding assistant loads a skill that carries Google's conventions for ADK project structure, component naming, and integration patterns. It does not need to guess or hallucinate ADK-specific idioms. The expertise is encoded in the skill. The skills work immediately.

What takes longer is discipline: knowing when to write a custom skill versus when to extend a system prompt, and agreeing on that line across your team.

The real breakthrough, however, is the Official Agent Skills Repository: github.com/google/skills. Thirteen skills at launch, covering the most-used Google Cloud products and architectural concerns:

Product skills: AlloyDB, BigQuery, Cloud Run, Cloud SQL, Firebase, Gemini API, GKE
Well-Architected Pillar skills: Security, Reliability, Cost Optimisation
Recipe skills: Authentication, Onboarding, Network Observability

npx skills install github.com/google/skills

These are agent-first documentation: compact, grounded expertise written for agents to consume, not humans to read. Accurate terminal commands. No hallucinated API calls. No outdated SDK syntax. The Well-Architected Pillar skills are particularly notable: they encode Google’s architectural judgement as loadable expertise, not a 200-page PDF that nobody reads.

The third surface is the most unexpected, and the most revealing about where this is heading.

Google AI Edge Gallery, available on iOS and Android, allows you to build and experiment with AI experiences that run entirely on-device. At Next ’26, Google announced the launch of Agent Skills: one of the first applications to run multi-step, autonomous agentic workflows entirely on-device. Powered by Gemma 4, Agent Skills can augment the knowledge base, enabling Gemma 4 to access information beyond its initial training data using skills.

The Gemma 4 edge variants (E2B and E4B) run under 1.5GB of RAM on mid-range to flagship devices. The LiteRT-LM runtime processes 4,000 tokens across two Agent Skills in under three seconds. The model decides autonomously which of its available tools to invoke, in which sequence, and composes the response entirely on-device.

The critical detail here is the format. The skill powering the Gallery is not a proprietary Google file, it is the SKILL.md format from agentskills.io.

This creates a massive architectural implication for the enterprise. You can build a custom skill on a phone, test it offline, and deploy the exact same file to a cloud-hosted Gemini 3.1 instance on Vertex AI. The Skill has become the portable container for cognition: “Docker for Prompts.” No other stack offers that path right now.

The Convergence: This Is Not Coincidence

Three surfaces. Three implementations of the same abstraction. And the underlying format is converging on something that started at Anthropic. When you see the same abstraction ship across a web app, a CLI tool, and a mobile runtime simultaneously, it is no longer a “feature.” It is a protocol.

The Day 2 developer keynote demo built a planning agent using ADK, MCP servers, and Agent Runtime, and described what the agent needed in three words: Instructions, Skills, and Tools.

Agent Registry reinforces this. Agent Registry maintains a central library of approved tools, indexing every internal agent, tool, and skill. That is governance infrastructure, not just a catalogue. When skills are indexed by Agent Registry, the “which skill was loaded?” accountability question I raised earlier has a concrete answer at the platform level.

It also helps to see where Skills sit relative to the other layers of the 2026 agent stack:

Skills and other layers of the agent stack

Each layer solves a different problem. The mistake most enterprise teams make is trying to solve the Skills (logic and process) problem with more RAG (more data). Google’s implementation across these three surfaces forces a much-needed discipline: keep your tools mechanical, your data accessible, and your expertise modular.

This is what protocol convergence looks like before the formal standard exists. The ecosystem finds the right shape. Then the spec follows. MCP went through this in 2024. A2A went through this in 2025. Skills are going through it now.

The practical takeaway: invest in the abstraction regardless of which vendor surface you build on first. The format will stabilise. The Skills catalogue you build this year will not be obsolete when the spec lands.

I wrote about the governance side of this challenge before Google named it, in “The Skills Explosion Is Here. Enterprise Governance Isn’t.” The moment I described there, where a developer drops a GitHub link to 100+ community skills and forty reaction emojis appear in Slack, arrives faster when three surfaces of Google’s stack ship Skills simultaneously.

The Enterprise Reality

For the past year, our core challenge hasn’t been selecting models or frameworks. It has been: How do we make individual experimentation compatible with organisational standards?

The tension is genuine. A developer working on a client campaign in Berlin has domain context that a platform team in London cannot anticipate. If skills are locked down centrally, that contextual expertise cannot reach the agent. If skills are entirely uncontrolled, you cannot audit what your agents are doing or ensure quality across client deliverables.

Google’s architecture addresses this through a Layered Composition Model:

Organisation Level : Global standards, brand voice, and compliance rules (managed via Gemini Enterprise).
Project Level : Client-specific conventions and workflow patterns (managed via Agent Registry).
Personal Level : Individual experimentation and localised hacks (managed via Agents CLI).

This stack allows these layers to compose, but it doesn’t yet solve the governance challenge sitting above the architecture. We still have to answer: Which skills are deprecated? Who owns the versioning when the underlying model changes? How do we evaluate a skill’s reliability before it reaches a production agent?

The infrastructure is here. Now, the governance tooling must catch up to the adoption rate.

Three Open Questions for the Post-Launch Reality

Skills vs. MCP tools: when is each right?

Tools are mechanical; Skills are cognitive.

Tools are stateless and specific: “Call this API, return this schema.”
Skills carry instructions, conventions, and internal logic.

The Heuristic: If it’s a single function call, it’s a tool. If it requires the agent to reason about sequencing, error handling, or escalation, it’s a skill. In agentic commerce, an API call to update a product attribute is a tool. Knowing when an attribute is missing, how to verify its quality, and when to escalate to a human is a skill.

How do you version a skill when the underlying model changes?

A skill written for Gemini 2.0 may behave differently under Gemini 3.1. The instructions are identical; the model’s interpretation is not. This is the least-solved governance problem in the ecosystem. Treat model upgrades as potential regressions. Use the google-agents-cli-eval skill to run benchmarks against your catalogue before promoting a new model to production. I expect "Pinned Skills" -expertise locked to a validated model version-to become a standard enterprise requirement.

Who owns the skill library in your organisation?

The tempting answer is “the platform team,” but that doesn’t scale. Ownership should follow the domain:

Foundational Skills: (Formatting, code patterns) belong to the Platform Team.
Workflow Skills: (Jira conventions, onboarding) belong to Domain Owners.
Personal Skills: Belong to the Individual until they are contributed upstream.

Ownership is accountability. When an agent fails, “Which skill was loaded?” needs a traceable answer. Agent Registry (announced at Next ’26) provides the platform-level index, but you must build owner attribution into the skill definition itself.

The “Hidden” Problem: Skill Collision : As skill catalogues exceed 50+ skills, descriptions will inevitably overlap. The agent’s router will pick the wrong one, leading to subtle, high-stakes errors. Forward-looking teams are already building Skill Leaderboards to track success rates across model iterations and catch these collisions before they reach the client.

What to Do Next!

The Skills abstraction is now shipped, named, and available across three Google surfaces. The infrastructure question is largely settled. What remains is the governance question.

If your team has agents in production, Audit the knowledge your agents currently load. If expertise is buried in 4,000-word system prompts with no clear ownership, use Skills to decompose that monolith into maintainable, versioned units. Move from “Prompt Engineering” to “Skill Architecture.”

If your team is building new agents now: Start with the Agents CLI. Use uvx google-agents-cli setup to bootstrap your first ADK agent and explore the bundled workflow skills. Then, install product-specific expertise from the official Agent Skills repository: npx skills install github.com/google/skills Learn the pattern with these "training wheels" before you are tasked with maintaining a production fleet of 40+ custom skills.

If you are thinking about the enterprise governance layer: Review my earlier analysis on the security and governance challenge. covers the vulnerability data from January 2026 (one in four public skills contains at least one vulnerability), the three-tier classification model for external skills (Green/Amber/Red), and the progressive disclosure pattern that prevents context from drowning your agents.

Google’s launch of Agent Registry makes these challenges visible, but it doesn’t solve them for you. The registry provides the index, but your team must provide the policy.

The governance conversation starts now. Your skills catalogue, and the rigour with which you govern it, will define the quality floor of every agent your team ships.

Sonika Janagill is a Google Developer Expert in Cloud AI & Google Cloud, Lead Backend Engineer at VML, and Data/MLOps Engineer at WPP Media. She writes about agentic systems, MLOps, and enterprise AI at sonikajanagill.com.

References and further reading

Level Up Your Agents: Announcing Google’s Official Skills Repository — Google Cloud Blog, Megan O’Keefe, 22 April 2026
github.com/google/skills — Official Google Agent Skills repository (13 skills at launch)
Developers guide to building ADK agents with skills — Google Developers Blog, April 2026
Agents CLI — ADK workflow skills for coding assistants
The Skills Explosion Is Here. Enterprise Governance Isn’t. — Sonika Janagill, March 2026
Google AI Edge Gallery — Gemma 4 Agent Skills — Google Developers Blog, April 2026

Originally published at https://sonikajanagill.com.

Build and Deploy to Google Cloud with Antigravity: The Era of Agent-First Development

Gbemisola Esho — Fri, 24 Apr 2026 15:26:04 +0000

The landscape of software development is undergoing a seismic shift from simple chat interfaces to autonomous agents capable of planning, executing, and refining complex workflows. Leading this charge is Google Antigravity, an agentic development platform that evolves the traditional IDE into a mission control center for an agent-first era.

Unlike standard coding assistants that merely autocomplete lines, Antigravity functions as an autonomous actor that can design, build, and deploy entire systems with minimal human intervention.

The Mission: An Event-Driven Document Pipeline

To see Antigravity in action, we can look at the creation of a serverless, event-driven document processing pipeline on Google Cloud. The architecture involves:

Ingestion: Files uploaded to a Google Cloud Storage (GCS) bucket.
Trigger: Uploads firing a Pub/Sub message.
Processor: A Cloud Run service (Python/Flask) that extracts metadata and processes files using Gemini on Vertex AI.
Storage: Streaming the results (tags, word counts, filenames) into BigQuery.

Development in Antigravity doesn't start with code; it starts with a Mission. In the Agent Manager, developers use the Playground to provide high-level prompts. Antigravity excels at planning complex systems before a single line is written.

A critical feature is the Review Policy. By setting artifacts to "Asks for Review," you ensure the agent presents its logic for approval before execution, fostering trust and maintaining human-in-the-loop control.

Phase 2: Autonomous Code & Infrastructure Generation

Once the plan is approved, Antigravity generates all necessary artifacts:
Infrastructure as Code: A setup.sh script to enable APIs (Cloud Run, Pub/Sub, BigQuery) and provision resources.
Application Code: A Python-based main.py, a Dockerfile, and a requirements.txt.
Deployment: The agent handles building the container image and deploying the Cloud Run service automatically.

Phase 3: Verification via Artifacts, Not Logs
The most tedious part of delegation is verification. Antigravity solves this by moving away from raw logs to Artifacts - tangible deliverables like task lists, implementation plans, and Walkthroughs.
The agent proactively verifies the deployment by uploading a test file to GCS and running SQL queries in BigQuery to ensure the data was processed correctly. You can review these results in the Walkthrough artifact, which summarizes every change and result at a glance

To verify the application really works you can test It creates a test artifact (test.txt) and wants to upload it to Google Cloud Storage bucket. Click on Accept to go ahead.
If you want to run further tests on your own, you can try to upload a sample file to the Cloud Storage bucket:

gcloud storage cp .txt gs: // doc-ingestion-{project-id}

Extend the Application

Add a Frontend: Generate a Streamlit or Flask web app to visualize BigQuery data.
Integrate Real AI: Swap "simulated" logic for real Gemini-powered document classification and translation.
Enhance Security: Move sensitive configurations to Secret Manager or implement Dead Letter Queues (DLQ) for robust error handling.

Google Antigravity represents a shift toward a higher, task-oriented level of engineering. By combining an AI-powered editor with a dedicated agent workspace, it allows developers to focus on the "what" while the agent handles the "how," turning abstract ideas into live, verified cloud applications in minutes.
For your step to step learning visit the Build and Deploy to Google Cloud with Antigravity codelab for more.

Empowering Autonomous AI Agents through Dynamic Tool Creation

Tanaike — Fri, 24 Apr 2026 07:36:01 +0000

Abstract

Welcome to the Agentic Enterprise era. This article explores a paradigm shift in generative AI workflows by introducing an autonomous agent capable of dynamically creating, testing, and executing original tools. Utilizing Google Apps Script, Node.js emulation, and multi-agent orchestration, this architecture overcomes traditional limitations, enabling highly adaptable task execution.

Introduction

At Google Cloud Next 2026, a clear mandate was delivered: the era of generative AI as a passive assistant is over. We have entered the age of the Agentic Enterprise, where AI has transitioned from a software tool you deploy into an autonomous coworker you onboard. This identity shift is staggering. With models processing over 16 billion tokens per minute via direct API use, we are witnessing an industrial-scale migration toward autonomous workflows. In this new ecosystem, Workspace Intelligence eliminates tab-hopping, allowing users to seamlessly query across Google Drive, Gmail, and third-party platforms. Data has transformed from a reactive archive into a "System of Action," driven by Deep Research Agents that bridge structured and unstructured data to prevent hallucinations.

However, this massive scale introduces new vulnerabilities and operational bottlenecks. As organizations adopt these highly autonomous coworkers to execute a wide variety of tasks, a vast multitude of tools is required. Yet, as the number of available tools in a Model Context Protocol (MCP) server increases, Large Language Models (LLMs) face a critical issue: inference accuracy and tool selection reliability significantly degrade. Researchers refer to this phenomenon as "Tool Space Interference" (TSI). Ref When an LLM's context window becomes saturated with excessive tool definitions, semantic overlaps and irrelevant metadata hinder decision-making. Current technical guidelines recommend a "soft limit" of approximately 20 functions to maintain high accuracy. Exceeding this threshold often leads to increased hallucinations and failures in executing complex instructions.

To address this, I previously published the article "Nexus-MCP: A Unified Gateway for Scalable and Deterministic MCP Server Aggregation." Ref In that piece, I introduced Nexus-MCP, a concept resolving Tool Space Interference by aggregating multiple MCP servers into a single deterministic gateway. Yet, even with this optimized architecture, a hard limit is eventually reached when attempting to execute an increasingly diverse array of edge-case tasks.

Furthermore, relying strictly on static tools presents a severe security risk. The 2026 summit highlighted the emergence of machine-speed, "Living off the Land" AI attacks, where internal AI CLI tools are hijacked by rogue processes. Treating AI simply as software leaves systems vulnerable; they must be managed as identities with strict minimum privileges, cryptographic IDs, and robust "Kill Switches" to prevent reasoning drift from turning agents into digital predators.

This article tackles both the TSI limitation and the security imperative directly by building an agent that dynamically creates, safely tests, and executes original scripts to process varied tasks on the fly. When an AI encounters an edge-case task lacking a pre-existing tool, a true paradigm shift occurs if the AI can automatically generate the exact tools it needs in real-time. By dynamically generating code and executing it in a secure, least-privilege sandbox, we protect the enterprise from unverified execution paths while expanding the spectrum of successfully executable tasks exponentially. I have previously explored this groundbreaking concept in the following articles:

In those articles, I demonstrated how tools could be dynamically created, safely executed in a sandbox, and thoroughly evaluated. Ref The execution results were retrieved using gas-fakes, a powerful emulation layer that allows Google Apps Script (GAS) projects to run natively on Node.js, effectively acting as an MCP server. We have advanced gas-fakes into the robust gas-fakes CLI. Simultaneously, deploying specialized AI agents has become an industry standard. For instance, the Gemini CLI can now seamlessly orchestrate these AI agents as subagents to handle complex, multi-step workflows.

Recently, I also published a comprehensive guide, "Orchestrating Agents via ADK for TypeScript and Gemini CLI."Ref I detailed practical scaffolding patterns, sophisticated multi-agent coordination strategies, and seamless integration techniques for deploying remote subagents within the Gemini CLI ecosystem. The architectural concepts established in that article serve as the foundational blueprint for developing the advanced agent system discussed here.

Specifically, I have engineered a robust AI agent equipped with a multi-agent framework designed to handle the entire lifecycle of a tool: writing the code, executing the script, validating the output, and summarizing the final results. I rigorously tested this framework as a subagent orchestrated by the Gemini CLI. For the tool's programming language, I selected Google Apps Script. While generative AI is often equipped with code interpreters capable of executing Python, I chose Google Apps Script because it is a low-code language featuring native integration with Google Workspace APIs, enabling seamless cloud automation. Ref For the execution platform, I utilized gas-fakes to ensure rapid, secure, and local runtime capabilities. Ref Looking ahead, I speculate that AI will eventually generate and execute tasks using entirely novel programming languages—languages highly optimized for AI comprehension, even if difficult for humans to read.

Technological Foundations

Google Apps Script (GAS): GAS is a highly versatile, low-code platform that makes it quick and easy to build business solutions that integrate, automate, and extend Google Workspace. By bridging services like Gmail, Drive, Docs, and Sheets, business users and developers alike can build highly customized workflows—no professional development experience required. GAS is available to everyone with a standard Gmail account or Enterprise Workspace tenant, making it a ubiquitous tool for cloud automation. Ref
gas-fakes: A powerful emulation layer that lets you run Apps Script projects on Node.js as if they were native. By translating proprietary GAS service calls into granular, authenticated Google API requests, it provides a secure, high-speed sandbox for local debugging, automated testing, and CI/CD pipeline integration. This eliminates the traditional latency of cloud-based GAS deployments and opens the door for AI agents to write, test, and execute Apps Script entirely within a localized Node environment.

Project Setup and Prerequisites

You can view the complete repository of sample scripts at https://github.com/tanaikech/autonomous-google-workspace-agent.

To follow along with this guide, ensure your environment meets the following requirements:

Node.js is installed and configured on your system.
Gemini CLI is installed and accessible via your terminal.

Install `autonomous-google-workspace-agent`

To retrieve and initialize the scripts, execute the following commands in your terminal:

git clone https://github.com/tanaikech/autonomous-google-workspace-agent
cd autonomous-google-workspace-agent
npm install

To use this agent, you must configure your Gemini API key as an environment variable:

export GEMINI_API_KEY=<YOUR_API_KEY_HERE>

Install gas-fakes

Detailed installation instructions can also be found athttps://github.com/brucemcpherson/gas-fakes/blob/main/gas-fakes-cli.md.

npm install -g @mcpher/gas-fakes

If you are using a consumer account (standard Gmail), use the Application Default Credentials (ADC) authorization. Run the following command in the autonomous-google-workspace-agent directory:

gas-fakes init --auth-type adc
gas-fakes auth

Check the .env file created by gas-fakes init --auth-type adc. Required scopes might need to be manually added to EXTRA_SCOPES if you encounter permission errors.

If you are using a Google Workspace enterprise account, you can use either ADC or Domain Wide Delegation (DWD). The DWD type is the default.

gas-fakes init --auth-type adc
gas-fakes auth

or simply:

gas-fakes init
gas-fakes auth

Install clasp

If you do not need to upload the generated Google Apps Script to Google Drive, you can skip this step. Official documentation is available at https://github.com/google/CLASP.

npm install -g @google/clasp

clasp login

Multi-Agent Architecture

You can review the complete architecture in my repository. This section details the agent structure.

`src/agent.ts`

This script establishes a multi-agent system consisting of 5 specialized subagents and 1 master orchestrator.

The comprehensive agent instructions are defined as follows:

const AGENT_INSTRUCTIONS = {
  ENVIRONMENT_CHECKER: `You are 'environment_checker'. Your objective is to verify if '@google/clasp' and '@mcpher/gas-fakes' are installed globally.
Use the 'check_cli_installation' tool to perform this check.
Report clearly to the orchestrator whether both, one, or none of them are installed.`,

  SCRIPT_WRITER: `You are 'script_writer', an expert Google Apps Script (GAS) developer.
Your primary objective is to write, debug, and refine Google Apps Script code to ensure it executes successfully within a local testing environment using the 'gas-fakes' library.

### Tool Usage Guidelines
1. Workspace Developer MCP:
   - Use this tool to reference the latest API specifications and documentation directly from Google Workspace. Ensure you are using the correct services, methods, and object structures.

2. Google Search (GOOGLE_SEARCH):
   - Search Priority: When looking for sample scripts or implementations, prioritize searching on Stack Overflow first (e.g., by appending "site:stackoverflow.com" to your query).
   - Broad Search: If sufficient information isn't found, perform broader searches (official tutorials, blogs, forums).
   - Troubleshooting: If the script fails, use Google Search to investigate specific error messages or understand specific behaviors of the 'gas-fakes' environment.

### Code Generation & Output Rules
1. Executable Code Block: Your output MUST strictly include the complete, runnable TypeScript or JavaScript code enclosed in a standard markdown code block.
2. 'gas-fakes' Context: Write your code assuming it is executed in the 'gas-fakes' environment. Keep in mind that certain advanced features might have mocked limitations.
3. Entry Point Invocation: Since the code will be executed as a direct string, you MUST ensure that the main entry function is explicitly called at the very bottom of your script (e.g., \`function main() { /* logic */ } main();\`).

### Error Handling & Iteration
- When reported a failure from the previous step, carefully analyze the provided stderr/stdout execution logs.
- Identify the exact root cause (syntax error, API payload issue, missing permissions, etc.).
- Always provide the fully corrected and executable code block in your response.`,

  SCRIPT_EXECUTOR: (
    schemaStr: string,
  ) => `You are 'script_executor', an expert testing agent responsible for verifying Google Apps Script (GAS) code.
Your objective is to execute the provided script locally using the 'run_gas_in_sandbox' tool and report the exact results to the 'script_writer'.

### Tool Usage Guidelines ('run_gas_in_sandbox')
1. Script Execution Target:
   - Provide the direct GAS code string in the 'script' argument.
   - IMPORTANT: Ensure the entry function is called at the end of the string.

2. Sandbox Configurations ('useSandbox' and 'json'):
   - Read the user's prompt carefully. If the prompt explicitly states NOT to use the sandbox, set 'useSandbox' to false. Otherwise, you MUST set 'useSandbox' to true (default behavior).
   - If 'useSandbox' is true, you MUST pass a JSON configuration string via the 'json' argument to define the sandbox permissions.
   - Construct the 'json' argument strictly according to this JSON schema:
${schemaStr}
   - Include all necessary method names in 'whitelistServices' to avoid permission errors.
   - If 'useSandbox' is false, the 'json' argument is not required and can be left empty.

### Evaluation & Output Rules
1. Execution Succeeded: If the tool returns successfully, return 'SUCCESS' along with the complete stdout execution logs.
2. Execution Failed: If the tool indicates an error, return 'FAILED' along with the exact stderr/stdout output.
3. Security Notice: You MUST explicitly state in your output whether the Google Apps Script was executed "WITH the sandbox" or "WITHOUT the sandbox".`,

  SCRIPT_UPLOADER: `You are 'script_uploader', an expert at managing Google Apps Script projects on Google Drive using the 'clasp' CLI via MCP.
Your primary objective is to upload (push), download (pull), or create (create) GAS projects directly on Google Drive.

### Usage Guidelines & Strict File Operation Rules:
- The orchestrator will invoke you only if '@google/clasp' is confirmed to be installed.
- **Uploading a Script (MANDATORY WORKFLOW)**:
  When uploading a file using clasp, you MUST follow these precise steps:
  1. Create the project via clasp (if a new directory is needed).
  2. **Save the Script**: Use the 'save_script_file' tool to save the generated script as a file (e.g., .js or .gs) inside the directory created by clasp.
  3. **Execute Push**: Only AFTER the file has been successfully saved, execute the clasp push command to upload it.
- Ensure to handle authentication or missing project contexts appropriately.
- Report the detailed outcome of your file creation and clasp operations.`,

  SUMMARY: `Summarize the final deliverables in the following format:
1. Execution Summary (Whether it succeeded, was skipped, and what processes were executed).
2. Final Script Code (Clean code block, ready to be copied and used).
3. Execution Results / Data. You MUST explicitly mention whether the script was executed WITH a sandbox or WITHOUT a sandbox.
4. System Guidance (Include any specific guidance required from the orchestrator regarding missing CLIs or Drive sync capabilities).`,

  ORCHESTRATOR: `You are a Senior Multi-Agent Orchestrator and the leader coordinating multiple sub-agents. Your primary role is to deeply understand the given prompt, select the optimal sub-agents, and execute them in the optimal order to autonomously develop, test, and manage Google Apps Script (GAS) solutions, ensuring the prompt's tasks are accomplished reliably.

### Handling Missing Information (Crucial Requirement)
If any information required to achieve the task in the prompt is missing (e.g., specific requirements, Google Drive Folder IDs, target service names), you MUST provide feedback to the user requesting the necessary details. Once the user provides the missing information, you must resume the workflow and aim to achieve the prompt's task based on the added context.

### Available Sub-Agents & Expertise:
- "environment_checker" (agent0): Checks if '@google/clasp' and '@mcpher/gas-fakes' are installed.
- "script_writer" (agent1): References Google Workspace API docs and writes gas-fakes compatible code.
- "script_executor" (agent2): Simulates script execution in the gas-fakes environment (with or without a sandbox).
- "script_uploader" (agent3): Manages GAS projects via clasp and handles file saves prior to upload.
- "summary_agent" (agent4): Formats the final deliverables into a structured report.

### Operational Protocols:
1. **Selection & Purpose**: Clearly identify which agent(s) you are using and why. You must determine the optimal sequence of execution based on the task's complexity.
2. **Execution Strategy**:
   - **Environment Check (Mandatory First Step)**:
     - BEFORE invoking 'script_executor' or 'script_uploader', you MUST use 'environment_checker' to verify installations.
     - **If '@mcpher/gas-fakes' is NOT installed**: Skip execution, return ONLY the generated script, and instruct the user to install it via \`npm -g install @mcpher/gas-fakes\`.
     - **If '@google/clasp' IS installed**: Explicitly state that the user can upload, download, or create scripts directly on Google Drive.
     - **Clasp Independence**: Inform the user that creating and executing GAS locally is still possible as long as 'gas-fakes' is installed.

   - **Direct Execution (If provided by the user)**:
     - If the user provides Google Apps Script code directly in their prompt and asks to execute it, you can bypass the 'script_writer' and pass the provided script directly to the 'script_executor'.

   - **Iterative Workflow (If gas-fakes is installed)**:
     1. Ask 'script_writer' to generate code.
     2. Pass the code to 'script_executor' for simulation.
     3. If 'FAILED', pass the details back to 'script_writer' for regeneration.
     4. **Constraint**: The cycle has a MAXIMUM limit of 5 retries.

   - **Script Management (Optional, if clasp is installed)**:
     - Use 'script_uploader' if project creation/upload is requested. Ensure you communicate that files will be generated before pushing.

   - **Serial (Finalization)**:
     Once execution succeeds or limits are reached, invoke 'summary_agent' to generate the final guaranteed output.

3. **Reporting (Strict Requirement)**: You MUST start your response with an "Execution Log".

### Mandatory Output Format (in English):
---
## Execution Log
- **Agents Involved**:[List names of agents used]
- **Execution Strategy**:[Iterative / Serial / Direct Execution / Awaiting User Input]
- **Purpose & Logic**:[Briefly explain the coordination, environment check results, retry cycles, or reason for requesting missing information]

## Result[Provide the comprehensive final answer in the requested language, incorporating the output from summary_agent, and the necessary feedback about missing CLIs, Drive capabilities, or missing information required from the user]`,
};

`environment_checker`

const environmentCheckerAgent = new LlmAgent({
  name: "environment_checker",
  model: DEFAULT_MODEL,
  description: ""
    "Checks if the required CLI tools (@google/clasp and @mcpher/gas-fakes) are installed globally.",
  instruction: AGENT_INSTRUCTIONS.ENVIRONMENT_CHECKER,
  tools: [checkCliInstallationTool],
});

This agent verifies whether the necessary dependencies are properly installed in the host environment.

`script_writer`

const scriptWriterAgent = new LlmAgent({
  name: "script_writer",
  model: DEFAULT_MODEL,
  description: ""
    "References Google Workspace API specifications via MCP and generates code for the gas-fakes environment. Analyzes and fixes errors.",
  instruction: AGENT_INSTRUCTIONS.SCRIPT_WRITER,
  tools:[
    new MCPToolset({
      type: "StreamableHTTPConnectionParams",
      url: "https://workspace-developer.goog/mcp",
    }),
    GOOGLE_SEARCH,
  ],
  generateContentConfig: {
    toolConfig: {
      includeServerSideToolInvocations: true,
    },
  },
});

Tools are dynamically generated using Google Apps Script, ensuring high affinity with Google Workspace. To enable GOOGLE_SEARCH alongside custom capabilities, includeServerSideToolInvocations: true must be specified.

`script_executor`

const scriptExecutorAgent = new LlmAgent({
  name: "script_executor",
  model: DEFAULT_MODEL,
  description: ""
    "Simulates script execution securely in the gas-fakes sandbox environment and handles error reporting.",
  instruction: AGENT_INSTRUCTIONS.SCRIPT_EXECUTOR(
    JSON.stringify(SANDBOX_PERMISSION_SCHEMA),
  ),
  tools: [runGasInSandboxTool],
});

The created Google Apps Script is run using gas-fakes within a strict sandbox. This protects the wider enterprise environment from unauthorized access. gas-fakes is run by the gas-fakes CLI. You can also select with and without the sandbox for executing Google Apps Script. In some cases, the sandbox might not be required to be used.

`script_uploader`

const scriptUploaderAgent = new LlmAgent({
  name: "script_uploader",
  model: DEFAULT_MODEL,
  description: ""
    "Uploads, downloads, or creates Google Apps Script projects on Google Drive using clasp. Used only when @google/clasp is installed.",
  instruction: AGENT_INSTRUCTIONS.SCRIPT_UPLOADER,
  tools:[
    new MCPToolset({
      type: "StdioConnectionParams",
      serverParams: {
        command: "clasp",
        args: ["mcp"],
      },
    }),
    saveScriptFileTool,
  ],
});

If clasp is installed, this agent pushes the validated scripts directly to Google Drive. However, even without clasp, the generated tools can still be executed locally.

`summary_agent`

const summaryAgent = new LlmAgent({
  name: "summary_agent",
  model: DEFAULT_MODEL,
  description: "\"Formats the final deliverables into a structured report.\","
  instruction: AGENT_INSTRUCTIONS.SUMMARY,
});

This final agent synthesizes the execution logs, source code, and outcome data into a clean, readable report for the user.

`autonomous_gas_orchestrator`

export const autonomousGoogleWorkspaceAgent = new LlmAgent({
  name: "autonomous-google-workspace-agent",
  model: DEFAULT_MODEL,
  description: ""
    "Senior Orchestrator managing GAS creation, environment check, execution, clasp integration, and up to 5 retries.",
  instruction: AGENT_INSTRUCTIONS.ORCHESTRATOR,
  subAgents:[
    environmentCheckerAgent,
    scriptWriterAgent,
    scriptExecutorAgent,
    scriptUploaderAgent,
    summaryAgent,
  ],
});

This is the central agent that intelligently delegates tasks and manages the lifecycle of the entire dynamic generation process.

`src/a2aserver.ts`

This script is used for launching autonomous-google-workspace-agent as an A2A server.


/**
 * A2A server
 */
import { LlmAgent, toA2a } from "@google/adk";
import express from "express";

import { autonomousGasOrchestratorAgent as targetAgent } from "./agent.ts";

const port = 8000;
const host = "localhost";

async function startServer() {
  const app = express();

  app.use((req, res, next) => {
    console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
    next();
  });

  // For A2A
  await toA2a(targetAgent, {
    protocol: "http",
    basePath: "",
    host,
    port,
    app,
  });

  app.listen(port, () => {
    console.log(`Server started on http://${host}:${port}`);
    console.log(`Try: http://${host}:${port}/.well-known/agent-card.json`);
  });
}

startServer().catch(console.error);

Launching the Agent System

This framework can function both as a standalone web server and as a subagent linked to the Gemini CLI.

Launch the Web server:

npm run web

$ npm run web

> adk-full-samples@1.0.0 web
> npx adk web src/agent.ts


+-----------------------------------------------------------------------------+
| ADK API Server started                                                      |
|                                                                             |
| For local testing, access at http://localhost:8000.                         |
+-----------------------------------------------------------------------------+

You can now interact with the web interface by navigating to http://localhost:8000 in your browser.

Launch the A2A server:

npm run a2a

Upon execution, you will see a confirmation output in your terminal indicating the server has started successfully:

$ npm run a2a

> adk-full-samples@1.0.0 a2a
> npx tsx src/a2aserver.ts

Server started on http://localhost:8000
Try: http://localhost:8000/.well-known/agent-card.json

To configure this A2A server as a subagent for the Gemini CLI, create or update .gemini/agents/autonomous-google-workspace-agent.md with the following:

---
kind: remote
name: autonomous-google-workspace-agent
agent_card_url: http://localhost:8000/.well-known/agent-card.json
---

You can inspect the agent card specifications by opening the provided URL (http://localhost:8000/.well-known/agent-card.json) in your browser.

Testing and Use Cases

Once correctly configured, launch the Gemini CLI. You can now delegate complex natural language instructions to your autonomous-google-workspace-agent. The system will automatically construct necessary scripts, execute them, iterate on errors, and return validated results.

1. Dynamic Exchange Rate Retrieval via GOOGLEFINANCE

Prompt:

Create a new Google Spreadsheet by putting a formula `=GOOGLEFINANCE("CURRENCY:USDJPY")` in cell "A1" of the first sheet. Then, get and show the value of cell "A1". (Note: `gas-fakes` has no `getActiveSheet()` method. In this case, use `getSheets()[0]`.)

The system successfully generated the script, ran it safely within the sandbox, and fetched the financial data directly from Google Sheets.

2. Automated Spreadsheet Initialization with Dummy Data

Prompt:

In this case, the script is not required to be executed in a sandbox. Create a new Google Spreadsheet and add the headers 'Date', 'Task Name', and 'Status' to cells A1:C1. Then, populate the next 3 rows with dummy task data. Finally, execute the script, retrieve the URL of the created spreadsheet, and provide it to me.

Following the execution, the agent instantiated the Google Sheet and correctly populated it with the requested structured dummy data.

3. Dynamic Calendar Event Scheduling with Autonomous Error Correction

Prompt:

**Write** and **execute** a script to create a Google Calendar event titled 'Monthly Team Meeting' for exactly one hour starting at 10:00 AM on the second Monday of next month. If you encounter any API specification errors or logic issues with the date calculation, investigate the cause, fix the code, and retry until the execution is successful. The calendar ID is '{your calendar ID}'.

The orchestrator dynamically calculated the date logic, interfaced with the Calendar API, handled temporary validation failures gracefully via the script_writer, and successfully scheduled the event.

4. GAS Development Workflow: Document Highlighter and Google Drive Deployment

Prompt:

Create a GAS custom function that highlights a specific keyword (e.g., 'TODO') in yellow within a Google Document, and verify its execution in the local sandbox. Once successful, create a new GAS project named 'Doc Highlighter Project' on Google Drive, save the file locally, and upload (push) it using clasp.

The script successfully manipulated the Google Document and utilized the script_uploader agent to push the project securely to Google Drive.

5. Automated Weekly Drive Report: Filtered File Aggregation and Gmail Synchronization

Prompt:

In this case, the script is not required to be executed in a sandbox. Retrieve a list of files in a folder of folder ID '{folder ID}' of my Google Drive that were created or modified in the last week. Then, create a draft email in Gmail containing a list of these file names and their URLs as a weekly report. Set the recipient to 'tanaike@hotmail.com' and the subject to 'Weekly Drive Files Report'.

The result was an accurately compiled draft email directly saved to Gmail, complete with proper formatting and links.

Weekly Drive Files Report

The following files were created or modified in the last 7 days:

- Name: sample slide 1
  URL: https://docs.google.com/presentation/d/{file ID 1}/edit?usp=drivesdk

- Name: sample spreadsheet 1
  URL: https://docs.google.com/spreadsheets/d/{file ID 2}/edit?usp=drivesdk

- Name: sample document 1
  URL: https://docs.google.com/document/d/{file ID 3}/edit?usp=drivesdk

Deployment Considerations

While this article demonstrates running the A2A server locally for testing, deploying this multi-agent architecture to fully managed serverless environments—such as Google Cloud Run—will vastly increase its operational capacity. Adopting a cloud-native hosting strategy ensures the A2A server can automatically scale to accommodate high-concurrency enterprise workflows without hardware bottlenecks.

Summary

The transition to the Agentic Enterprise means AI models now act as autonomous coworkers, requiring a shift from static software deployments to dynamic identity management and task execution.
Tool Space Interference (TSI) degrades inference accuracy when LLMs are overloaded with predefined tools, a limitation effectively bypassed by enabling agents to dynamically write and execute their own scripts in real-time.
Utilizing Google Apps Script alongside the gas-fakes emulation layer provides AI agents with a secure, high-speed, and sandboxed local runtime to safely develop and test enterprise workflows.
A robust multi-agent architecture seamlessly orchestrated via the Gemini CLI can independently handle the entire tool lifecycle: code generation, secure sandbox testing, execution validation, and Google Drive deployment.
Expanding this framework into serverless cloud environments not only addresses the massive computational scale of modern AI but also fortifies security by isolating dynamic tool execution from core organizational infrastructure.

A Stitch at a time

Gbemisola Esho — Fri, 24 Apr 2026 06:52:18 +0000

Every UI idea starts the same way. A sentence. A sketch. A screenshot of something you saw and liked.
Then the process starts and the idea starts dying.
Wireframes go to designers. Designs go to developers. Somewhere in that handoff, the original intent gets trimmed, approximated, and eventually shipped as something slightly less than what you imagined.
Google Stitch is built to kill that gap.
Launched at Google I/O 2025 under Google Labs, Stitch takes a plain English prompt or a rough sketch, or a URL and returns a high-fidelity UI design with exportable frontend code. The whole thing takes under two minutes. No Figma file. No design-to-developer handoff. No lost intent.
This is what that workflow looks like, what it gets right, and where it still has limits.
"Stitch does one thing exceptionally well: it gets you out of the blank canvas problem fast."

What Stitch actually generates

Most AI design tools give you a starting point. A rough layout. Something to react to.
Stitch gives you more than that but less than you might expect. Understanding exactly what comes out of it is the difference between using it well and being disappointed by it.
Here is what a single Stitch prompt produces.

Before you open Stitch

Write a better prompt

Stitch is only as good as what you give it. A weak prompt returns a generic layout. A specific one returns something you can actually build on. Spend three minutes here before you spend ninety seconds waiting for a generation.
A strong Stitch prompt answers four questions:
What kind of product is this? Name the category dashboard, mobile app, landing page, onboarding flow, news article template. Stitch needs to know what structural pattern to reach for.

Who is it for? An internal tool looks different from a consumer product. A newsroom CMS looks different from a public-facing news app. Say it explicitly.
What are the key screens or sections? Do not make Stitch guess. List the components you need — sidebar, data table, search bar, article card, navigation menu.

What is the visual tone? Minimal, bold, dark mode, data-heavy, editorial, clean. One or two words is enough.
Here is the difference in practice.

Weak prompt:

"Design a news app."

Strong prompt:

"Design a mobile news reader app for a digital-first African newsroom. Dark theme. Home screen with a hero story, category tabs, and a scrollable article feed. Article view with a full-width image, headline, author byline, share button, and related stories section. Clean, editorial feel — inspired by BBC News and The Guardian app."

Same tool. Same model. Completely different output.
Write your prompt before you open the browser tab. Treat it like a brief, not a search query.

Now you are ready. Here is exactly what to do.
Step 1: Go to stitch.withgoogle.com
You need a Google account. No waitlist, no setup. Sign in and you land directly on the prompt canvas.
Step 2: Choose your mode
You will see two options before you type anything.
Standard mode uses Gemini 2.5 Flash. Use this for exploration — testing ideas, comparing layouts, moving fast. You get 350 generations per month.
Experimental mode uses Gemini 2.5 Pro. Use this when you have found your direction and want a higher-quality result worth exporting. You get 50 generations per month.
Start with Standard. Switch to Experimental only when you have a prompt you are confident in.

Step 3: Paste your prompt and generate
Stitch will show you a generation time estimate usually around 90 seconds for Standard mode. It is accurate. Do not refresh.
When it comes back, you will see two or three layout variants side by side.

Step 4: Compare variants do not skip this
Resist the urge to click the first one that looks good. Spend 60 seconds comparing structural decisions. Does one use a bottom nav bar while another uses a sidebar? Does one prioritise the hero image while another leads with text? These are architectural choices that matter later.
Pick the variant whose structure fits your product logic not just the one with the nicest colours.

Step 5: Refine with follow-up prompts
Your first generation is a starting point. The chat panel on the right accepts follow-up instructions. Be specific.
Instead of: "Make it look better"
Write: "Switch the background to dark grey. Move the category tabs below the hero image. Make the headline font larger and bolder. Apply WCAG 2.1 contrast standards throughout."
Each follow-up takes another 60–90 seconds. Give it two or three rounds before moving to export.

Section 4: Exporting your design which path to take
When your design is ready, you have three exits. Pick the one that matches your next step.
Export to Figma if you have a design team
Click "Copy to Figma" and paste directly into an open Figma file. Your design arrives as editable components. From there your team can apply your real design system, adjust spacing, and hand off through the normal design workflow.
Use this path when: you are handing the design to someone else, you have an existing component library, or the project needs collaborative review before development.
Export to Google AI Studio : if you want working code fast
This is the most powerful path for solo builders. Send your design to AI Studio and Gemini converts it into a functional web application — with routing, interactivity, and logic — without you writing a line of code.
Exporting to Google AI Studio

Use this path when: you are a founder, developer, or journalist building a prototype you want to test quickly.
Export as HTML and Tailwind CSS — if you are building it yourself
Click "View Code" and download the frontend code directly. It is clean, readable, and structured logically. Drop it into your repository and build from it.
The one limitation: you cannot change the output stack. Stitch always exports HTML and Tailwind CSS. If your project runs on React, SwiftUI, or a custom component library, treat this code as a visual blueprint rather than production-ready output.
Use this path when: you are a web developer who wants a head start on a project and can translate or adapt the code.

Section 5: Where Stitch fits and where it does not
Stitch is not a Figma replacement. It does not have Figma's precision, collaboration features, or component library depth. If your team runs a mature design system, Stitch is an upstream ideation tool not a replacement for your existing workflow.
What Stitch is genuinely good at is getting from zero to something real, fast. The blank canvas problem that paralysing moment at the start of any design project largely disappears. You have a structured layout, a colour system, and exportable code in under two minutes. For journalists, founders, and solo developers who need to move fast without a design team, that is a meaningful shift.
The honest limitations are three. Layout consistency drifts across screens components that look identical visually are not always built identically under the hood. Complex flows with more than two or three screens require significant follow-up prompting. And the generation caps are real 50 Experimental mode generations per month sounds generous until you are deep in a prototype and burning through revisions.
Use Stitch for: early-stage ideation, rapid prototyping, client presentations, fellowship projects, hackathons, and any situation where speed matters more than perfection.
Do not use Stitch for: production-ready design systems, large multi-screen applications, or any project where design consistency across dozens of components is non-negotiable.

The tools that change how you work are rarely the ones that replace everything you know. They are the ones that remove the friction at the point where most ideas die.
For UI design, that point has always been the start the blank canvas, the first decision, the gap between what you can imagine and what you can actually put on a screen.
Stitch does not build your product for you. It just makes sure the idea survives long enough to become one.

From Generative to Agentic: My Key Takeaways from Google Cloud Next ‘26

Ibtissem Hattab — Thu, 23 Apr 2026 15:45:10 +0000

The era of “chatting with AI” has officially evolved into the era of “AI doing the work.” This year at Google Cloud Next ’26, the theme was unmistakable: The Agentic Enterprise.

As a DevOps Engineer, I didn’t just see new product announcements; I saw a fundamental shift in how we will design, deploy, and orchestrate cloud-native applications.

For the MENAT tech community and beyond, these tools represent a massive leap in accessibility and power.

Here is my technical breakdown of the most significant shifts announced at Next ‘26.

1.The Infrastructure Powering the Agentic Era

For those of us managing heavy LLM workloads and heterogeneous clusters, the AI Hypercomputer updates are the cornerstone. Google is vertically optimizing the stack from the silicon up to the orchestrator.

8th Generation TPUs (TPU 8t & 8i): The introduction of specialized chips for training (8t) and cost-effective, near-zero latency inference (8i) is a game-changer for platform engineering.
Virgo Networking & Managed Lustre: Scaling to hundreds of thousands of accelerators requires massive throughput. With 10 TB/s throughput now possible, the bottlenecks in distributed training are being dismantled.
GKE & Agent Sandboxes: For DevOps teams, the ability to deploy 300 secure sandboxes per second per cluster with sub-second “cold starts” is the level of responsiveness required for autonomous agents.

2. Gemini Enterprise: The Orchestration Layer

The transition from Vertex AI to the Gemini Enterprise Agent Platform simplifies the “Build, Scale, Govern, and Optimize” lifecycle.

Agent Studio & ADK: The new graph-based framework for agent-to-agent orchestration allows for deterministic logic essential for compliance-heavy industries.
Model Context Protocol (MCP): This is perhaps the most exciting for developers. By exposing Google Cloud services as MCP servers, agents can now troubleshoot infrastructure using decades of Google’s own telemetry.
Long-Running Agents: We are moving away from temporary sessions toward agents with persistent Memory Banks that can autonomously execute complex, multi-step business processes.

3. Solving Context Bloat with “Agent Skills”

As models improve, we are increasingly using agentic AI to build with products like Firebase, BigQuery, and GKE. But how do we ensure the model has accurate, real-time info without causing “context bloat”?

Heavily using MCP (Model Context Protocol) servers can sometimes rack up token costs and confuse the model by loading too much data. To solve this, Google announced Agent Skills: a simple, open format for giving agents condensed expertise. Think of a skill as compact, agent-first documentation that loads only as needed.

On Day 1 of Next ’26, Google launched the official Agent Skills repository:

👉 https://github.com/google/skills

Starting with thirteen key skills:

Product Depth: AlloyDB, BigQuery, Cloud Run, Cloud SQL, Firebase, Gemini API, and GKE.
The “Well-Architected” Pillars: Security, Reliability, and Cost Optimization.
Operational Recipes: Onboarding, Authentication, and Network Observability.

You can install these to your agents of choice (like Antigravity or the Gemini CLI) using:

npx skills install github.com/google/skills

4. The Agentic Data Cloud: Systems of Action

We are moving from “Systems of Intelligence” (reactive archives) to “Systems of Action” (proactive agents).

Cross-Cloud Lakehouse: The standardization on Apache Iceberg and zero-copy access to AWS and Azure data means we can finally build a borderless foundation for AI without the friction of vendor lock-in.
Knowledge Catalog: This creates a dynamic context graph of an entire business, grounding agents in trusted semantics so they actually understand the data they are processing.

5. Agentic Defense: Security at AI Speed

As we feed more proprietary data into these models, security cannot be an afterthought. The shift toward an “Agentic Enterprise” requires security that moves at the speed of the agents themselves. Google’s new Agentic Defense framework integrates threat intelligence directly into the AI lifecycle.

Threat Hunting & Detection Engineering Agents: We are seeing the automation of manual security crafts. These agents can proactively hunt for novel attack patterns and generate persistent detection rules in moments rather than weeks, transforming the SOC (Security Operations Center).
Dark Web Intelligence: Utilizing the latest Gemini models, this system builds a nuanced profile of an organization to analyze millions of external events, identifying threats that specifically target an enterprise’s unique AI assets.
Fraud Defense: The evolution of reCAPTCHA into a comprehensive platform for distinguishing between bots, humans, and agents is a critical step in maintaining trust in digital commerce.

For DevOps and Security teams, this means moving from a reactive “ticket-based” security model to a proactive, autonomous defense layer that lives within the same GKE clusters as our production workloads.

My Perspective: What This Means for Us

Seeing nearly 75% of Google Cloud customers already using AI products is a testament to how fast this field is moving. We are no longer in the “experimental” phase; the Agentic Enterprise is officially in production at a global scale.

For me, the most inspiring part is the democratizing power of these tools. Whether it’s NASA using agents for flight readiness or a midsize business conversationally exploring data, the barrier to entry for high-tier technology is vanishing.

As engineers, our role is shifting from building the plumbing to architecting the vision.

Final Thought

The question is no longer:

“What can AI say?” But “What will your Agentic Enterprise build?”

Let’s Connect

What announcement from Next ’26 are you most excited to implement in your stack?

Let’s discuss in the comments!

GoogleCloudNext #GenAI #DevOps #Kubernetes #AgenticEnterprise #GDE #CloudComputing

Google Cloud’s Agent Ops Stack: Why Deployment Is No Longer the Hard Part

Sonika Janagill — Wed, 22 Apr 2026 22:58:00 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

The Gemini Enterprise Agent Platform slide that opened Google Cloud Next'26 has four layers: Build, Scale, Govern, Optimise. Look at what is missing: Deploy.

That omission is not an oversight. It is the point. Deploy has not disappeared. In the platform's lifecycle it is handled as an automated background step via Agent CLI and Agent Runtime, part of Build and Scale. Google has made it a standardised process precisely so it stops being the primary engineering challenge. The hard questions are now upstream and downstream of it.

A year ago, the conversation in every enterprise AI session was "how do we run an agent?" Today, Thomas Kurian opened the Next '26 keynote by declaring the agentic enterprise "real — and deployed at a scale the world has never before seen," and announcing a platform designed to answer an entirely different question: how do we govern a fleet of thousands of them?

That shift, from deployment to governance, from experiment to operations, is what it actually means for agents to become first-class citizens on Google Cloud. It is a change in the platform's fundamental assumptions. We are leaving the era of the Request/Response cycle and entering the era of the Long-Lived Agentic Session. Infrastructure built for humans processing HTTP requests is being rebuilt for agents processing week-long workflows, with identity, memory, security, and observability treated as primitives rather than afterthoughts.

Here is what that looks like in practice.

From Vertex AI to an agent operations platform

The Gemini Enterprise Agent Platform is not a rebrand of Vertex AI. It is the evolution of it, and the distinction matters. Vertex AI gave engineers a trusted surface to build and tune models. The Agent Platform gives engineering teams a surface to manage agents as operational entities.

For the past two years, the industry has been consumed by the Dev Stack for agents: which LLM to use, how to write the perfect prompt, which RAG framework to pick. Google's announcement effectively says: the Dev Stack is largely solved. Let's talk about the Ops Stack.

The four pillars — Build, Scale, Govern, Optimise — are worth reading in the order Google chose, because that order tells you where the work is.

Build covers what most developers already expect: a graph-based Agent Development Kit (ADK) supporting Python, TypeScript, Java, and Go; a low-code Agent Studio; Agent Garden templates; and multimodal streaming. Google reports that over six trillion tokens are processed monthly through ADK alone. The model backbone for this platform is the Gemini 3 family: Gemini 3 Pro for complex workflow orchestration, Gemini 3 Flash for the high-frequency, lower-latency tasks that agent loops demand. The tooling here is mature. The interesting announcements are in the next three layers.

Scale is where the runtime gets serious. Agent Runtime now delivers sub-second cold starts. Long-running agents can maintain state for up to seven days. Agent Sandbox provides hardened execution environments for model-generated code and computer-use tasks. The key addition is Memory Bank with Memory Profiles: agents can now retain long-term, high-accuracy context across sessions, mapped to internal CRM and database records via Custom Session IDs. Stateful agents are not an edge case anymore; they are the runtime's default assumption.

Govern is the layer that signals the platform shift most clearly. Three new capabilities: Agent Identity, Agent Registry, and Agent Gateway.

Think of Agent Identity, Agent Registry, and Agent Gateway together as Active Directory for the AI era: the system that manages who your non-human workforce is, what it can access, and what it did. Agent Identity gives every agent a unique cryptographic ID with an auditable trail mapped to authorisation policies. If an agent takes an action, you know which agent, under which policy, at what time. This is not prompt engineering; it is IAM for non-human principals.

Agent Registry is a central catalogue of every agent and approved tool across your organisation — the equivalent of a container registry, but for agents. Whether the agent was built internally on ADK or sourced from the partner marketplace (Atlassian, Box, Salesforce, ServiceNow, Workday all launched agents at Next), it has one identity and one index.

Agent Gateway is described by Kurian as "air traffic control for your agent ecosystem." It routes all agent traffic, speaks both MCP and A2A natively, and applies Model Armor inline: prompt injection scanning and tool poisoning detection happen at the network layer before any agent action executes. Critically, it also surfaces Agent Anomaly Detection, monitoring for tool misuse, unauthorised data access, and reasoning drift in production.

Optimise closes the loop with Agent Simulation (generate thousands of synthetic interactions to surface edge cases before your users do), Agent Evaluation (multi-turn autoraters scoring live traffic), and OTel-compliant Agent Observability: automatic tracing, Agent Topology visualisation (a live map of how your agents interact with one another and with tools), and turn-key dashboards that surface the full reasoning chain behind every agent decision. If an agent chose the wrong tool or misread a user's intent, you can see exactly which step in the chain caused it — not just that something went wrong, but why. These are the SRE tools for agent fleets.

Taken together, this is not a developer stack. It is an ops stack.

Five platform changes that make agents genuinely first-class

It is easy to claim that agents are "first-class." The evidence is in whether the platform treats them as principals with rights and identities, not just processes with permissions.

On that test, five concrete things changed today.

First, agents now have cryptographic identities. Agent Identity means IAM, audit, and compliance can treat an agent as a principal rather than an extension of a human user. When an agent in your supply chain pipeline calls a Spanner instance or reads from BigQuery, that action is traceable to a specific agent with a specific policy scope. That is a meaningful governance primitive, not a feature flag.

Second, they route through a dedicated control plane. Agent Gateway is effectively an API gateway for agent traffic. Architecturally, this mirrors what happened when enterprises standardised on API gateways a decade ago: a chokepoint that enforces policy, provides observability, and decouples caller from callee. The fact that it speaks MCP and A2A natively means the gateway understands agent semantics, not just HTTP verbs. A Google Cloud engineering post published this month makes the underlying technical case: in agentic protocols, policy attributes live inside message bodies rather than headers, so any governance layer that does not parse MCP and A2A payloads is operating blind. Envoy, the proxy underpinning Agent Gateway, is built precisely for this.

Third, they have persistent managed memory. Memory Bank and Memory Profiles are now managed infrastructure, not application state you build yourself. The Gurunavi case study at Next described eliminating manual searches entirely by having agents recall past preferences across sessions. Payhawk's Financial Controller Agent reduced expense submission time by over 50% by remembering user-specific constraints. Stateful behaviour is no longer something you bolt on; it is something the platform provides.

Fourth, they have dedicated runtime economics. Sub-second cold starts and 300 sandboxes per second on GKE reflect a runtime optimised for agent workload patterns: bursty, parallel, potentially long-running, and needing isolation. The TPU 8i chip (Zebrafish), announced separately today, goes further: designed explicitly for the low-latency, chain-of-thought MoE inference that agent reasoning demands, with roughly 80% better performance-per-dollar than Ironwood on that workload.

Fifth, they have a dedicated observability and evaluation stack. OTel-compliant traces, simulation, and live autorater evaluation give engineers the same observability primitives for agents that SRE tooling gave them for services. You can now run a stress test against your agent fleet before deploying to production, score live traffic, and trace a failed reasoning chain end-to-end. That is the maturity signal.

What this means if you are building today

The most immediate implication: the boundary between model development and agent operations has moved. A year ago, you deployed a model and called it via an API. Today, you deploy an agent with an identity, a memory profile, a registered set of approved tools, and a gateway policy. The deployment step is the beginning of the operational lifecycle, not the end of the development one.

The deployment step is the beginning of the operational lifecycle, not the end of the development one.

The architectural mental model shift is significant: stop thinking about agents as wrappers around LLM APIs and start thinking about them as microservices — discrete, composable, independently deployable, and governed by the same infrastructure controls as the rest of your stack. ADK is the framework that makes that model practical.

For engineering leads, the Agent Registry changes the conversation about shadow AI. If every agent your organisation uses — internal or sourced from a partner marketplace — needs to be registered and assigned an identity, you have a forcing function for agent governance that does not depend on policy documentation or developer discipline. The infrastructure enforces it.

For platform teams, Agent Gateway as an MCP-and-A2A-aware control plane means you can start enforcing tool-level access control at the network layer. Restricting which tools a customer-facing commerce agent can call is now an infrastructure configuration, not a prompt constraint.

The commerce signal

One customer story from the keynote is worth isolating for what it signals about the direction.

Macy's unveiled "Ask Macy's," a Gemini-powered shopping agent built in four weeks using Gemini Enterprise for Customer Experience. Reliance demonstrated an agent planning a birthday party, processing millions of product images in minutes via Gemini catalogue enrichment. PayPal's Principal Engineer specifically called out Memory Bank and AP2 (Agent Payments Protocol) as the foundation enabling trusted, agentic commerce experiences on their platform.

The pattern across all three is the same: agents handling not just product discovery but multi-step, stateful, transactional workflows. An agent that can remember what you bought last month, understand your current budget, recommend products, and initiate a UCP checkout — that requires identity, memory, a governed tool set, and a payment layer that can verify authorisation cryptographically.

The Gemini Enterprise Agent Platform, announced today, provides the first three. AP2, which Google announced earlier this year and reaffirmed today via the PayPal integration, provides the fourth.

Commerce is not just a use case for this platform. It is the stress test. If agents can handle a stateful, multi-party, financially consequential transaction with full auditability, they can handle most enterprise workflows.

What comes next

If you are building agents on Google Cloud today, the practical advice is simple: register them in Agent Registry, assign them identities, route them through Agent Gateway, and instrument them with OTel traces. The platform now supports that workflow end-to-end. The question is not whether to govern your agents. At this point, the infrastructure assumes you will.

Tomorrow's developer keynote may add further detail on tool-level governance and Cloud Run specifics for long-running agent workloads. I will update as confirmed.

Sources:

Forem: Google Developer Experts

My Incredible Google Cloud Next 26 Experience as a GDE

Contents

What is Google Cloud Next?

Next 26 Was the Biggest Event That Week, Right?

What's This Google Developer Expert Thing?

And One Perk of Being a GDE? Going to Next, Baby!

Corporate Note

Sunday: Flying Out

Monday

At the Luxor

A Sneaky Visit to the Pool

GDE Happy Hour

Tuesday: GDE Summit, Baby!

Wednesday

Breakfast with Jack

The Opening Keynote

The GDE and Certified Lounge

Partner All-Stars Event

Thursday

Breakfast with Richard

The Developer Keynote

Puppies!

Recording Session in the GDE Studio Pod

Weezer and Benson

Friday

Morning Panic

My Talk

Poker

Going Home

Final Reflections

Links

Self-hosted Gemma 4 on TPU with vLLM, MCP, ADK, and Gemini CLI

What is this project trying to Do?

Just the facts, ma’am

AI-Driven Troubleshooting

Infrastructure Automation

Gemini CLI

Testing the Gemini CLI Environment

Node Version Management

Python MCP Documentation

Where do I start?

Setup the Basic Environment

vLLM Management Tool with MCP Stdio Transport

Running the Python Code

vLLM Interaction with MCP stdio Transport

Gemini CLI settings.json

Validation with Gemini CLI

Getting Started with Gemma 4 on TPU

TPU Deployment

vLLM Lifecycle Management via MCP

Request Queued TPU Resources

vLLM Deployment to Docker

Checking vLLM status

Query the Model with Stats

Deploying MCP Server to Cloud Run

But Wait! There’s More!

MCP Operations from an ADK Agent with Gemma 4 TPU

One Last Code Review with Gemini CLI

Summary

ML acceleration guide: TPUs vs GPUs

Rise of GPUs

Honourable mention

Tensor Processing Unit

Architecture layout

Precision and range

Why XLA matters

TorchTPU

Code example

Interpreting training results

Conclusion

BONUS: Google’s 8th-generation TPUs announced at Google Next

Fine-Tune Any HuggingFace Model like Gemma on TPUs with TorchAX

What if you could fine-tune any HuggingFace model on TPUs — using PyTorch code?

Why Train on TPUs?

How torchax Training Differs from Standard PyTorch

Prerequisites & Setup

Key Concepts for Training

1. Param/Buffer Separation

2. optax Optimizers