Transcription
Last week, there were two very interesting articles on building agents. One of them shows you how to build multi-agent systems. The other one proposes not to build multi-agent systems at all. But I think both of them, although they seem contradictory, are very important to read. And this also shows you how early we are in the process of learning how to build agentic systems.
So, the first one, "How We Built Our Multi-Agent Research System," is from Anthropic, whereas the second one, "Do Not Build Multi-Agents," is from Cognition Labs, who are the creators of Devin. I'll highly recommend reading both of these articles, but in this video, I want to give you a very quick summary of what these articles say about building agentic systems.
Okay. So today, if you're building an agentic system for a complex task, the proposed approach is that you divide it into subtasks, where each of the subtasks is carried out by a separate small sub-agent, and then you somehow combine them. So you have an orchestrator and then an aggregator, and in between, you have multiple agents working together. But this article from Cognition Labs says that it might not be the most optimal approach.
So, in general, here is what a usual approach looks like. You have the orchestrator, which receives a task from the user. Then it's going to break it down into sub-agents. It will assign a task to each of the sub-agents. Sub-agents perform those tasks, and then the aggregator will combine the results. Now, there are two main issues. The first one is that each of the agents is doing their tasks independent of the others. So they don't really have visibility to what each one of them is doing. And the second one is, if one of the agents misunderstands their task, it's going to have a negative impact on the aggregator when it tries to combine those results. So, the example they give in their blog post is looking at building a Flappy Bird clone, and then different subtasks could implement some of the main themes of the model independently of each other, and there might be no coherence whatsoever.
Now, a simpler approach in order to address something like this is to have a running history of context sharing between the agents or sub-agents. So, the way this is going to look like is you have the orchestrator, then it keeps track of the conversations that have happened so far, as well as the actions that have been taken so far, and they are shared among different sub-agents. In this handoff principle that was proposed by OpenAI in their OpenAII Agent SDK is a very similar concept, where you hand off control as well as the context of the prior conversations that have happened to a sub-agent.
Now, the problem with this approach is that you're going to have sometimes long-running tasks. So it becomes very hard to actually keep track of all the conversations and actions that are taken by these different sub-agents. And the second is the decisions that are taken independently. So, going back to the Flappy Bird example, they say when you give your agent the same Flappy Bird cloning task, this time you might end up with a bird and background with completely different visual styles. And the reason is because sub-agent one and sub-agent two are not able to keep track of what they're doing at runtime.
So, they propose a more sequential approach where the same agent initially breaks down the task, then takes on a subtask. So it's not a sub-agent, but a subtask to the same agent. It performs that subtask, updates its memory, and then takes another subtask. Now, in this case, since it's doing sequential execution within the same agent, the only thing that is changing is the subtask. It actually has a conversational history, as well as it has the memory of all the decisions that it has taken so far. So that way, it will be able to keep track of everything that has happened.
But going back to the long-horizon tasks or long-running tasks, you're going to run into context overflow. For this, they propose a compression LLM that is running in parallel, which is compressing all the context of chat history, the memory the agent has worked on so far, and basically providing that as context as the agent is working on a long-horizon task. So, the team came up with this concept of context engineering, which is an extension of prompt engineering. But now you want to make sure that the agent or sub-agents have context of all the actions that have been taken so far, and also the responses that they have seen. And their proposal is that in most of the tasks that we have seen so far, a single agent is probably a more appropriate solution compared to multiple sub-agents.
And one example that specifically highlighted was Cloud Code, which is an amazing system from Anthropic. And actually, we're going to look at the blog post from Anthropic, which makes a case for multi-agent systems. But in here, they say that Cloud Code is an example of an agent that creates subtasks for itself. So it doesn't create sub-agents that are performing tasks in parallel, but it is actually a sequential execution system which simply creates subtasks, performs those subtasks, and then moves on to another one. For code editing, people used to use multiple different models. A smaller model or a bigger model will come up with changes that it wanted to apply, and then a smaller sub-agent model will apply those changes. But it turned out that that was not a great approach. So they proposed that today, the decision-making process and applying more often is done by a single model in one action. They give a few examples of why they think that one model that can divide its task into subtasks is a much better approach compared to creating multi-agent systems.
Let's look at what Anthropic says when it comes to building multi-agent systems. Okay, so the second article is from Anthropic, where they argue about building multi-agent systems. Well, keep in mind, they're specifically talking about a research system that they have built that is available within Claude, and I think this is probably one of the best web search implementations that I have seen. So I'm going to show you an example, and then we're going to look at the article and also look at some of the learnings that they have shared.
So, this is an example query that the Anthropic team shared. Now, we're going to enable web search. And when you execute this, it has an orchestrator which takes the user query, creates a plan based on the user query. So here's the plan. And then it spins up multiple sub-agents which are performing different search results. It has each of the sub-agents has access to a number of different tools. These could be like MCMs, memory update, write, and they are doing these works independently. The orchestrator at the end collects and aggregates these results and generates a final response for the user.
Now, if we were to go with that one huge agent that is producing subtasks, then it will do sequential execution, and the same agent is going to be performing all of these web searches, right? But that's not the implementation Anthropic suggests to use. And if you think about it, the reason is that it's a very different application. The nature of search versus code generation is very different, and that's where I think a multi-agent system like this can work.
So, here's how the architecture looks like. You have the system which is interacting with the user. Then you have the lead researcher, which generates the plan, and then you have sub-agents with memory. Those are executing the plan that was created by the orchestrator or lead researcher. So, in the rest of the video, we're going to look at some of the insights Anthropic provides. And I personally find their engineering blogs to be very helpful. They share a lot of details compared to some of the other companies. And it all comes down to how you architect the system.
But they say that they found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 sub-agents outperformed single-agent Claude Opus 4 by 90% on their internal research evals, which is kind of crazy. So you can almost get double the performance using this multi-agent system compared to a single monolithic agent that Cognition was proposing.
Now, they make the case of why multi-agent systems can potentially work, specifically for search applications. And one of the ideas is that since you're using multiple different agents, each of the sub-agents can explore a different research surface, right? Now, you're going to use a lot more tokens, but that can give you a huge performance boost. And they specifically talk about three different factors which explain this performance boost. So they say, "We found that the token usage by itself explains 80% of the variance, with the number of tool calls and model choices as the other explanatory factors."
So, if you have, let's say, a thousand tools provided to a single agent, I think it's going to be really hard for the agent to figure out. Actually, what I have seen is probably around 10 to 15 is the optimal number of tools that you can give an agent. And if you have specialized sub-agents, that becomes a lot more manageable. But that does not mean that you can use multi-agent systems for every application. In fact, they specifically point out that in certain domains where you need to share the same context or that involve many dependencies between agents, they are probably not a great use case for multi-agent systems.
An example they say is that most coding tasks involve fewer truly generalizable tasks than search, and LLM agents are not yet great at coordinating and delegating to other agents in real time. So, Cognition Labs is specifically focusing on coding agents, and I think that's why the one monolithic agent actually works for them. And here, even Anthropic is alluding to exactly the same point.
Now, let me walk you through some of the more practical points, and I have covered most of these things in my previous videos. And specifically, I gave a talk on building agentic systems at Google. Next, I have recorded that video. So if you are interested in a more deeper dive into the topic, I highly recommend watching that video. They have divided it into two main focus areas: one is prompt engineering, and the second one is evaluation for research agents. And the evaluation piece is very interesting. We're going to look at the evaluation piece later, but I wanted to quickly highlight something, and that is that you don't really need a huge evaluation dataset. In fact, they started with around 20 queries which are representing the real usage. So you need a relatively small evaluation dataset in order to be able to evaluate your agents.
Okay. So first, let's talk about the most critical component of any LLM-based system, and that is prompt engineering, which is more important than ever right now because you want to provide very clear instructions to your agents in order for them to do the task that you assigned them. An example they give is that early agents made errors, and they would create multiple different sub-agents in order to execute tasks or to search on web links that did not exist at all.
Now, how do you tackle those kinds of issues? The first is, "Think like your agent." And this is something that I highlighted in my own talk as well, that you actually need to go and see how you execute a given task as a human, step by step, and only then can you provide very clear instructions to your agent in order to just replicate what you as a human do. Second is, you need to teach your orchestrator how to delegate. Again, it comes down to very clear communication. So, you want to provide detailed task descriptions, and the idea is that you want to make sure that two sub-agents avoid duplicating the same task, and that comes down to how good your orchestrator is at not only planning but also delegating that work.
Next is, "Scale effort to query complexity." I would say task complexity. So, depending on the nature of the task, you want to assign that much scaling or compute. So, for example, they say simple fact-finding requires just one agent with 3 to 10 tool calls. Direct comparison might need 2 to 4 sub-agents with 5 to 15 calls each, and complex research might use more than 10 sub-agents with clearly divided responsibilities. So, when you're designing agentic systems, you want to make sure that you provide enough information in your prompt on how it's going to delegate the task and what is going to be the amount of complexity assigned to each task.
The next item is, "Tool design and selection are critical." What I have seen is people either don't design the tools with the complexity in mind, or they have really good tools for the task, but then the tool description, or the description of input or output to those tools, are really bad. Right now, if the agent is not able to understand when to use a very specific tool, it's going to make mistakes. So, you want to make sure that the prompts that go into both the agent are really great, but also the description of the tools are really clear as well, so that the agent does not get confused when to use a specific tool.
And another interesting idea is that, "Let agents self-improve." So, the agents can change the tool description, or they can also modify which tools are available through different MCM servers. That is, I think, a really interesting idea that if the agent is making specific mistakes, then it can try to modify not only some of its own prompts but also the tools that are available to it.
Specific to search, they say, "Start wide, then narrow down," very similar to how humans perform that, and then "Guide the thinking process." So, that means where applicable, you want to use the thinking capabilities of these thinking or reasoning models. Now, it's not only limited to the orchestrator and aggregator, but even the sub-agents can make use of that. And in fact, in some of the RAG applications that I'm building, I actually started using these reasoning models. So, the same reasoning model can not only do re-ranking but also can do generation in a single step, which is a very interesting idea that I'm going to be introducing to LocalGPT.
And the last proposal that they have for prompting is, "You can use parallel tool execution and also parallel sub-agents." So, they say that in their testing, they were trying to use two different types of parallelization. One was that the lead agent spins up to five sub-agents in parallel rather than serially. So, this is very different from what Cognition was proposing. And then the sub-agents use three-plus tools in parallel. This can definitely reduce the research time, but keep in mind, if you're using a multi-agent system with multiple tool calls, you are going to be exhausting a lot of tokens. So, the cost is going to add up.
Okay, now let's talk about a topic that nobody likes, and that's evals. But if you don't have good evals in place, you can't really measure the improvements you're making. It's going to be just based on your own preferences or "looks good to me" metrics. Creating evals for a multi-agent system is a lot more complex because these are not deterministic systems. So, if you run the same query through the same system multiple times, it might come up with a completely different plan on each iteration, and even the order of execution of the tools or the agent is going to be very different. So, this makes it very complex.
But there is a very simple idea that you can use to evaluate these sub-agents. But before then, they proposed to start small. In fact, like when they were creating this multi-agent research tool, they started with a set of 20 queries representing real-world usage, which is very interesting because a lot of people spend time on collecting a lot of data before they start putting these things into test. And the goal is that you want to have a huge evaluation set that is going to cover all of your edge cases and test cases. But it turns out that they proposed that start with a very small number of examples, and this is going to give you an early indication of how good your system is, and then you can add more and more test cases as you encounter more and more complex situations or edge cases. So, start small, but start early.
Now, the question is going to be, how exactly do you do these evals at scale? And that's why you can use LLM as a judge for a specific evaluation. Now, there is a lot of discussion around the effectiveness of LLMs as a judge and what type of metrics to use. Well, they have a very simple criteria, and which I really like. So, they say that these multi-agent systems are very complex because you have to keep track of multiple different things at the same time. But they found that the single LLM call with a single prompt outputting scores from 0 to 1 and a pass and fail grade was the most consistent and aligned with human judgments.
If you look at LLM-based systems, people are coming up with very novel metrics to measure the performance. But in reality, they are not really measuring anything. So, for example, if you're building a RAG system, people use evaluation criteria like truthfulness, correctness, but as a human being, you're probably interested in, okay, is the response correct or not? So, it could be that simple recall, a binary outcome. So, whenever you can just stick to things that make sense for you as a human evaluator and ask the LLM system or the agentic system to output those evals, rather than coming up with some fancy novel metrics which do not make any sense in reality.
But that also means that you need to have human in the loop. So, they say, "Human evaluation catches what automated evaluation misses." An interesting example is that they say that in our case, human testers noticed that early agent cons agents consistently chose SEO-optimized content forms over authoritative but less highly ranked sources like academic PDF files or personal blogs. And reward hacking is a real thing when it comes to these agentic or LLM-based systems, and it can happen both in the generation part or if you're using LLM as a judge. So, you definitely want to have humans who spot-check the evaluators and make sure that the results the LLM as a judge is producing actually make sense.
And you want to do this thoroughly because they highlight that multi-agent systems have emergent behaviors which arise without specific programming. So, for instance, small changes to the lead agent can unpredictably change how sub-agents behave. And this is a very important point to keep in mind. So, let's say if you're building a multi-agentic system, you change a single component, for example, the orchestrator, you can't just run eval on that simple component, assuming that you did not touch anything else, but it's going to have downstream effects on the rest of the system as well. And that's why if you change one part, you'll have to run end-to-end evals.
Now, a few recommendations or ideas on putting these things into production. One is, "Agents are stateful and errors compound." So, again, if you make a change to one part of the system, it starts producing errors that will compound as you go downstream. So, you want to make sure that you have metrics in place or systems in place that can trace and observe the systems. It introduces its own challenges. So, you can't just recreate the whole agentic systems. And the way they propose is that when errors occur, we can't just restart from the beginning. Restarts are expensive and frustrating for the users. So, they built a system that can resume from where the agent was when the error occurred. And they say, "We also use the models' intelligence to handle issues gracefully." And that kind of goes to that self-improvement. So, they say that, for instance, letting the agent know when a tool is failing and letting it adapt its work, and it seems to work surprisingly well.
Another thing which I found very interesting was how they are deploying these multi-agent systems. So, they say agent systems are highly stateful, with prompts, tools, and execution logic that almost runs continuously. So, let's say you deploy a system, it's running continuously. So, you can't really just upgrade the system as a whole. And this way, I think the traditional software engineering principles are so critical, even if you're building with these multi-agent systems. So, when they're deploying, they're using rainbow deployment strategies, and the idea would be you gradually replace previous updates or previous systems with these new systems, rather than deploying everything all at once.
Another point that they highlight is synchronous execution. So, right now, they say that our lead agent executes sub-agents synchronously, waiting for each set of sub-agents to complete before proceeding. And the reason is that they have to aggregate the results from all of the agents. So, there could be, like, in cases in which you want to run these systems asynchronously, but it seems like for their specific use case, they haven't figured out how to do that.
Anyways, this was a very interesting read. Link to it is going to be in the video description. I also created some videos on how Google and OpenAI propose to build agentic systems. Those are going to be linked here if you are interested in that. Anyways, I hope you found this video useful. Thanks for watching, and as always, see you in the next one.