Google ADK Finally Gets It: Skills are here and they’re absolutely wild

“Your AI agent can follow instructions. But can it write new ones?”
— Google Developers Blog, April 2026

I’ve been building AI agents for a while now. And if there’s one thing that every developer hits eventually, it’s the context window wall. You start packing your system prompt with everything your agent might ever need — weather logic, compliance checklists, security review steps, data validation rules ,and before you know it, you’re burning thousands of tokens before the user has even said hello.

For a long time, the industry’s answer was: just make the context window bigger. OpenAI made it bigger. Anthropic made it bigger. Google made it bigger. And that worked ,until agents started needing everything, all at once, across dozens of domains.

Then something smarter happened.

Anthropic quietly published an open standard called Skills , a way for agents to load specialized knowledge on demand, like a doctor reaching for the right textbook instead of memorizing every medical reference ever written. Claude Code adopted it. Cursor adopted it. Gemini CLI adopted it. And now, as of early 2026, Google’s Agent Development Kit (ADK) has gone all in with its own native SkillToolset implementation.

This isn’t a minor feature update. This is a fundamental rethink of how agents should handle knowledge. And if you’re building anything serious with AI agents in 2026, you need to understand it.

Let’s break it all down.

what is google ADK ?

Before we get into Skills, a quick primer for those just tuning in.

Google ADK (Agent Development Kit) is Google’s open-source framework for building AI agents powered by Gemini models. It supports Python, Java, Go, and TypeScript. It handles the coordination between models, tools, memory, and multi-agent orchestration so you don’t have to wire everything together yourself.

Think of it as the “Rails” of AI agent development — opinionated, batteries-included, and designed to get you from prototype to production without reinventing the wheel at every step.

Key building blocks of ADK include:

Agent: the brain, defined by its model, name, instructions, and tools
Session: the conversation memory, storing interaction history
Runner: the execution engine that processes user queries and orchestrates responses
Tools: functions, MCP servers, or now skill toolsets that the agent can invoke

What makes ADK stand out from other frameworks is its native support for multi-agent systems ; agents delegating to other agents, sequential pipelines, parallel processing ; all managed through clean abstractions. But until recently, there was still that nagging problem: how do you give one agent access to deep, specialized knowledge across many domains without bloating every single conversation?

Enter: Skills.

the problem skills solve (and why it’s bigger than you think)

Let’s paint a concrete picture.

Imagine you’re building a medical assistant agent. It needs to handle lab reports, discharge summaries, prescriptions, and radiology notes. Each of these domains has its own vocabulary, reference ranges, output templates, and validation rules.

The naive approach? Dump all of that into the system prompt. Every. Single. Call.

Here’s the math on why that’s a disaster:

understanding the three-level skills architecture

Skills in ADK follow a three-level hierarchy. This structure is elegant in its simplicity and powerful in its impact.

level 1 metadata (always visible, ~100 tokens)

This is the skill’s “business card.” The agent always has access to it. It contains the skill’s name and a short description that helps the agent decide whether to activate the skill at all.

Defined in the YAML frontmatter of SKILL.md:

---
name: weather-skill
description: A skill that provides weather information based on reference data.
---

That’s it. Tiny. Cheap. Always there.

level 2 instructions (loaded on activation, <5,000 tokens)

When the agent determines the current query matches a skill, it calls load_skill() to fetch the full instruction body. This is the "how to do it" layer.

Step 1: Check 'references/weather_info.md' for the current weather.
Step 2: If humidity is requested, run 'scripts/get_humidity.py' with the `location` argument.
Step 3: Provide the update to the user.

Clear, sequential, specific. The agent now knows exactly what to do and where to look.

level 3 resources (loaded per-step, as needed)

This is the deep knowledge layer — reference files, scripts, templates, glossaries. The agent only fetches these when a specific instruction step requires them.

In our weather example:

references/weather_info.md — loaded when the user asks about current weather
scripts/get_humidity.py — executed only when the user asks about humidity

If the user only asks about temperature, get_humidity.py is never touched. Zero tokens wasted.

the four patterns of ADK skills implementation

Google’s ADK supports four distinct patterns for implementing skills. Each has its place depending on your use case.

pattern 1 inline skills

The simplest approach. Define the skill directly in Python code. Perfect for quick prototypes or skills that need to be dynamically modified at runtime.

from google.adk.skills import models

greeting_skill = models.Skill(
    frontmatter=models.Frontmatter(
        name="greeting-skill",
        description="A friendly greeting skill.",
    ),
    instructions="Step 1: Read 'references/hello_world.txt'. Step 2: Return a greeting.",
    resources=models.Resources(
        references={
            "hello_world.txt": "Hello! So glad to have you here!",
        },
    ),
)

