DEV Community: Sonika Janagill

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.

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: