You see, I very much welcome this era of AI (Despite the some concerns đ€)
All my ideas, and initiatives which I didn't have time for in the past, or rather didn't know how to build outâââand Now Ican go at it.
I can build out those ideas, prove their worth, and even scale ⊠although many tend to fail spectacularly, as im quickly learning that âExecution stage is where Strategy comes to dieâ. (Perhaps more on that in another blog post.)
Be it a hackathon or a personal project, you have all the freedom to get creative solving a problem, and move fast (evening or a weekend, in-between kids playtime). You tend to get ready for the practical work: architecture, IAM, service choice, costs, deployment, tests, alerts, run-books, and all the small decisions that decide whether the thing is useful beyond the first demo.
It just happened that I kept rebuilding that baseline, in varied forms and ways for my Google Cloud hosted project.
Over the past two years, across my own projects, hackathons and delivery experiments, I have found myself seeding the same foundations – a way to give an agent the project context, skills for common work, clear constraints, a path for design review and a definition of what âdoneâ means.
That is why I have released the GoogleCloud Plugin: an open-source Google Cloud delivery baseline for your coding agents.
It is the Google Cloud companion to my public join-the-team harness. It gives an agent a working team, a routing model and a set of delivery gates for Google Cloud work. The plug-in currently supports Claude Code, Codex, Antigravity and Kimi Code.
A plug-inâââWorkflow + Expert Skills
Google Cloud skills, prompts and MCP servers are appearing everywhere. That is useful. The missing piece is an operating contract: what happens before an agent writes code, and who checks the result before it becomes a billable production service?
The plug-in starts with the following delivery flow:
- Define the intent and decide whether Google Cloud is the right boundary.
- Design the Google Cloud solution before implementation.
- Review identity, permissions, secrets and security controls.
- Build with service-specific guidance.
- Run quality checks and agent evaluations.
- Require an SLO, alerting and a runbook before production.
That sequence just comes from the way I buildâŠ
So when the agent has a blank workspace, it will often make reasonable local choices. A team needs choices that remain reasonable when someone else inherits the work, when a cost alert arrives, or when security asks how a service account acquired its permissions.
The rule underneath the workflow is deliberately plain: infer intent, never infer permission. The agent can draft, design and validate. A named human still authorises a consequential, billable or irreversible action.
What is In The Box
The plugin packages six specialist delivery roles, supported by service-specific and cross-cutting skills.
The roles cover solution design, Google Cloud architecture, agent architecture, security, quality assurance and operations. They establish who should lead each stage of the work and where another specialist needs to review the result.
The first set of service skills covers Cloud Run, GKE, IAM, BigQuery, Cloud Storage, Vertex AI, networking, and logging and monitoring. Cross-cutting skills cover MCP servers, Terraform on Google Cloud and the Well-Architected Framework.
The aim is to get practical. Ask the agent for a Cloud Run service, a BigQuery design, an agentic workload or an IAM review and it should know which role starts the conversation, which checks follow, and which work needs human approval.
How I would start with it
Start with a small request that you can judge properly. A Cloud Run service that reads from a defined data source. An IAM review for an existing service account. A sketch for an ADK workload with an explicit user and a clear boundary. Give the agent the problem, the constraints and the outcome you need.
The plug-in should take that request through the relevant path. A broad requirement starts with the solution designer. A clearly Google Cloud request begins with the GCP architecture work. An agentic workload brings in the agent architect. Before implementation, the security role checks the identity and permission model. The quality and operations roles ask for evidence before the work is called ready.
That is the test I would use. The first response should make the delivery conversation more precise. It should surface a missing requirement, an unclear owner or an unsafe permission before those omissions become code. A good agent does more than produce files. It helps the team make the right next decision.
Why Gates Matter
Agents make the implementation phase faster. They also make it easy to skip the work that used to slow us down for good reasons.
A GCP project can look complete while it still lacks a least-privilege review, a cost decision, a test path or an operational owner. The missing parts only show themselves later, when the project reaches another team or a production environment.
The plug-in therefore treats design, security, quality and operations as part of the build. It also carries two habits that are easy to lose in a fast-moving project, such as
- Warn before a billable action;âââđ«Ł
- Keep a research trail, including source URLs, retrieval dates and content hashes, so documentation can be checked again when Google Cloud changes.
The repository runs its own checks through make gate. I intend the MCP toolsâââfetching the latest docs on demandâââto be what keeps this harness fresh, because Google Cloud services, models and guidance change frequently.. WE really donât want stale advisory, or incoherent architecture solution design which uses legacy service naming and referencing.
Built for a community that works across tools
People will keep choosing different coding agents. Some live in a terminal. Some work inside an IDE. Some work best with one model; others deliberately spread tasks across several. I do not think the delivery discipline should have to start again with every tool choice.
The plug-in keeps the Google Cloud contract separate from the agent surface. Claude reads its own plug-in manifest. Antigravity and Kimi have their installation paths. Codex discovers the included skills and AGENTS.md directly after a clone. The common part is the work: think before generating, review security before deploying, and leave evidence behind for the next person.
This is also where the community can make it much better. I have focused the first release on the services I reach for most often, and on the agentic patterns that keep turning up in my own builds. It covers a selected part of Google Cloud.
Try it. Feedback to improve it. (PR)
Excited to try it? Check it out on github here.
I would value feedback on the parts that only show themselves in real work. Better yet recommend me the improvements by forking the repo and creating a Pull Request with your contributions, comments welcomed.
I have been building these foundations for myself because I wanted a quicker start without starting carelessly. Sharing them with the Google Cloud community feels like the useful next step. If it saves somebody from reconstructing the same delivery baseline on their next build, it has done its job. đ
The project is independent and DIY-built. It is not affiliated with, sponsored by or endorsed by Google.
Best of Success, folks,
JP
Jaroslav Pantsjoha is a Google Developer Expert in Google Cloud, a Technical Director and an enterprise agent solution architect. He builds and writes about agentic systems, delivery discipline and the operating foundations around them.
I Kept Rebuilding the Same Google Cloud Team. So I Put It in a Plug-in. 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-kept-rebuilding-the-same-google-cloud-team-so-i-put-it-in-a-plug-in-d28489483d7c?source=rss—-e52cf94d98af—4
About the Author
