Google just open-sourced the Python framework it uses internally to build production AI agents — and the 2.0 release suggests they've learned something the rest of the industry hasn't figured out yet.
The Summary
- Google released ADK (Agent Development Kit) 2.0, an open-source Python framework for building, evaluating, and deploying AI agents with a workflow-based architecture
- The breaking changes from 1.x to 2.0 reveal a fundamental shift: from chat-based agents to graph-based execution flows with deterministic routing and state management
- New features include workflow runtime for composing execution flows, structured agent-to-agent delegation, and human-in-the-loop patterns — the infrastructure layer most agent builders are currently duct-taping together
The Signal
Most AI agent frameworks treat agents like chatbots with function calling. You give them tools, write a system prompt, and hope the LLM figures out the right sequence of actions. Google's ADK 2.0 takes a different approach: workflows as first-class primitives. The graph-based execution engine lets you define deterministic flows — routing, fan-out/fan-in, loops, retry logic — that don't rely on the model remembering what to do next.
This matters because the current generation of agent frameworks has a reliability problem. When your agent is just an LLM with tools, every decision point is probabilistic. The model might call functions in the wrong order. It might forget context. It might hallucinate a tool that doesn't exist. You can prompt-engineer around some of this, but you can't engineer around fundamental architecture.
"Workflow Runtime: A graph-based execution engine for composing deterministic execution flows for agentic apps, with support for routing, fan-out/fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop, and nested workflows."
The breaking changes between ADK 1.x and 2.0 tell the real story. Google didn't just add features — they restructured the entire agent API, event model, and session schema. That's not a minor version bump. That's what happens when you run agents in production long enough to discover that the original abstraction was wrong. The new Task API handles structured agent-to-agent delegation with multi-turn modes and controlled output. You're not hoping agents collaborate correctly; you're defining how they hand off work.
What makes this different from existing frameworks:
- Deterministic execution flows instead of hoping the LLM routes correctly
- Built-in state management and retry logic at the workflow level
- Native support for human-in-the-loop without bolting it on afterward
- Task agents as workflow nodes, treating delegation as infrastructure not prompting
The code-first approach is quietly important. No low-code builders, no visual flow editors, no drag-and-drop abstraction layers. Just Python. This is Google saying: if you want reliable agents, you need to treat them like distributed systems, not magic boxes. You need version control, testing, and the ability to reason about execution paths without parsing LLM outputs.
The Implication
If Google needed to rebuild their agent framework from scratch to make production systems work, everyone else probably does too. The current crop of agent startups building on top of LangChain or AutoGPT-style architectures will either evolve toward workflow-based execution or get replaced by teams who started there.
Watch how fast this gets adopted by teams currently maintaining their own agent orchestration layers. The bi-weekly release cadence suggests active internal use at Google. When a big tech company open-sources something with breaking changes this significant, it's usually because they've already committed to the new architecture internally and want the ecosystem to catch up.