What I Learned from Google's AI Agent Example: Agents Are Workflows, Not Prompts
A builder-friendly breakdown of planner agents, validation loops, and multi-agent architecture.
I watched Google Cloud Tech's short explainer on building AI agents, and one idea became very clear to me:
An AI agent is not just a large language model with tools.
It is a workflow.
That sounds simple, but it changes how we design agents. Instead of asking, "What prompt should I write?", builders should ask a better question:
What system keeps the agent planning, acting, checking, revising, and stopping correctly?
That is the real shift from prompt engineering to loop engineering.
Source video: AI agents explained: Build your first agent in 8 minutes
1. Start With a Narrow Planner Agent
The first useful idea from the example is the planner agent.
The planner agent does not try to do everything. It has one narrow responsibility: create a practical outline.
In the example, the planner is asked to produce a clear Markdown outline with:
- a title
- a short introduction
- 4 to 6 main sections
- 2 to 3 bullets per section
- a conclusion
This is a small but important design choice.
A beginner might try to build one giant agent that plans, writes, checks, edits, and publishes everything. That usually becomes hard to control. When something goes wrong, you do not know which part failed.
A better pattern is to give each agent a narrow job.
The planner should plan. The writer should write. The checker should check.
This makes the system easier to debug, test, and improve.
2. A Real Agent Needs a Validation Loop
The second screenshot is the most important one.
The example introduces a more robust planner. It is not just:
Planner -> Output
It is closer to:
Planner -> Checker -> Retry if needed
This is where the idea becomes more agentic.
A normal prompt gives you one answer. If the answer is weak, the user has to notice the problem and ask again.
A loop-based agent can inspect its own intermediate output. If the outline fails validation, the system can retry. It can improve the plan before moving forward.
That is the difference between a demo and a workflow.
The key detail is not only the retry. It is the limit.
In the example, the loop has a maximum number of iterations. That matters because reliable agents need stopping conditions. Without a stopping condition, an agent can waste time, repeat itself, or keep trying when it should ask for help.
A good validation loop usually needs three things:
- A clear success condition
- A checker that can evaluate the output
- A retry limit or stopping rule
This is why I think "loop engineering" is a useful mental model.
Prompt engineering starts the work. Loop engineering controls the work.
3. The Full Agent Architecture Is a System
The third screenshot shows the larger architecture.
There is a root agent, in this case a blogger agent. Under it, there are tools or sub-agents for planning and writing. Each part has its own supporting checker.
This is a very practical pattern:
Root Agent
-> Planner Tool
-> Planner
-> Checker
-> Writer Tool
-> Writer
-> Checker
The root agent does not need to know every detail of planning and writing. It coordinates the workflow.
The planner creates the outline. The checker validates the outline. The writer creates the draft. The writer checker validates the draft.
This is much closer to how real work happens.
A human content workflow is not one step either. You plan, draft, review, revise, and publish. AI agents become useful when they model that process instead of pretending one prompt can replace the whole workflow.
My Builder Takeaway
The biggest lesson for me is this:
The hard part of building AI agents is not adding more tools. The hard part is designing the workflow around the tools.
For builders, a useful AI agent needs more than a good model. It needs structure:
- split the task into smaller roles
- give each role a narrow responsibility
- validate intermediate outputs
- retry when the output fails
- stop when the loop reaches a limit
- keep the whole process inspectable
This is also why "agent" can be a confusing word.
Sometimes people use it to mean an LLM that can call tools. But for production workflows, that definition is too weak.
A more useful definition is:
An AI agent is a system that can pursue a goal through repeated steps of planning, acting, observing, checking, and improving.
The loop is the important part.
From Prompt Engineering to Loop Engineering
Prompt engineering is still useful. A clear instruction matters.
But a single prompt is not enough for reliable work.
If you are building an AI coding assistant, a research assistant, a content workflow, or an internal automation agent, the important questions are different:
- What should the agent do first?
- How does it know whether the result is good?
- What happens when the result is wrong?
- How many times should it retry?
- When should it stop?
- When should it ask the user for help?
Those are workflow questions, not just prompt questions.
That is why I think builders should pay more attention to loop engineering.
A prompt can produce an answer.
A loop can produce a process.
A Simple Agent Loop
Here is the simplest version I keep coming back to:
Goal -> Act -> Observe -> Verify -> Improve
Each step has a job.
The goal defines what success means. The action does the work. The observation reads the result. The verification checks whether the result is good enough. The improvement changes the next step.
This loop is what turns a chatbot into a workflow.
Final Thought
The more I study AI agents, the more I believe the winning systems will not be the ones with the longest prompts.
They will be the ones with the cleanest loops.
For builders, the question is no longer:
How do I ask the model better?
The better question is:
What workflow keeps the agent working correctly after the first answer?
That is the real work.
Prompts start the work. Loops make the work reliable.