In Google ADK, when do you use a workflow agent instead of an LlmAgent?
answer
- two flavours of composition in ADK
- one reasons, three just orchestrate
- workflow agents call no model at all
- LlmAgent for judgment, Sequential/Parallel/Loop for order
basics
~20 sUse LlmAgent when the model must decide what happens next. Use ADK's SequentialAgent, ParallelAgent or LoopAgent when the order is already known: they run their sub_agents on fixed control flow and call no LLM of their own.
solid answer
~40 sGoogle ADK splits composition into two kinds of agent. `LlmAgent` (exported as `Agent` too) wraps a model with an `instruction`, `tools` and optional `sub_agents`; the LLM chooses which tool to call and whether to transfer to a sub-agent, so control flow is emergent and non-deterministic. The workflow agents — `SequentialAgent`, `ParallelAgent`, `LoopAgent` — are plain orchestrators: they take a `sub_agents` list and run it in order, concurrently, or repeatedly, and they never invoke a model themselves, so they add no token cost and no variance. The practical rule is to push everything you already know into workflow agents and keep the LLM only where genuine judgment is needed. A common production shape is a `SequentialAgent` whose steps are individually `LlmAgent`s: the pipeline is guaranteed, the reasoning inside each step is not.
go deeper
Be able to name the four composition types in ADK — LlmAgent plus SequentialAgent, ParallelAgent and LoopAgent — and say plainly that only LlmAgent involves a model deciding anything.
Explain that workflow agents drive control flow from their sub_agents list rather than from inference, and that the two nest, so a fixed pipeline of LLM-powered steps is the normal shape.
Show the production judgment: quantify what an LLM routing turn costs in latency and tokens, and describe converting a flaky model-chosen ordering into a SequentialAgent so the path becomes assertable in tests.
Own the boundary as a design rule for the team — which decisions are allowed to be probabilistic, how much non-determinism the product can absorb, and how the deterministic skeleton keeps evaluation and incident triage tractable as the agent tree grows.
## The two flavours Google ADK (this answer assumes `google-adk` 2.x) deliberately gives you two ways to decide what runs next, and interviewers ask this question because choosing between them is the main architectural decision in an ADK app. **`LlmAgent`** — imported as `from google.adk.agents import LlmAgent` and also exported under the alias `Agent` — is the reasoning unit. You give it a `name`, a `model` (a model id string such as `"gemini-2.0-flash"`, or a model object), an `instruction` that becomes its system prompt, a `description` used by other agents when routing, a list of `tools`, and optionally `sub_agents`. At run time the model decides: answer directly, call a tool, or transfer control to a sub-agent. That decision is made by an LLM on every turn, so it costs tokens and latency, and it can differ between two identical runs. **Workflow agents** — `SequentialAgent`, `ParallelAgent`, `LoopAgent` — are the deterministic units. Each takes a `name` and a `sub_agents` list and does exactly one thing with it: - `SequentialAgent` runs its sub-agents one after another, in list order, passing the same invocation context through so later agents can see earlier events and state. - `ParallelAgent` runs its sub-agents concurrently, each in its own branch of the event history, over one shared session state. - `LoopAgent` runs its sub-agents in order, then starts again, until `max_iterations` is reached or a sub-agent escalates. None of the three calls a model. Their control flow is code, not inference. ## Why the distinction matters Every LLM decision you keep is a place the system can go somewhere you did not intend. If your requirement is "always fetch the record, then summarise it, then write the summary to the ticket", handing that ordering to a model buys nothing and costs three things: tokens for the routing turns, latency for the extra round trips, and a failure mode where the model skips a step or repeats one. Expressed as a `SequentialAgent` with three sub-agents, the ordering is guaranteed by the framework, is visible in the code, and is trivially testable. Conversely, if the next step genuinely depends on content the model has just read — which specialist should handle this ticket, is the draft good enough yet — that is exactly what an `LlmAgent` with `sub_agents` or with tools is for. ## The composite shape Because workflow agents accept any agent as a sub-agent, and `LlmAgent` accepts sub-agents too, the two nest freely. The idiomatic production structure is a deterministic skeleton with LLM judgment at the leaves: - A top-level `SequentialAgent`: `[research_step, ParallelAgent([...analysts]), synthesis_step]`. - A `LoopAgent` containing `[writer_agent, critic_agent]` where the critic escalates when quality is acceptable. - An `LlmAgent` coordinator whose `sub_agents` are domain specialists, used only where routing is a real judgment call. Workflow agents are also where you get parallelism at all: an `LlmAgent` issues tool calls that a model chose, whereas `ParallelAgent` fans out branches you chose, which is how you turn three independent 4-second lookups into one 4-second step. ## Cost, latency and testing A workflow agent's own overhead is effectively zero — no prompt is assembled, no model is called. Replacing a routing `LlmAgent` with a `SequentialAgent` removes an entire model round trip from every request. That is often the single biggest latency win available in an ADK pipeline. Deterministic composition is also what makes the system testable. A `SequentialAgent` has one execution path, so a test asserts on the outputs of each step. An `LlmAgent` coordinator has as many paths as it has sub-agents, and each path is chosen probabilistically, so testing it means evaluation runs rather than assertions. ## Where people get it wrong The common mistake is treating `LlmAgent` with `sub_agents` as the default structure because it looks more "agentic", then discovering that the router picks the wrong specialist a few percent of the time and that every request pays an extra model call to make a decision the code already knew. The opposite mistake — modelling everything as a fixed sequence — shows up as a pipeline that cannot cope with inputs it was not shaped for, because no step is allowed to decide anything. The answer an interviewer wants is the rule, not the taxonomy: **give the decision to the model only when the decision genuinely depends on what the model just read.**
- Do workflow agents add any token cost of their own?No. `SequentialAgent`, `ParallelAgent` and `LoopAgent` assemble no prompt and call no model — they only invoke their `sub_agents`. All token cost comes from the `LlmAgent`s nested inside them. That is why replacing an LLM router with a workflow agent removes a whole model round trip per request, not just some prompt tokens.
- Can a workflow agent contain another workflow agent?Yes — any agent can be a sub-agent of any composite, so you can nest freely: a `SequentialAgent` whose second step is a `ParallelAgent`, whose branches are `LoopAgent`s over `LlmAgent` pairs. The one structural constraint is that an agent instance belongs to a single parent, so build a separate instance rather than reusing one object in two places in the tree.
- Where does an LlmAgent with sub_agents still make sense?Where the routing decision depends on the semantics of the input — triage across specialists, disambiguating an underspecified request, choosing between escalation and self-service. Keep the sibling set small and the `description` fields sharply distinct, and consider fencing transfers with `disallow_transfer_to_parent` / `disallow_transfer_to_peers` so a wrong hop cannot bounce around the tree.
saying these in an interview costs you the question
- Thinking SequentialAgent asks the LLM what to run next
- Claiming workflow agents need their own model configured
- Using an LlmAgent coordinator for an order you already know
- Assuming ParallelAgent is just Sequential with a faster model
- Believing determinism means you cannot use LLMs inside the steps