I attempted to build a team of agents to help do my job on Google Cloud Agent Platform with the…

I attempted to build a team of agents to help do my job on Google Cloud Agent Platform with the agents-cli. This is what I learnt.

Will AI take my job? 8 years ago, I wrote an article without the help of AI on Experiments in making my role redundant. The article detailed my successful experiment in eliminating siloed Quality Assurance (QA) role and transition to a model where the entire team shares responsibility for software quality. The result wasn’t that I was jobless, or twiddling my thumbs, rather it was that I was presented with a brilliant opportunity and proceeded to evolve in my career, ultimately finding myself at Google. It got me thinking about what might be possible today.

AI should facilitate human creativity, not replace it.
— Mouth Coding by Brad Frost

One aspect of my job is building demos to showcase the art of the possible with Google Cloud, and to inspire you and other developers.. But, I tend to come up with more ideas than what I can actually build. This seems like a prime opportunity to figure out if I can get AI to help; a team of agents to build a demo creator. If it means that more ideas are brought to life, or more demos help out customers, then it seems like a better use of my time!

I learn by doing and getting hands-on. So this post is simply me learning and trying Agent Platform, using agents-cli, Gemini CLI, and Agent Platform, to see if AI agents can help me do my job, specifically, building demos.

Assembling a team of agents; starting with the new agents-cli.

Firstly, I use the term agents here. Not an agent. I think a single Esther Demo Agent seems like it just wouldn’t work. Also, putting all the eggs in one basket. Therefore I want to break down what I would potentially do into agentic services.

I’ve built some agents in the past, but using the “old fashioned way”, which was reading the ADK documentation and using Gemini Code Assist of the Gemini CLI to help with the coding. But now, things are changing, and development has shifted along.

So, first I am going to try the newly released agents-cli. The agents-cli is the evolution of the agent starter pack, it has tools and skills for building, evaluating, deploying, and operating agents on Gemini Enterprise Agent Platform. You can either invoke it manually, using it like any other CLI, or it turns your favorite AI development tool or agent harness (Claude Code, Gemini CLI, Codex, and any other coding agent) into a pro, so you can concentrate all your energy on creating agents. As we move away from MCP to Skills + CLI’s, this approach makes a lot of sense.

I attempted to build a team of agents to help do my job on Google Cloud Agent Platform with the… — *Installing the agent-cli was a great experience. Simply uvx google-agents-cli setup on a Python friendly environment.*

Installing the agents-cli, it pulls in agent skills from https://skills.sh/google/agents-cli, which I found interesting in itself as I wasn’t aware that Google had listed all the official skills here https://skills.sh/google. The CLI is opensource, but the code is zipped in a .whl file, so the source code isn’t shown directly in the repo. I was interested in the source, and what the CLI was doing behind the scenes. So I downloaded the .whl using

pip download google-agents-cli --no-deps && unzip google_agents_cli-0.1.1-py3-none-any.whl

It’s rather brilliant, essentially it’s what a platform team might be building themselves to help their companies ship agents. Everything from the terraform, to the deployment pipelines. Thought it was interesting to see the differences in how the agents are deployed when the target is Agent Runtime, Cloud Run or GKE. It’s very opinionated I might add (but sometimes this is a good thing).

So getting back to actually using the agents-cli. Now that it is installed, I want to use it with the Gemini CLI. Checking CLI, I can see the skills are listed. Else, I guess I could explicitly call the agents-cli in the prompt rather than hoping.

Checking what skills are installed to use with any AI coding harness.

From here, I put in the following prompt into Gemini CLI:

Using the the agents-cli I want to create a team of agents. The agents should form a little Google Cloud Developement team, and they focus on the serverless stack (Cloud Run etc), developer focused platforms like Firebase Platform, and AI Dev Tools. The team is designed to replace me (Esther) in building out demos for customers to showcase the ebst of google Cloud and what's new. The idea would be that I can put in an idea in the form of a long prompt (maybe using voice to text and then passing through the unfiltered idea and narrative of what I want to achieve),and then the team will build it. there should be a demo script also to help make the demos reusable. At Cloud Next '26 there was a demo theme around Marathons, https://github.com/GoogleCloudPlatform/next-26-keynotes, this is a good reference to see what they may end up looking like. The demos should be best practices, showcasing the latest of Google Cloud.

