Wrapping specialist agents as callable functions that a primary agent invokes on demand. Unlike coordinator-style delegation, the primary agent retains full control.
Instructor:Your coordinator agent delegates to specialists, and you lose all control over the response. The specialist runs its own tools, generates its own output, and the primary agent never sees the intermediate results. Agent-as-tool flips that model. Over the next five minutes, you'll see how it works, when to use it instead of a coordinator, and why the synthesis step matters. The coordinator pattern, which we saw in the last video, transfers full control to a specialist.
Instructor:It works great when that specialist can handle the complete result on its own. But when your response needs output from multiple domains, in our case food, transport, and nearby attractions, you need the primary agent to see everything and drive the sequence. Agent-as-tool keeps the orchestrator in control while still using specialist capabilities. In a simple example, you ask for a trip plan: restaurants, transit, and nearby attractions.
Instructor:That's a multi-domain request where you need results from several specialists combined into one coherent answer. That synthesis requirement is exactly why agent-as-tool fits better here. Than the coordinator pattern we saw earlier. The primary agent owns the entire workflow. The control never leaves. The primary agent decides which specialist to call, in what order, and how to combine the results. Think of it like a craftsman picking tools from a workbench. The craftsman builds the final product, not the tool.
Instructor:The Food Finder gets wrapped with AgentTool and dropped into the primary agent's tools list. The primary agent calls it like any function. Input goes in and a result comes back. The specialist doesn't take over the conversation. The transport tool works the same way. Every agent call is stateless, a fresh invocation with no memory of the previous one. The primary agent manages state within itself, but the specialists don't retain anything between calls. The nearby tool handles directions and points of interest.
Instructor:The primary agent can call these tools in any order it wants, and even fire independent calls in parallel to reduce latency. Now the primary agent combines food, transport, and nearby results into one unified trip plan. That synthesis step is the big differentiator from the coordinator pattern. Here, the primary agent builds the final response, not the specialist. Before we get into the trade-offs, let's see how it works in a real example.
Instructor:So I've got the example, and I already have the servers up and running here. This example is available on GitHub, and the link is in the description below. It's free to run locally. It just requires Ollama, or any other LLM endpoint you want to use. So let's call it from the client and see how it works. For this example, we're using an entry-level model, qwen3.5:0.8b, so basically anyone can run it locally. That way, you can follow along on your own machine without much setup.
Instructor:We can see here that the call has already started, and now it's in progress. And you can see the transport finder, food finder, and nearby tools have all been called, and we're waiting for the final LLM synthesis. Right here. So now we can see the synthesized result. We got the calls, and this is the resolved output. You can see it isn't perfect, and the model choice affects the quality we get. More importantly, it's a lightweight model, so don't over-read the exact answer quality.
Instructor:What matters is that it shows how the pattern works. Let's go back to where we left the explanation. Agent-as-tool gives you maximum orchestration control, but the trade-off is stateless specialist calls. Every AgentTool invocation is fresh: no conversation history, no session memory. If you need specialists to remember previous interactions, this isn't your pattern. There's also latency: you pay for the primary agent call plus every specialist call.
Instructor:But if you parallelize independent work, you can offset some of that cost. Agent-as-tool keeps the primary agent in full control while using specialists as callable functions. It's the closest multi-agent pattern to traditional function composition. And that makes it intuitive for engineers coming from conventional software architecture. Choose it when you need to combine output from multiple domains into one response. Thanks for watching this one, and I'll see you in the next video.
Learning Objectives4
Describe how agent-as-tool composition lets a primary agent call specialists as stateless functions
Implement an agent-as-tool system using ADK's AgentTool wrapper
Compare agent-as-tool and coordinator patterns to choose the right control model
Identify failure modes unique to tool-wrapped agents and strategies to mitigate them
Q&A
Q & A
Q
When should I use agent-as-tool instead of coordinator?
Use agent-as-tool when the primary agent needs to combine results from multiple specialists into a single response — for example, gathering food, transport, and attractions to build a trip plan. The coordinator pattern is better when each specialist can independently handle a complete request. The deciding factor is whether the primary agent needs to stay in control after dispatch.
Q
Does AgentTool preserve the specialist's conversation history?
No. Each AgentTool invocation is stateless — it is a fresh call with no memory of previous invocations. The specialist receives the input, processes it, and returns the result. The primary agent's own session state is preserved across turns, but the specialist does not retain state between calls.
Q
Can I mix AgentTool with regular tools on the same agent?
Yes. AgentTool is just another tool entry in the agent's tools list. You can combine AgentTool-wrapped specialists with regular functions, google_search, or any other ADK tool. The LLM decides which tool to call based on the request.
