 This video is a conceptual guide to how we think about multi-agent systems. So Lengraph is a framework for building agentic systems, and a big type of agentic systems are multi-agent systems. And so in this video, we'll walk through at a conceptual level what a multi-agent system is, some of the common different architectures, and some of the common things that you might want to think about when thinking about building these multi-agent systems. Just to set expectations, this is purely a conceptual video, so we will just be talking about concepts. Please see other videos and documentation for more technical guides on how to build multi-agent systems. When talking about multi-agent systems, it's helpful to start with what a single- system is. The technical definition that we like best is that a system is more agentic the more that an LLM decides the control flow of an application. However, for simplification we'll start from a more simple definition of an agent, an LLM that calls tools, as this is often the first place that people start when building agents. This is great to get started, but as you scale up the complexity, it can have some downsides. Some of those common issues are too many tools. The agent might have too many tools at his disposal, and as a result, it makes poor decisions about which tool to call next. Anecdotally, we've seen that around five to ten tools is the sweet spot for the maximum number of tools an agent should have. Second, the context could grow too complex for a single agent to keep track of. As you're calling more and more tools and having more and more interactions with the human, the context starts to grow and so it starts to overwhelm the context window of the LLM and it stops performing well. And then finally, we often see a need for multiple specialization areas in the system. For example, having a planner, a researcher, a math expert, a coder, things like that. And for performance reasons, it's often better to break these out into separate agents, rather than trying to rely on them all being present in one big prompt. Some of the benefits of multi-agent systems are that they are more modular, which makes it easier to develop, test, and maintain these systems. They can be more specialized, so you can create these different expert agents focused on particular domains. And then you also have more control. A big part of multi-agent systems is how these agents communicate with each other. And when you use a framework like LandGraph, which gives you really low-level control, you can explicitly control the communication patterns between these agents. Let's now talk about some of the common architectures we see when building multi-agent systems. We've already covered the baseline system, a single agent system, where there is an LLM that calls multiple tools. Another common architecture is a network of agents, where these agents each have their own individual tools, and they communicate with each other by deciding who goes next. Frameworks like Swarm and Crew AI are best known for this type of architecture. In practice, we've seen that this architecture is a little bit too loose in its communication patterns. If a single agent can route to any different agent at any different point in time, there's not a whole lot of control that you can actually have as part of this system. As a result, we've seen that these types of systems are often unreliable, take a lot of time, and cost a lot of money because they're making a lot of calls to the LLM. And so we don't typically recommend these in production. In a supervisor agent approach, you have one single agent whose sole job is to route to other agents. If we compare this to the previous network of agents, this makes it a little bit more manageable for the sub-agents. They can focus solely on doing their job. They don't have to think about who to call next. Who does think about who to call next? That's the supervisor agent, this node right here, which can communicate with all the different subagents. A simplified version of this is when you actually pass these subagents as tools to a central LLM. Your individual subagents are now just tools in a larger system. This is great because it's pretty simple. However, the downside is that when the LLM calls those subagents, what it's passing to those subagents is largely the inputs to the tool call. This means that the agents communicate with each other not through some shared state, but rather through the tool call parameters. We'll go into more on this later. In a hierarchical approach, you just keep on layering up these supervisor agents. So you might have one supervisor agent, which you can call into a separate subagent, but that subagent itself is a supervisor agent, and you can keep on layering this. This is really good when you're working with a lot of these subagents, and you can keep on layering this. This is really good when you're working with a lot of these sub-agents, and you're able to group them in more specialized ways. However, the most common architecture that we see above all is a completely custom cognitive architecture. It's not using an off-the-shelf supervisor or hierarchical agent. It's maybe borrowing aspects of that, but it's very custom to the domain that you're building. We see this level of customization and control being needed to get to production, and that's what we try to give with Lengraph. Let's talk a little bit more about how these agents communicate. One aspect of this is how an agent might call another agent, whether it's in a supervisor or hierarchical approach. There's two main methods that we see happening here. One is when the two agents share some overall state object, and the second is when the second agent just gets the results of a tool call from agent one. So in the first situation, you might have a shared state which has a list of messages, some artifacts, and any other keys that you might desire. And then both agents just write to that state. A separate way of doing this is where the agents communicate solely through tool calling. So agent one might call agent two, and it just fills out the parameters that it wants agent two to see as part of the tool call that it generates. Agent two then takes those parameters and nothing more, goes, does work, and then comes back with a final response, and that's passed back as a tool call response to Agent 1. If we compare some of the architectures that use these, this is the main difference between the supervisor and the supervisor with tool architectures. In the supervisor architecture, the overall state is passed to the sub-agent. But when the supervisor with tools architecture is used, it's just one LLM that's generating tool call parameters, and that's only what's passed to the sub-agent. One common question we get is how might you have two agents that have different states communicate with each other? The answer is that there just needs to be some shared keys that they communicate on, but all the other keys can be completely different so here in this example we have the first agent which has this foo key and let's say it's generating that and it's also using bar and baz it also has this foobar key which hasn't been set yet because that's what the second agent's going to set the second agent is going to read from the foo key it also has its own separate internal keys a b ABC and XYZ, but then it's going to return its result as foobar because that's part of the overall state that the first agent can recognize. The final communication pattern that I want to highlight is what happens when you have two agents that are communicating on the same list of messages. List of messages are a very common state that we see in LandGraph, and oftentimes you might have agents reading from and writing to that same list of message. These agents themselves might be doing tool calls, and then they're generating a final response. And these two different sets of messages, the tool calls and kind of like the internal thought process of the agent and the final response, you don't have to treat those the same. So you could append all of the tool calls and the final response to this shared list of messages. And you'll grow up a pretty big kind of like message list that has agent one's tool calls and agent two's tool calls. Another approach that you could take is just only put the final responses on this shared message sheet. You then could have a separate message list that just tracks this internal tool calls for each agent. That's it for this conceptual guide on multi-agent systems. We think they're pretty powerful to allow you to create more complex agentic systems, and we're excited to see how you use it. We're releasing some improved technical support for multi-agent systems, including subgraph support in Langraph Studio, so I definitely encourage you to check that out. And again, I'd also emphasize that the most common multi-agent architecture that we see getting into production is custom cognitive architectures. So while it's great to think about and read about supervisor and hierarchical agent systems, I'd really think about what type of system you think works best for your domain, and then just build that using a lot of the common techniques that we've shown here, but maybe not taking an off-the-shelf architecture.
Conceptual Guide: Multi Agent Architectures
This video is a conceptual video that covers multi-agent architectures

Full documentation: https://langchain-ai.github.io/langgraph/concepts/multi_agent/