// blog

"Google ADK first impressions: agents as code, finally"

2 min read
  • google-adk
  • agentic-ai
  • frameworks

I spent a weekend porting one of my homegrown agent stacks to Google's Agent Development Kit (ADK) — the framework that powers agents inside Google's own products — and it's the first agent framework that feels like it was written by people who ship software rather than demos.

What an ADK agent looks like

The core abstraction is refreshingly small. You define an agent with a model, instructions, and tools — plain Python functions with type hints and docstrings become tools automatically:

from google.adk.agents import Agent

def get_weather(city: str) -> dict:
    """Returns current weather for a city."""
    return {"city": city, "temp_c": 21, "condition": "clear"}

root_agent = Agent(
    name="weather_agent",
    model="gemini-2.0-flash",
    instruction="You answer weather questions using tools.",
    tools=[get_weather],
)

No decorator soup, no YAML manifests. The docstring becomes the tool description, the type hints become the schema. Then adk web gives you a local dev UI with traces of every tool call and model turn — genuinely the best local DX I've seen in this space.

The part that sold me: workflow agents

Most frameworks make you choose between "one giant agent" and "hand-rolled orchestration code". ADK ships composition primitives as first-class agents:

  • SequentialAgent — run sub-agents in order, piping state between them
  • ParallelAgent — fan out independent sub-agents concurrently
  • LoopAgent — iterate until a condition or budget hits

The killer feature is that these are deterministic orchestrators wrapping non-deterministic workers. Your pipeline structure is code you can read, test and diff, while the fuzzy reasoning stays contained inside each worker. That inversion — deterministic control flow, stochastic leaves — matches how I've been structuring agents by hand for a year, so seeing it as a framework primitive was validating.

Rough edges

  • Model lock-in gravity. ADK is model-agnostic on paper (LiteLLM integration exists), but the paved road is Gemini + Vertex AI. Straying off it means you fight documentation gaps.
  • Session state feels young. The State dict with app/user/session prefixes works, but long-term memory is clearly still evolving.
  • Docs assume Google Cloud fluency. If you don't already know your way around GCP auth, the first hour is friction.

Verdict

ADK gets the fundamental thing right: agents should be defined in code, composed like code, and tested like code. The multi-agent primitives are ahead of most of the field. I'm keeping my port — and the next post will dig into how ADK's approach compares with wiring tools over MCP.

← All posts