LLM-driven agent to dynamically route requests to specialist sub-agents at runtime using ADK's transfer_to_agent mechanism.
Stop Hardcoding Your Agents: Master the Coordinator Pattern · 6 minsTranscript10 entries
Instructor:Your multi-agent system grew around a pile of if-else trees. Every new specialist means more branching, more edge cases, and more maintenance. The coordinator pattern replaces all that with one LLM routing call. Over the next five minutes, we'll see how it works, how to design descriptions for accurate routing, and what to check when routing goes wrong. Let's start with a simple question. Static routing, if-else trees, regex, keyword matching, we all know that. It works fine with two or three specialists.
Instructor:It fails when you grow to ten. Every new domain needs more branching logic, and overlapping vocabulary creates ambiguous routes. The coordinator replaces all of that with one simple LLM-based dispatch. The LLM reads the agent descriptions and makes the routing call at runtime. Let's understand it with a simple example. A travel question comes in. It could be about food, transport, or budget. The challenge here isn't quality or speed. It's routing. Which specialist should handle this particular request?
Instructor:The coordinator reads each specialist description for you and uses the LLM to figure it out, where the query belongs. The framework generates a transfer function for all those agents, and the LLM comes back with the target agent name. No keyword matching, no regex. The LLM makes the routing call. If it's a restaurant or dining question, it transfers full control to the food agent. The specialist owns everything from that point. It keeps the state and responds completely independently.
Instructor:A transport question goes to the transport agent. And here's the most critical detail: description engineering, the way you describe each agent. A vague description like handles various tasks is pretty much a recipe for misrouting. A good description is very specific about the domain, names the query types it handles, and clearly marks the boundary. Those descriptions are actually part of the routing prompt. Budget queries go to the cost agent, and here's what's great about it.
Instructor:Adding a new specialist requires pretty much zero routing code changes. All you need is a new agent and a description, and then the model can route to it. You define the agent, give it a clear description, and add it to sub_agents, and the coordinator starts routing to it automatically. The specialist generates the final response. The coordinator just dispatches. It never synthesizes. That's the key distinction from agent-as-tool, where the primary agent actively combines results from multiple specialists.
Instructor:Here, it just routes. Before we get into trade-offs, let's understand it by running an example. The link is available in the description for the GitHub repository. So let's go and see the real example. I'm on the server that's running here, and the server has all the sub-agents up there, and I'm just going to run the client. It will send three queries. The first one is for restaurants, the second one is about public transit, and the third one is about the cost of a trip to Paris.
Instructor:So let's see. Query one is: what are the best restaurants? And by the way, for this example, I'm just running Ollama locally. So the first one comes back, and the second one also comes back. The first one routed to transit. The second one, I believe, is... sorry, let's look at transit. The first one, yes, transit scoped correctly. But that's the point. It routed the second one via transportation and provided an answer. Query three routed via the cost agent, and it also provided an answer.
Instructor:So anyway, it just did what we anticipated. So now let's go back to our original trade-offs. The big win is flexibility. Adding a new specialist needs zero routing code changes. The cost is an extra LLM call for every request just for routing. But bear in mind, it's non-deterministic dispatch. For ambiguous queries, that might be a problem. For some use cases, dynamic dispatch or non-deterministic routing might be an issue, sure, but in most cases, it shouldn't be a deal breaker.
Instructor:And if it is, then this may not be the pattern for you. When routing goes wrong, you can check three things to start with: overlapping descriptions, which is the most likely problem here. If the agents have ambiguous or overlapping descriptions, this can make the LLM give you inconsistent responses and routing. Then check for a missing agent in the coordinator instruction, and then inspect the LLM trace to see what's going wrong with those LLM calls.
Instructor:These are the three places I would always start if I found any problems. That's the coordinator pattern in a nutshell. Static routing dies. The LLM dispatches. Your agent descriptions become your routing code. Design them carefully. Remember the three checks I mentioned. And remember one thing: the coordinator dispatches. It doesn't synthesize. That's the USP of the pattern. Next up, we'll discuss agent-as-tool, where the primary agent keeps full control, and you'll see that in the next video.
Learning Objectives4
Describe how the coordinator pattern enables dynamic task routing via LLM-driven delegation
Implement a coordinator with specialist sub-agents using ADK's transfer_to_agent mechanism
Design agent descriptions that enable accurate LLM-driven routing decisions
Evaluate coordinator routing overhead and debug misrouting failures
Q&A
Q & A
Q
How does the coordinator know which specialist to route to?
The coordinator's LLM reads the description field of each sub-agent and matches it against the user's request. ADK automatically generates a transfer_to_agent function that the LLM can call with the target agent's name. Clear, specific descriptions are essential for accurate routing.
Q
What happens if the coordinator routes to the wrong specialist?
The specialist processes the request in its own domain and returns an answer that may not match the user's intent. To debug: check if specialist descriptions overlap, verify the coordinator's instruction mentions all agents, and inspect the LLM trace to see which transfer_to_agent call was generated.
Q
Can the coordinator route to multiple specialists for one request?
In ADK's default behavior, a coordinator transfers to one specialist per turn. For multi-domain requests, you can either design a specialist that is itself a SequentialAgent or ParallelAgent (hierarchical composition), or use the agent-as-tool pattern where the primary agent calls multiple tools in sequence.
