Key takeaways
- Google's ADK ships three workflow patterns: sequential, loop, and parallel.
- Pick by task shape: ordered steps, repeat-until-good, or independent fan-out.
- Stay single-agent until the work genuinely splits into separate subtasks.
- Real resources: Google Cloud's docs, adk-python, adk-samples, and Gulli's free book.
You are mid-project on Google's agent stack. You have already seen the search results for "agent design pattern google": the Google Cloud doc that defines the term, the ADK sample repos, and the 400-page free book everyone keeps reposting. You can name the patterns. What you cannot do from any of those pages is decide which one to ship for the workload in front of you right now.
That is the gap this page fills. By the end you will be able to pick sequential, loop, or parallel for your task, know when to skip the whole multi-agent idea and stay single-agent, and land on the real docs, repos, and the book without another round of tab-hunting.
If you only came for the download, skip ahead to Get the real resources. No framework required. For everyone else, the framework is the point, so start here.
What "pattern" even means in Google's stack
Before you choose one, agree on what you are choosing between. Google Cloud's architecture docs define an agent design pattern as a framework for organizing a system's components, wiring in the model, and orchestrating how agents work together. That is the useful part of the definition: a pattern is a shape for coordination, not a feature you toggle on.
In Google's Agent Development Kit, that shape shows up as workflow agents. Reporting on the framework counts eight fundamental multi-agent patterns, of which three are the workhorses you will actually reach for: sequential, loop, and parallel. Treat the three as solid ground. The exact count of eight is third-party reporting, not a number Google's own primary doc hands you, so build on the three and hold the fuller taxonomy loosely.
Here is what each of the three does, described by the work it runs, not by adjectives:
- Sequential chains steps in a fixed order. Each step feeds the next. The
SequentialAgentbuilds this linear pipeline. - Loop repeats the same step until a condition is met. Think draft, critique, revise, and go again until the output clears a bar.
- Parallel runs independent subtasks at the same time, then gathers the results. A fan-out, then a join.
These are what people mean by "multi agent design patterns" on this stack. The names carry the behavior once you read them as task shapes instead of labels.
Which pattern fits which workload
The one thing the ranking set never gives you is a decision. So here it is as a table. Match your task's shape to the row, not the pattern to your ambition.
| Your task shape | ADK pattern | Stay single-agent when |
|---|---|---|
| Steps run in a set order, and each one needs the output of the step before it | Sequential (SequentialAgent) | The whole chain fits comfortably in one prompt and one context window |
| You repeat the same work until it is good enough | Loop | One pass is reliably good enough, so the retry logic buys nothing |
| Subtasks are independent and share no order | Parallel | The subtasks lean on so much shared context that splitting them just forces you to re-sync state |
Read it as a starting point, not a law. Most real systems mix shapes. A research agent might fan out to gather sources in parallel, then run a sequential write-and-check pipeline over what came back. The table tells you which pattern owns which part of the job. It does not tell you to pick exactly one and force the rest of the workload through it.
The trap is reaching for parallel or loop because they sound more capable. They are not more capable. They are answers to specific task shapes. If your task does not have that shape, the pattern adds moving parts and gives you nothing back.
When to stay single-agent instead
Here is the question the tutorials skip: when is the right number of agents one?
More often than the pattern catalogs imply. The honest rule is simple. Add an agent only when the work splits into genuinely separate subtasks that a single context handles poorly. Separate means the subtasks need different tools, different instructions, or a boundary that keeps one from stepping on another. If the work does not split that cleanly, a single well-scoped agent wins, and it is not close.
The reason is coordination cost. Every agent you add is another interface where messages get passed, misread, and re-synced. That overhead is real work your system now does instead of the task. A single agent skips all of it. It holds the whole job in one context, and nothing gets lost in the handoff because there is no handoff.
I am reasoning here, not quoting a benchmark. There is no measured production figure in hand for how many steps most systems run or exactly how steep the coordination tax gets. But the direction is not in doubt: multi-agent systems pay a tax that single agents do not, and you should make them earn it. Reach for a second agent when you can name the separate subtask it owns. If you cannot name it, you do not need it yet.
Get the real resources: docs, repos, and the free book
Now the navigational half. The resources for "agent design pattern google" are scattered across a doc, two repos, a blog, and some book mirrors. Here they are in one place.
The framework. ADK is Google's open-source Agent Development Kit for building, debugging, and deploying production agents at enterprise scale. It ships client libraries in Python, TypeScript, Go, Java, and Kotlin, so you are not locked to one language. There is no separate "app" to install and no consumer product behind the search for "agent design pattern google app". You build with the framework and run what you build.
The repos, for the github and download crowd. The main repository is google/adk-python, which is actively developed and, as of July 2026, documents a workflow resumability model for long-running agents. The companion google/adk-samples holds ready-to-use sample agents built on top of ADK, which is the fastest way to see a real pattern wired up rather than described.
The doc. Google Cloud's choose a design pattern guide is the primary source for the definition and the framing above. Google Cloud also positions ADK as the scaffolding, tools, and patterns for secure enterprise agents, deployed through Agent Engine. Start with the doc, then the blog if you are heading toward production hosting.
The book, free. This is the "agent design pattern google pdf", "agent design pattern google free", and "agentic design patterns book" query answered in one line. "Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems" is Antonio Gulli's book. The complete materials, all chapters as PDF plus accompanying code notebooks, are published for free, and the author's royalties go to Save the Children. It circulates through public GitHub repositories, so a search for the title and author name turns up the full download. One caution: those repositories are community-hosted copies, so treat the version you grab as a mirror rather than a canonical release, and re-check against the author's own listing when one is available.
A note on the numbers you will see on those repo pages. Star and fork counts move every day, so do not read any specific figure as current. What is stable is which repos are the official ones, and those are the two named above.
What a sequential pipeline looks like in ADK
The most concrete of the three is worth seeing up close. A sequential pipeline in ADK is a SequentialAgent that defines a linear chain: one step, then the next, each consuming what the last produced. If you have ever written a build script where stage two cannot start until stage one finishes, you already know the shape.
The fastest way to feel it is not to write one from scratch. Pull a working agent from google/adk-samples, find one built on the sequential pattern, and read how it passes state between steps. That state handoff is where the pattern lives, and it is far clearer in running code than in any diagram. The API surface is ADK-specific, so the exact calls will not transfer if you build on another stack. The shape of the pipeline will.
How to tell you picked right, and the failure mode to watch
A quick fit check before you commit. You picked right when the steps stay bounded, meaning the count does not creep upward every time you add a requirement, and when the subtasks are truly independent rather than three views of the same context. If either of those starts to wobble, your pattern is fighting the workload, and it is cheaper to notice now than after you have built around it.
Then there is the one failure mode the tutorials never mention: hallucination propagation. In a multi-agent run, one agent's output becomes the next agent's input. If an early agent invents a fact, states it confidently, and passes it downstream, every agent after it treats that fabrication as ground truth and builds on it. The error does not stay put. It compounds, quietly, through every step that trusts the message before it.
This is judgment, not a measured rate. But it is the reason to keep chains short and to validate the handoff between agents, not just the final answer. A single agent cannot propagate an error to a downstream agent because there is no downstream agent. That is one more quiet argument for staying single until you have a reason not to.
Where to go from here
You have the decision, the resources, and the failure mode. The next move depends on where you are.
If you are going deep on ADK internals, the adk-python repository and its July 2026 workflow resumability documentation are where long-running and recoverable agents get real. If you are thinking one level up, about how any of this survives contact with production rather than which framework you picked, that is a different question than pattern selection, and the selection logic here transfers even if you never touch Google's stack. Read on for how agentic systems hold together in production, or start with the free agentic design patterns PDF explainer if the book is what you came for. For a wider look at AI agent frameworks and how the agent loop actually runs, the research goes further than any single stack.
The patterns are Google's. The decision is yours. Now you can make it before you write the code, not after you have rebuilt it.