Immediately I like how the agents-cli ships with an agentic workflow, so then I am guided to create and form a planning design spec. This is crucial. I’m a big fan of planning ahead of time, more time planning, less tokens wasted I say.

Decided to call the agents my angels. While my name isn't Charlie, and my naming is conventional, I do like the DESIGN_SPEC outlining the approach allowing me to adjust as needed before implemntation.

Refining the implementation; ADK and Skills.

I found it really interesting to see what the agents-cli came up with. First, I think it is an oversight not to include the ADK Docs Skill with the agents-cli by default. I might look at seeing if that’s possible going forward. I had to add this later, mostly to ensure that the agents were using skills correctly (more on that later).

The implementation took me by surprise. I assumed that the agents-cli would spin up multiple agents as instructed. Instead, to ensure that there was a “team” I suppose, it created a root orchestration agent with a series of subagents. I’m not sure I’m a fan of this. Note, I don’t really know what agentic architectural best practices are, but the inner microservice in me screams that this isn’t ideal. I would prefer the agents be decoupled, and be able to work autonomously and for me to be able to update and redeploy independently. Additionally, by having the sub agents listed as dependencies in the root_agent it means that if an agent is down, or not required, or if a new agent is needed, then it’s a whole new deployment.

While I haven’t used it (and might experiment with this approach later), it seems like the new Gemini API Interactions API might be well placed here instead. The Interactions API is a unified interface for interacting with Gemini models and agents. It simplifies state management, tool orchestration, and long-running tasks. Potentially that could be used by decoupled agents instead.

