# Google Explains Why It Built ADK 2.0's Deterministic Workflows

**Google says ADK 2.0 adds a structured workflow runtime so AI agents can hand routine business steps to deterministic code instead of an LLM.**

## What Google announced

In a post on the [Google Developers Blog](https://developers.googleblog.com/why-we-built-adk-20/), a senior technical product manager explains why the team built ADK 2.0. The release builds on ADK v1, which brought "intuitive model instantiation, callback controls, and elegant context abstractions" to Python, Java, Go, TypeScript, and Kotlin. ADK 2.0's headline addition is a structured workflow runtime and task-collaboration model, described as workflows that blend the exploratory capabilities of agents with deterministic execution logic. Google says workflows have been available since March in Python and have "just launched" for Go.

## The problem Google says it is solving

According to the post, moving AI agents from prototype to production creates new failure modes: agents can get stuck in infinite loops, bypass business logic because of hallucinations, or fail without raising a clean exception. Google argues that guardrails, skills, and prompting can only go so far, and that the core issue is structural: large language models are often tasked with orchestration work, such as routing, scheduling, and error handling, that traditional code already does well, but doing it through an LLM loop is comparatively slow, expensive, and inconsistent. At the same time, Google says hand-writing a traditional workflow that accounts for every edge case is complex and impractical, so ADK 2.0 tries to offer both flexibility and predictability instead of forcing a choice.

## How the workflow approach differs

Earlier in the post, Google illustrates autonomous agents' inconsistency on strictly ordered business processes with a general example: asking an agent to execute a standard business process 100 times, it says, might produce the exact desired outcome only around 95 times, with the agent occasionally getting confused into skipping a step, or dismissing a failure as irrelevant and moving on.

Google then walks through a customer refund example to make the same point concretely. In a standard autonomous agent setup, a single system prompt tells the agent to follow five steps in order: check purchase history, check policy, issue a refund if eligible, email the customer, and close the ticket. According to the post, this setup means the agent must repeatedly process the entire prompt context, select a tool, parse the output, and decide the next action; if the context window becomes crowded, the agent may skip steps or hallucinate execution paths, and running that logic through an LLM loop also incurs high token costs and latency. The ADK 2.0 workflow version instead maps the same process as a directed graph, with tool-based nodes (fetching purchase history, issuing a refund, updating the ticket) handled by deterministic code, and only the genuinely ambiguous steps, like judging a customer's policy eligibility or drafting a confirmation email, handed to an LLM agent node.

## Key facts

- ADK 2.0 adds a structured workflow runtime and task-collaboration model on top of ADK v1's model instantiation, callback controls, and context abstractions.
- ADK v1 already supported Python, Java, Go, TypeScript, and Kotlin; ADK 2.0 workflows have been available since March in Python and have just launched for Go.
- Google's post illustrates agent inconsistency generally: an autonomous agent asked to run a standard business process 100 times may produce the exact desired outcome only around 95 times.
- The ADK 2.0 workflow version of that same process assigns deterministic steps, such as issuing a refund or updating a ticket, to code, and only ambiguous steps to an LLM agent node.
- Google frames the goal as mitigating context bloat: appending every tool output to an agent's conversation history can degrade attention and increase the odds of loops or redundant tool calls.

## Why it matters

Teams shipping AI agents into real business processes keep running into the same tension Google describes: agents are flexible but not perfectly reliable, while hand-written workflows are reliable but brittle to write and maintain. Because ADK 2.0 lets a developer confine language-model reasoning to the specific steps that actually need judgment, and let normal code handle everything else, transitions between deterministic steps run at ordinary programmatic speed instead of waiting on an extra model call. For teams already using ADK v1's other pieces, this is a way to add that structure without switching frameworks entirely.

## Check your understanding

According to Google's post, roughly how many times out of 100 attempts does an autonomous agent produce the exact desired outcome on a standard business process?

Which ADK 2.0 refund-workflow nodes does Google's post say are handled by deterministic code rather than an LLM agent?

## Sources

- [Why we built ADK 2.0 - Google Developers Blog](https://developers.googleblog.com/why-we-built-adk-20/)

---

- Category: implement (tooling)
- Affects: —
- Published: 2026-07-01T00:00:00.000Z
- Original: https://developers.googleblog.com/why-we-built-adk-20/
- Generated by tinker news