Best for: rapid prototyping, dynamically generated skills, simple use cases.

pattern 2 file-based skills

The production-ready approach. Skills live in their own directories with a SKILL.md file and optional subdirectories for references and scripts. This is what separates instructions from domain knowledge and makes skills reusable across projects.

weather-skill/
├── SKILL.md              # L1 + L2: frontmatter + instructions
├── references/
│   └── weather_info.md   # L3: reference data
└── scripts/
    └── get_humidity.py   # L3: executable scripts

Loaded with:

from google.adk.skills import load_skill_from_dir
import pathlib

weather_skill = load_skill_from_dir(
    pathlib.Path(__file__).parent / "skills" / "weather-skill"
)

Best for: production agents, reusable skills, team collaboration.

pattern 3 external/community skills

Skills published following the agentskills.io open standard can be shared across the community and imported directly. This is where the ecosystem play gets interesting ; one developer builds a "Python security review" skill, thousands of agents benefit.

The ADK Skill standard is cross-compatible: a skill built for ADK works in Claude Code, Gemini CLI, Cursor, and 40+ other tools that have adopted the agentskills.io spec.

Best for: leveraging community expertise, standard domains (security, compliance, etc.).

pattern 4 — the skill factory (meta-skills)

This is where things get genuinely wild. An agent that generates new skills at runtime. You give the agent a “skill creator” skill, and it can build entirely new SKILL.md files on demand — a security review skill, a GDPR compliance checker, a Kubernetes deployment validator — whatever the task requires.

The recommendation from Google’s developer blog: always keep a human in the loop to review generated skills before deployment. Treat them like code ; they should go through review, not straight to production.

step-by-step: building your first ADK agent with skills

Let’s get hands-on. We’ll build the exact weather agent from the video transcript, explain every step, and show you what actually happens at runtime.

prerequisites

pip install google-adk

Set up your environment file:

GOOGLE_GENAI_USE_VERTEXAI=false
GOOGLE_API_KEY=your_api_key_here

step 1 create the skill directory structure

my_agent/
├── agent.py
├── __init__.py
├── .env
└── skills/
    └── weather-skill/
        ├── SKILL.md
        ├── references/
        │   └── weather_info.md
        └── scripts/
            └── get_humidity.py

step 2 write the SKILL.md file

This is the heart of your skill. The YAML frontmatter is L1. The body is L2.

---
name: weather-skill
description: A skill that provides weather information based on reference data.
---

Step 1: Check 'references/weather_info.md' for the current weather.
Step 2: If humidity is requested, run 'scripts/get_humidity.py' with the `location` argument.
Step 3: Provide the update to the user.

step 3 add your reference data (L3)

references/weather_info.md:

# Weather Information

- **Location:** San Francisco, CA
- **Condition:** Sunny
- **Temperature:** 72°F (22°C)
- **Forecast:** Clear skies all day.

step 4 add your script (L3)

scripts/get_humidity.py:

import argparse

def get_humidity(location: str) -> str:
    """Fetch live humidity for a given location. (Simulated)"""
    print(f"Fetching live humidity for {location}...")
    return "45% (Simulated)"

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--location", type=str, default="Mountain View")
    args = parser.parse_args()
    print(get_humidity(args.location))

step 5 wire it all together in agent.py

import pathlib

from google.adk import Agent
from google.adk.skills import load_skill_from_dir
from google.adk.tools.skill_toolset import SkillToolset
from google.adk.code_executors.unsafe_local_code_executor import UnsafeLocalCodeExecutor

# Load the skill from the directory
weather_skill = load_skill_from_dir(
    pathlib.Path(__file__).parent / "skills" / "weather-skill"
)

# Create the toolset — note the code_executor for running scripts
my_skill_toolset = SkillToolset(
    skills=[weather_skill],
    code_executor=UnsafeLocalCodeExecutor()  # Use sandboxed executor in production!
)

# Define the agent
root_agent = Agent(
    model="gemini-2.5-flash",
    name="skill_user_agent",
    description="An agent that can use specialized skills.",
    tools=[my_skill_toolset]
)

step 6 add the init file

__init__.py:

from . import agent

step 7 run and test

adk web

Navigate to your agent in the ADK web UI. Now ask it two questions and watch the difference in behavior:

Query 1: “Please let me know the current weather.”

What happens at runtime:

Agent scans L1 metadata — sees weather-skill
Agent calls load_skill("weather-skill") — fetches L2 instructions
Agent reads Step 1, calls load_skill_resource("references/weather_info.md") — fetches L3 data
Agent returns: “Location: San Francisco, CA. Condition: Sunny. Temperature: 72°F…”

Query 2: “What about the humidity?”

What happens at runtime:

Agent already has L2 loaded
Agent reads Step 2, identifies it needs to run the script
Agent calls the code executor on scripts/get_humidity.py --location "San Francisco"
Agent returns: “The humidity is 45% (Simulated).”

The critical insight: get_humidity.py was never loaded for Query 1. weather_info.md barely mattered for Query 2. Each query only pays for what it needs.

a note on code executors

When your skill includes executable scripts, you need to configure a code executor in your SkillToolset. ADK provides several options:

For production: never use UnsafeLocalCodeExecutor. It runs code directly on your system without any sandboxing. If a malicious skill slips through, it has full access to your file system.

google ADK vs. openai agent SDK: the honest comparison

Let’s address the elephant in the room. OpenAI published “Building the Future of Autonomous Apps: A Hands-on Guide to the OpenAI Agent SDK” and it’s been making the rounds. So how does ADK’s Skills architecture stack up?

knowledge management

infrastructure & deployment

model flexibility

he honest verdict

OpenAI’s Agent SDK has a more mature ecosystem, better documentation (for now), and a larger community. If you’re already on the OpenAI stack, switching for Skills alone isn’t worth the friction.

But here’s the thing: no other major framework has a native equivalent to ADK’s SkillToolset. LangChain has “tools.” OpenAI has “functions.” AutoGen has “skills” in name only ,they’re really just tool definitions.

ADK’s three-level progressive disclosure is architecturally different. It’s not about what the agent can do. It’s about managing what the agent needs to know at any given moment. That’s a fundamentally more scalable approach as agents become more capable.

The question isn’t “ADK vs. OpenAI SDK” ,it’s “do you want to pay 10x more in tokens when your agent scales to 50 domains?” If not, the Skills architecture is the direction the industry is heading.

real-world use cases where skills change everything

use case 1 enterprise compliance agent

An agent managing compliance across GDPR, SOC 2, HIPAA, and PCI-DSS. Without Skills, every query loads all four compliance frameworks. With Skills:

User asks about data retention → only GDPR skill activates
User asks about audit logs → only SOC 2 skill activates
Token savings: ~75% per interaction
Added bonus: compliance teams can update individual skills without touching the agent code

use case 2 multi-domain devops assistant

An agent that handles incident response, deployment pipelines, security scanning, and cost optimization. With Skills:

“We have a P0 outage” → incident-response skill (with runbooks as L3 references)
“Deploy to staging” → deployment-pipeline skill (with environment configs as L3)
“Scan this PR for vulnerabilities” → security-review skill (loaded on demand)

use case 3 marathon route planning (from Google Next 2026)

Showcased at Google Cloud Next 2026, an ADK agent with three skills:

gis-spatial-engineering — processes GeoJSON data to create the marathon route
mapping — uses Google Maps MCP tools to find venues and check weather
race-director — validates the route against official marathon planning guidelines

Each skill is loaded only when its part of the workflow is active. The agent moves through them sequentially, loading only what it needs.

the open standard play: agentskills.io

One of the most underappreciated aspects of the Skills architecture is that it’s not proprietary to Google or Anthropic. It’s an open standard at agentskills.io.

This means:

A skill you build for ADK works in Claude Code
A community-published security skill works in Cursor, Gemini CLI, and Codex
Enterprises can build skill libraries that work across any compatible agent framework

The network effects here are enormous. Every new tool that adopts the standard increases the value of every skill in the ecosystem. We’re in the early days, but the trajectory is clear: skills will become the npm packages of the agent world.

Anthropic built the spec. Google ADK adopted it. 40+ tools are now compatible. The race is on for other frameworks to follow.

what to watch out for: the gotchas

It wouldn’t be a complete guide without the warnings.

1. skill description quality is everything

The agent’s decision to activate a skill depends entirely on the L1 description. A vague description like “handles stuff” will result in the wrong skills being loaded (or the right ones being missed). Treat skill descriptions like search engine keywords — specific, clear, trigger-focused.

2. don’t use UnsafeLocalCodeExecutor in production

It does exactly what it says. Any script that runs through it has the same file system access as your agent process. For production, use VertexCodeExecutor or AgentEnginesSandboxCodeExecutor.

3. review AI-generated skills like code

The Skill Factory pattern is powerful, but generated skills can have subtle issues — incorrect reference paths, overly broad triggers, poorly structured steps. Always treat generated SKILL.md files like a junior developer's PR: review before merge.

4. L3 resources aren’t version-controlled by default

If your skills reference external files that change frequently, build versioning into your skill directory structure. An agent using a stale reference file is worse than an agent with no reference file — it’s confidently wrong.

what this means for the future of agent development

The Skills architecture is more than a performance optimization. It’s a glimpse of how agents will be built at scale.

