Agents as Tools
1. Agents as Tools
Multi-agent architectures are useful for many different things. You might want to isolate noisy tools from your main agent's context, or you might have tasks that require different expertise, like research versus writing versus code generation. Or maybe you want to use different models for different parts of the workflow to optimize for cost or bring in specific models for their specialized capabilities. Multi-agent architectures let you decompose a problem so that each agent does one thing well. And the overall system better and more reliably. Let's say you want to create an agent that does trends research and writes technical summaries. To do this, it'll need to be able to search the web. You could give one agent both capabilities and a system prompt explaining when to use each. Or you could create agents that specialize and chain them together. The writer would call the researcher when it needs information through a tool. This is also a great context engineering pattern for tools that are noisy, like web search. Instead of letting one noisy tool fill up the main agent's context window with distracting or irrelevant information, you can use this agent as a tool pattern. Each agent has its own isolated context window, so you can have the researcher agent do all of the searching and filtering, then relay back only the relevant information to the writer agent. This helps keep the orchestrator's context window focused. Let's check it out. This file shows two different ways to provide an agent as a tool. First is the simplest version, where you create both agents, then directly pass the sub agent to the orchestrator agent as a tool. Here we have the researcher agent, which has a system prompt and is using the HTTP request tool. Then we create the writer agent, which has a different system prompt and accepts the researcher agent as a tool. You could also have multiple agents and multiple tools passed in here. Another way to do this is to wrap the researcher agent in a function with the @tool decorator. Inside, it creates an agent with web search tools and a research focused system prompt. This version accepts parameters like query and depth, so the orchestrator can control how the researcher works. And the agent is created inside the function, which means it starts fresh every time. That's a design choice, so you get a clean context on every call. Also notice that the callback handler set to none on the researcher. That suppresses the default streaming output, so the writer's result is captured in the result object and you access it programmatically. In practice, you'll decide which agents stream to the client and which run silently. Now, a couple of important things about how data flows between agents. When the orchestrator calls a specialist, it sends a string. The specialist receives that string as the new user message, runs its own agent loop with its own system prompt and tools, and returns a string response. The specialist doesn't see the orchestrator's conversation history at all because each agent operates in its own context. By default, the specialist context resets between calls. If the orchestrator calls the researcher twice, the researcher doesn't remember the first call. Now, let's comment out the first simple delegation pattern, save the file, and then we can run this to see how it works. So, we can see the agent is running and our orchestrator agent has invoked the research agent through the tool. And now that's running and searching the web. We passed in a prompt that says, "What are the latest Transact SDK features? Check the GitHub API." So, the sub agent will use its HTTP tool to do that. So, the research agent came back, passed its results back to the writer agent, which then produced this final report. All right. So, that's agents as tools. It's the simplest multi-agent pattern and the starting point for multi-agent architectures. Over the next three videos, we'll go deeper covering more advanced techniques like graph workflows and agent swarms. Each pattern solves different problems and the choice does matter. So, when should you use this pattern? Agents as tools is the right choice when you have clearly separable domains and you want one orchestrator maintaining control over the final response. The orchestrator decides who to talk to and when. The limitation is that the orchestrator is the bottleneck. Every specialist reports back to it and the specialists can't talk to each other. And because orchestration is still model-driven, you can't guarantee execution order between specialists. If you need guaranteed execution order, parallel fan out, or agents that build on each other's work without going through the coordinator, you need a graph and that's the next video.2. Final slide
Next, define explicit dependencies with graph workflows.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.