Imagine this.
You give an agent five tools and one instruction.
Your refund process might run perfectly.
Then, the confirmation email fails.
The agent starts the sequence all over again, repeats an action that already succeeded.
The result? A double refund.
The prototype worked beautifully. The production system did not.
The problem is not the prompt.
The problem is asking the model to run a process it should never be running in the first place!
LLMs are constantly forced into routing, scheduling, and error management.
These are tasks that standard software already handles with perfect predictability.
Yet, we are asking AI to do two conflicting jobs:
- Read the world: Making sense of unpredictable, unstructured data
- Run the process: Orchestrating a rigid, pre-defined sequence of events
The first is where AI shines. The second is where traditional code belongs.
When the next step is known, a model should not have to guess it.
Imagine a single autonomous agent given five tools and one large instruction:
→ retrieve the purchase history
→ check the refund policy
→ issue the refund if eligible
→ send an email
→ then close the ticket
To pull this off, the agent must remember the sequence, inspect every tool result, and infer what comes next.
If that confirmation email fails after the money is sent, the model tries to reconstruct the workflow from its context window instead of resuming from a secure execution state.
The result is that double refund we mentioned earlier.
How ADK 2.0 brings order to chaos
Google’s ADK 2.0 fixes this by taking a whole new approach.
It turns predictable actions back into concrete workflow steps, inserting AI only where interpretation is actually needed:
[Refund workflow graph - source: “Why we built ADK 2.0”]
In the example above, fetching purchase history, issuing the refund, and closing the ticket are normal software actions.
Analyzing the complaint and drafting a personalized confirmation message are handed to the AI.
The result is a beautiful hybrid: fixed execution combined with focused reasoning.
But you might be thinking: isn’t this just a return to rigid automation?
Are we hard-coding the very workflows agents were supposed to replace?
Well, not quite.
The workflow defines the boundaries that are already known.
The agents still handle the parts that require interpretation, language, or judgment.
The goal is not to remove flexibility, it is to stop forcing the model to rediscover the same execution path on every single run.
By eliminating those unnecessary model decisions, this architecture changes the math entirely.
Same refund workflow. Same model.
But with ADK 2.0, tokens went from 5,152 down to 2,265, and latency dropped from 7.2s to 5.7s 🔥
[source: “Why we built ADK 2.0”]
This structure acts as a natural filter that cuts token usage in half.
Instead of passing the entire history, agents only see what they need (e.g., the policy agent only sees the complaint).
The benefits are immediate:
- Less prompt noise and higher privacy
- Tightly constrained execution
- Fail-safes: A model might make a bad call, but it can never invent its own route
The frontend needs boundaries too: How A2UI keeps your UIs under control
That's great. The refund workflow is now under control.
ADK 2.0 defined the path and prevented the agent from inventing its own sequence.
But the user still needs a safe way to see and act on what the agent produces.
In other words, the frontend needs boundaries too!
Imagine that every approved refund now requires a supervisor’s sign-off.
The agent should not simply generate text saying:
“This refund is approved.”
It needs to show a structured card containing
- the amount
- the transaction
- the policy reason
- clear 'Approve/Reject' buttons
This is exactly where Google's A2UI steps in!
With A2UI, the agent returns a declarative JSON payload rather than executable frontend code.
The host validates that payload and renders only components supported by its catalogue.
The agent decides what info appears, and the app controls how it renders.
👇 Below are examples of A2UI rendered cards, showing you the wide variety of UI compositions that A2UI can achieve:
Google’s A2UI-over-MCP Recipe Studio demo shows this architecture in practice:
Source: Google Developers Blog.
👆 You can see that a static selection form is delivered through an MCP Resource, while a dynamically generated recipe card is returned through an MCP Tool.
A2UI renders both natively inside the host application.
Notice the symmetry?
- ADK 2.0 constrains what the agent can do on the backend
- A2UI constrains what it can create on the frontend
In both cases, the model has room to reason, but only inside boundaries the application has defined.
To go back to the refund example we were discussing above, a standard refund might only need a simple approval card.
But a disputed case involving exceptions, attachments, or partial repayments might require a richer experience.
That is where an MCP App can step in to provide a contained workspace for complex interactions:
→ ADK controls what can happen
→ A2UI makes the result visible and actionable
→ MCP Apps handle the complex workspaces
Curious to learn more?
Here is everything you need to explore ADK 2.0, A2UI, and Google Cloud’s broader agent platform:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
It was a privilege partnering with @googlecloud on this project! 🤝
If you want to stay up-to-date on the latest in LLMs, AI agents, and workflows, you can follow me @datachaz for daily insights.