Right now, we think of agents as things we program — we write their instructions, define their tools, set their personas. But as agents become more capable, the bottleneck shifts from “can the agent do this?” to “does the agent know how to do this, right now, in this context?”

Skills answer that question with a new primitive: modular, on-demand, composable expertise.

In 12 months, I expect to see:

Skill marketplaces — verified, community-rated skills for every domain
Skill versioning — semantic versioning for skill updates, with backwards compatibility
Skill composition — skills that depend on and call other skills
Skill monitoring — analytics on which skills activate, how often, and with what accuracy

Google ADK’s adoption of the Skills standard isn’t just a feature announcement. It’s a signal that the industry is converging on a new architecture for knowledge-intensive agents. The frameworks that don’t adopt some version of progressive disclosure will find themselves at a serious cost and scalability disadvantage as agent use cases become more complex.

getting started today

Here’s your action plan:

Install ADK: pip install google-adk
Read the official docs: google.github.io/adk-docs/skills
Clone the samples: github.com/google/adk-samples
Explore the open standard: agentskills.io
Take the official training: Google’s GEAR program includes a full ADK learning path with skill badges at skills.google
Explore the community: Check Anthropic’s skills GitHub repo for inspiration on skill structure across domains

wrapping up

Google ADK didn’t just add a new feature. It joined a movement.

The Skills architecture , born as an open standard from Anthropic, adopted by Google, spreading across 40+ tools , represents a genuine shift in how we think about building intelligent agents. Not smarter prompts. Not bigger context windows. But smarter management of what agents need to know, when they need to know it.

The weather agent we built in this article is almost embarrassingly simple. But the architecture behind it scales to enterprise compliance, medical documentation, multi-cloud devops, and whatever comes next.

If you’re building agents in 2026 and you’re not thinking about Skills, you’re leaving a lot of tokens and a lot of money on the table.

The pattern is here. The standard is open. The tools are ready.

Time to build.

Google ADK Finally Gets It: Skills are here and they’re absolutely wild

“Your AI agent can follow instructions. But can it write new ones?”
— Google Developers Blog, April 2026

what is google ADK ?

the problem skills solve (and why it’s bigger than you think)

understanding the three-level skills architecture

level 1 metadata (always visible, ~100 tokens)

level 2 instructions (loaded on activation, <5,000 tokens)

level 3 resources (loaded per-step, as needed)

the four patterns of ADK skills implementation

pattern 1 inline skills

pattern 2 file-based skills

pattern 3 external/community skills

pattern 4 — the skill factory (meta-skills)

step-by-step: building your first ADK agent with skills

prerequisites

step 1 create the skill directory structure

step 2 write the SKILL.md file

step 3 add your reference data (L3)

step 4 add your script (L3)

step 5 wire it all together in agent.py

step 6 add the init file

step 7 run and test

a note on code executors

google ADK vs. openai agent SDK: the honest comparison

knowledge management

infrastructure & deployment

model flexibility

he honest verdict

real-world use cases where skills change everything

use case 1 enterprise compliance agent

use case 2 multi-domain devops assistant

use case 3 marathon route planning (from Google Next 2026)

the open standard play: agentskills.io

what to watch out for: the gotchas

what this means for the future of agent development

getting started today

wrapping up

further reading and resources

Leave a Comment

“Your AI agent can follow instructions. But can it write new ones?” — Google Developers Blog, April 2026

what is google ADK ?

the problem skills solve (and why it’s bigger than you think)

understanding the three-level skills architecture

level 1 metadata (always visible, ~100 tokens)

level 2 instructions (loaded on activation, <5,000 tokens)

level 3 resources (loaded per-step, as needed)

the four patterns of ADK skills implementation

pattern 1 inline skills

pattern 2 file-based skills

pattern 3 external/community skills

pattern 4 — the skill factory (meta-skills)

step-by-step: building your first ADK agent with skills

prerequisites

step 1 create the skill directory structure

step 2 write the SKILL.md file

step 3 add your reference data (L3)

step 4 add your script (L3)

step 5 wire it all together in agent.py

step 6 add the init file

step 7 run and test

a note on code executors

google ADK vs. openai agent SDK: the honest comparison

knowledge management

infrastructure & deployment

model flexibility

he honest verdict

real-world use cases where skills change everything

use case 1 enterprise compliance agent

use case 2 multi-domain devops assistant

use case 3 marathon route planning (from Google Next 2026)

the open standard play: agentskills.io

what to watch out for: the gotchas

what this means for the future of agent development

getting started today

wrapping up

further reading and resources

Leave a Comment

“Your AI agent can follow instructions. But can it write new ones?”
— Google Developers Blog, April 2026