The other thing that I was surprised at, was the agent implementations. They didn’t refer or use skills. Now that ADK supports skills and to ensure that I was using the newly released skills from Google Cloud (https://github.com/google/skills) I adapted the subagents to ensure they used the skills. Luckily for me, the skills that have been released so far really complement my own skill set, namely with the Firebase and Cloud Run skills.

Lastly, I needed to add a .gitignore. There was a lot of scaffolding (unsure what process caused it if I’m honest) of agent skills for every agentic coding harness under the sun it seems. I removed that, in favour of the .agents directory.

To better summarise some of the additional changes I made, here’s Gemini CLIs take:

There was a fair amount of human-in-the-loop to get to a first pass of the agents, so I used Gemini CLI to summarise the changes.

Another point of interest was the skills-lock.json. This seems to be a Vertex opinionated method to lock down the skills with a hash key, based on the install path. I like this in theory, I wrote about this actually in my last post that we need a way to manage skills and have a registry. But I’m unsure if this is the solution. Be interesting to see if it takes off. But it doesn’t mean that the skill hasn’t been changed or ignored completely when the agent invokes it. Also assumes that the source will persist. Libraries are a little different to skills and I don’t think context can be treated like code.

{
  "version": 1,
  "skills": {
...
    "firebase-basics": {
      "source": "google/skills",
      "sourceType": "github",
      "skillPath": "skills/cloud/firebase-basics/SKILL.md",
      "computedHash": "b1bbd67ca1bf614e1130ee6e02021c1518448fda4bcd420c81014c2e4ffb22ec"
    },
...

The skills came into play when I wanted to ensure that agents had known skills at their disposal. By checking in the downloaded skills, they could be passed to the subagents using the skill_toolset function in the ADK framework. Ideally these would be discoverable at runtime, but for the time being, seems valid.

# --- Load Skills ---
# Skills are located in the .agents/skills directory at the project root

# Create a SkillToolset to be shared by all agents
# This gives them the ability to list, load, and run scripts from the skills
skill_toolset = SkillToolset(skills=skills, code_executor=BuiltInCodeExecutor())

Finally, it’s worth mentioning that the agents were configured with A2A so they can be added to Gemini Enterprise or exposed to other agents, or surfaces.

Deploying the agent; the Google Cloud agent stack.

It’s worth showing the opinionated agent stack with Google Cloud and the Agent Platform. This is what the agents-cli helps to manage and orchestrate. Like an agents platform team. There are a couple of Deployment options, either Agent Runtime (formerly known as Agent or Reasoning Engine), including Cloud Run which I’m happy to see. There is a lot in the new Agent Platform. Deploying to Agent Runtime is easy, but less portable. I’d probably prefer a Dockerfile and Cloud Run instance, but I do want to try Agent Runtime as an opinionated runtime for agents.

The Google Cloud agent stack that agents-cli builds on (https://github.com/google/agents-cli).

First though, I want to test if the agent actually works. Should I do this locally? Makes sense to me. Or are we at the point of time where we just deploy and then test in production? Why not both? I decided to deploy the agent, and while I wait for the deployment (quite a while I might add… Gemini CLI had to add in a wait sleep loop to poll for the status).

When the deployment finished, I went to Agent Platform in Google Cloud Console to see the Deployment. It didn’t work. Immediately I wished there was a CI/CD pipeline. Using AI to deploy AI isn’t exactly deterministic. There is a file deployment_metadata.json that is created with a timestamp of deployment, and some information about the deployment target. It’s like the skills lock, this is just a snapshot and could change. This is only subject to being checked in with a codebase. If another developer was working on this agent, in another code base, and both myself and the other developer went to deploy and then checked in this metadata, it would be a nightmare to understand what is deployed and what code is deployed! I really think there should be basic best practices put in place with deployment of agents.

Turns out the error was a missing API, I enabled this, and tried the deployment again. This time it worked, the deployment was successful and easy.

The deployed Agent (root agent) served from Agent Runtime and shown in Google Cloud Agent Platform.

However, you can see the 404 error rate is 100%. This is as when I went to use the agent in the Gemini Enterprise app, it sadly didn’t work. Back to the agents-cli and some investigation. I appreciate the Playground in the Agents Runtime to be able to test the agent, and the inbuilt telemetry and observability. Once deployed and operational, I can then simply just call on my team of Angels to be able to help create demos on the fly in Gemini Enterprise. But if I’ve learned anything from this experience, it is that I need to spend more time getting these foundations done correctly, and testing the agents’ work first.

I ended up also deploying the agent to Cloud Run, and exposing it as an A2A agent. This worked perfectly with Gemini Enterprise. It was super simple to register the Agent, given the A2A card URI, and suddenly I could chat to my team of agents in the Gemini Enterprise App.

Calling my agent served in Cloud Run from Gemini Enterprise App.

What I learned; AI won't take my job, but it will change it.

Up until now, this has all been written by me, a human, without Gemini or AI assistance. AI hasn't taken my job (the lack of long dashes in this post supports this), but it is making me far more productive and able to think outside the box.

While I got somewhere in building a team of agents, and a chance to learn the Agents Platform, I realised really quickly there is SO much I need to consider to make this actually useful. Things that stood out include:

CI/CD for Agents: build, test, deploy still should exist. Even if AI coding agents might change how. What skills were used and locking down the agent deployment to understand actually what is deployed is highly important. Surely we need to be thinking of best practices, SALSA, ensuring there is provenance as we ship from source to production… Versioning of agents even at a minimum, rollbacks, evaluations… so much.
Decoupled agents: I wasn't a fan of the orchestrator / subagent pattern that was created. To me, it's a bloated service. I want to investigate further how to ensure that these agents can be decoupled but share context.
Observabilty is key: errors, missing permissions, APIs that need enabled… all standard issues that we think about all the time. Only a matter of time before most reason agents fail is because of CORS.
Docs first, code later: planning is still key. Use tools to really get clear specs in place. To be honest, I should have stopped the implementation and redefined the spec to address most of these concerns at the time instead of YOLOing.
Question everything, get excited: I might be wrong here, but it seems if we strip away the LLM results, agents are like microservices. We should be treating them as such. But, things are changing so quickly, and it's never been easier to use agents to build agents. I'm excited to see the future. Who knows, might be soon I have an ephemeral team of agents I call on demand when I need a new demo?

Finally, this is what Gemini thinks about this:

Experimenting with the new agents-cli and Google Cloud’s Agent Platform was an eye-opening journey into the future of demo creation, revealing both the incredible potential of agentic orchestration and the critical importance of treating agents like production software. While my first deployment taught me that even the smartest agents need a solid foundation in CI/CD and observability, I’m genuinely excited to see how these powerful new developer tools continue to mature.1

Building the future is messy, but the view from here is incredible; I’m eager to refine these engineering foundations and get my demo-building team fully operational — stay tuned for the next update!

I attempted to build a team of agents to help do my job on Google Cloud Agent Platform with the… was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source Credit: https://medium.com/google-cloud/i-attempted-to-build-a-team-of-agents-to-help-do-my-job-on-google-cloud-agent-platform-with-the-dc99ff03205f?source=rss—-e52cf94d98af—4