Google recently launched a free Agent course.
The course starts from Prompt and Agent Loop to Graph Workflow, multi-agent and self-evolving systems. At first glance, it looks like introducing a new Agent development method.
But putting together the official information of Google ADK 2.0, Google Cloud architecture guidelines, and several recent Agent evaluation studies, I think what is really worth paying attention to is not a certain API, but a bigger change:
Agent development is moving from "tuning models" to the stage of "designing systems".
In the past, most AI applications looked like this:
Input → Prompt → Model → Output.
Translation, summary, classification, information extraction, and content rewriting can usually be completed in one call.
Development is fast, the cost is easy to estimate, and if something goes wrong, just call it again.
But after tool calls appeared, Agents began to truly enter the business process.
It can search for materials, call APIs, execute code, query databases, and then decide the next step based on the results returned by the tool.
Models are no longer just "answering questions."
It starts to "do things."
Once the model is involved in execution, the problem is completely different.
The context will continue to grow, and tool results will continue to enter historical records. Agents may call the tool repeatedly, deviate from the goal halfway, or even end the task early before it is completed.
Enterprise processes will further add requirements such as authority, approval, status, retry, recovery, and audit.
Customer service refunds, invoice verification, employee onboarding, and order processing are not simple questions and answers.
So the real difficulties for Agents have gone from:
"How to get the model to get the correct answers more times?"
became:
"How to make a business process involving a model run stably?"
This is also what I think Google ADK 2.0 deserves attention.
1. What is the difference between Prompt, Agent Loop, and Graph?
Many people talk about Agents now, and it is easy to mix Prompt, Agent Loop and Workflow together.
In fact, they solve three different levels of problems.
Prompt solves "understanding"
Prompt told the model:
What do you want to do, what should you do, what format to output, and what limitations are there.
If the task itself is simple, such as translation, summary, classification, and rewriting, then Prompt is often enough.
Agent Loop solves "actions"
When a model has tools, it can:
Understand the goal → make the next step → invoke the tool → read the results → decide the next step.
This is a typical Agent Loop.
It is particularly suitable for open tasks.
Such as searching for data, code repairs, and complex data analysis.
Because it's difficult to write every step in advance, the model needs to dynamically adjust the plan based on field results.
Graph Workflow solves "execution"
Workflow focuses on:
How should the whole process run?
What steps must be taken?
Which tasks can be parallel?
Under what circumstances do you enter a branch?
When is manual approval necessary?
Where to try again after failing?
What states need to be saved?
These issues cannot be left to the model to decide on the spot.
They are more suitable for writing into programs.
So the three can be simply understood as:
Prompt is responsible for understanding, Agent Loop is responsible for actions, and Workflow is responsible for constraint execution.
The three do not replace each other, but can be superimposed.
Problems that can be solved with one model call do not need to be forced to build Workflow.
A single Agent can already complete tasks stably, and there is no need to break them into multiple agents for the sake of "agency".
2. When does Prompt begin to expire?
The biggest problem with Prompt is not that it is not strong enough.
But as business processes become more complex,The process itself is beginning to be hidden in Prompt.
For example, a refund process:
The user submits a refund → checks the order → judges the policy → decides whether to refund the refund → executes the refund → sends a confirmation email → updates the work order.
If you leave all this to an Agent and let the model decide its next step, it seems very flexible.
But problems will soon arise in the production environment.
It is difficult for developers to determine:
Will this step be implemented every time?
Has the authority check been completed before refunding?
Will there be repeated refunds after the tool fails?
Where should I continue after the email fails?
After the database update fails, do the previous operations need to be rolled back?
These are no longer Prompt issues.
It's a software engineering issue.
So truly reliable systems usually adopt a more realistic division of labor:
Models are responsible for uncertainty, and code is responsible for certainty.
For example:
The understanding and analysis of the complaint content can be handed over to the model.
Order inquiries, refund execution, and database updates should be controlled by the program.
3. Agent Loop is very flexible, but the production environment must be "put on the reins"
The charm of Agent Loop is that it does not need to know all the paths in advance.
The model can continuously adjust the plan based on the results returned by the tool.
For example:
"Help me investigate the recent financing situation of this company."
Agents can search web pages, query databases, organize data by themselves, and then continue searching when they find insufficient information.
If this kind of task is completely written to death, it will be very cumbersome.
But Loop also has a natural risk:
It doesn't know when it should stop.
Therefore, the Agent Loop in the production environment usually needs to be clearly set up:
- Maximum execution steps
- Total timeout
- Token / API Budget
- success conditions
- failure conditions
- Manual upgrade path
Otherwise, a wrong judgment may become:
Call the tool → get wrong results → call again → fail again → continue trying.
The end result is:
Costs rise, delays increase, but tasks are not completed.
So:
When the path is uncertain, let the model make the decision.
When determining the path, don't let the model guess.
This is actually a very important principle in Agent engineering.
4. What does Graph Workflow really solve?
What Graph Workflow does is actually very simple:
Transform the process originally hidden in model decisions into software structures that developers can see, test, and modify.
For example, a refund process can be designed as:
query order
↓
Analyze user complaints
↓
Determine refund conditions
↓
丨 ── Conditions are met → Refund execution
│
── Not satisfied → Close the work order
↓
Generate confirmation email
↓
Update work order status
In this way, every node becomes clear.
What steps must be taken?
What steps can be parallel?
Where do I need manual confirmation?
Where to recover after failure?
What results need to be sustained?
can be clearly expressed.
This is also the greatest value of Workflow:
It does not make Agents smarter, but makes Agents more controllable.
5. Why is Google ADK 2.0 worthy of attention?
An important change in Google ADK 2.0 is to officially place Workflow Runtime at the core of Agent development.
Python 2.0 will enter GA on May 19, 2026, and Go 2.0 will enter GA on June 30.
From the official design point of view, Agents, tools, and functions can all become nodes in the workflow, and then control the entire process through execution relationships.
Sequential execution, conditional routing, parallel tasks, cycles, dynamic workflows, nested processes, and manual intervention can all be incorporated into a unified operating model.
More importantly, it began to focus on the status and recovery of long tasks.
Because a real corporate task may not be completed in seconds.
It may run for tens of minutes or even longer.
There may be a pause halfway.
May wait for manual approval.
An external system may be temporarily unavailable.
At this time, the system must know:
Where did the implementation go before?
Without checkpoints and state recovery capabilities, once the Agent is interrupted, it can only start over.
This is why enterprise-level agents will eventually become more and more like traditional software systems.
It requires:
Status.
events.
Checkpoints.
Try again.
Authority.
Journal.
Audit.
Recovery.
6. Long context does not mean reliable memory
Here is another question that is very easy to ignore:
Context Rot。
Many people believe that as long as the historical record is stuffed into the context, the Agent "remembers everything."
In fact, things are not that simple.
As inputs get longer, the model's ability to accurately find truly important information from context may decline.
Agents are more likely to encounter this problem than ordinary chat.
Because every tool call may bring new data.
Search results, web content, database records, API return values, intermediate reasoning...
If everything is constantly added to the context, it will eventually form a huge information garbage dump.
The longer the context, the smarter it is not necessarily.
Sometimes it's easier to make mistakes.
So Workflow can be alleviated in three directions:
First, nodes isolate contexts.
Each node only reads the information it really needs.
Second, use structured states.
Don't slip the full chat history back to the model every time.
Third, establish checkpoints.
Save the confirmation results after one node is completed, and the next node continues from the confirmed state.
But there is another important difference:
Saving chat records does not mean having the ability to recover.
The real recovery mechanism also needs to be considered:
Checkpoints, event logging, idempotent operations, and replay strategies for external systems.
7. The more multiple agents are not the more advanced they are
There is also a trend that is easily misunderstood:
It seems that the more agents there are, the more advanced the system will be.
This is not the case at all.
The real value of multi-agent isClear division of responsibilities。
For example:
An Agent is responsible for retrieving.
An Agent is responsible for the analysis.
An Agent is responsible for execution.
This way, each Agent can have different tools, permissions, and contexts.
Problems also arise:
Call more.
There is more communication.
Status synchronization is more complex.
Troubleshooting becomes more difficult.
Concurrency will also cause current restriction, resource competition, and consistency issues in the future.
NeurIPS 2025 's MAST research analyzed more than 1,600 multi-agent execution trajectories and summarized 14 types of failures.
Many of these problems are not that Prompt is poorly written.
Instead:
The division of tasks is unreasonable, Agent collaboration fails, state management is chaotic, and results cannot be verified.
So I very much agree with one simple principle:
Without clear responsibility boundaries, don't use multiple agents for the sake of "multiple agents".
If a problem can be stably solved with one Agent, use one first.
Only when the task really has a clear division of roles, authority isolation, or complex collaboration can you consider splitting it.
8. Agent evaluation cannot just look at "No answer"
In traditional LLM applications, it is easy to do an accuracy test.
Agents are different.
Because it must not only "answer correctly", but also "get things done."
For example, a customer service refund Agent.
It finally replied:
"The refund has been completed for you."
No matter how beautiful this sentence is, it is meaningless.
What really needs to be verified is:
Is the refund actually implemented?
Is the refund amount correct?
Are there duplicate refunds?
Did you override your authority?
Has the work order been updated?
Did the user receive any notification?
Is there a complete record of the entire process?
Therefore, when companies evaluate Agents, I suggest comparing a batch of real and desensitized historical tasks.
For example, 20 to 50 tasks.
Compare at least three implementations:
- Single model call
- Single Agent with Tools
- Graph Workflow or Multi-Agent
And use the same set of tasks and acceptance criteria.
Key records:
- Success rate for first completion
- Final mission success rate
- Manual modification time
- end to end latency
- Total cost of models and tools
- number of retries
- At which node did the failure occur
- Number of unauthorized operations
- Whether the source and execution trajectory are complete
Especially for high-risk businesses, you can't just record "success/failure."
It should also retain:
Scoring basis, original evidence, execution track and manual review records.
Because after it's actually online, you need to answer more than just:
"Is it doing it right?"
Also answer:
"Why do you do this?"
9. The best starting point for enterprises to implement Agents is not to "build a super Agent"
If I were to be a corporate Agent now, I would not consider first:
"Should we build a multi-agent system?"
I would ask first:
Does the company have an existing manual process with clear boundaries and verifiable results?
For example:
Invoice verification.
Customer service refunds.
Contract review.
Employees are on board.
Collate sales leads.
Run the manual process clearly first.
How long will it take?
What is the cost?
What are the most common mistakes?
Which steps waste the most labor?
What steps are the determination rules?
What steps require human judgment?
Once you have this benchmark, you can decide where to use the model.
Then:
If you can use one Agent to solve it, don't rush to tear down multiple agents.
If you can solve it in code, don't let the model decide.
Only when the process appears clear:
Branch, parallel, approve, retry, resume
When needed, introduce Workflow.
If irreversible actions such as payment, database writing, sending emails, and submitting work orders are involved, you need to design in advance:
Permission verification, idempotent key, manual confirmation, rollback path.
At this time you will find:
The engineering of agents is essentially getting closer to traditional software engineering.
Finally: What is the real next stage for Agent?
Over the past two years, we have been studying:
How to make models smarter?
How to make Prompt more effective?
How to make agents better use tools?
But then, the real concern for companies may become:
How to make an Agent complete a task stably?
These two things are completely different.
Just because a model occasionally performs amazing doesn't mean it can enter the production environment.
Just because an Agent can complete one task does not mean that it can stably complete 10,000 tasks per day.
What companies really need is:
Stable success.
controllable costs.
Traceable process.
Recoverable state.
Minimum authority.
Reliable retry.
Full audit.
Manual intervention.
Continuous evaluation.
So I prefer to think of Agent as a new software system rather than a chat window that calls tools.
Prompt allows the model to understand the task.
Agent Loop allows the model to act based on results.
Graph Workflow constrains the entire execution process.
Only by putting the three in the right position can we gain both the flexibility of AI and the certainty of traditional software.
What really deserves attention about Google ADK 2.0 may not be how many APIs it has added.
Instead, it sends a very clear signal:
Agents are changing from "chatbots that can call tools" to "software systems that can be engineered, operated, and audited."
Graph Workflow is just one step on the road.
In the end, what determines whether an Agent can be online is still not how amazing the Demo is, but:
Success rates, manual rework, delays, costs, and safety records.
This may be the most noteworthy competitiveness of Agents after they truly enter the enterprise production environment.