Made withLangChainClip

Conceptual Guide: Multi Agent Architectures

L

LangChain

Creator on the LangChain channel

Watch on YouTube ↗

123K viewsOct 16, 20248:58 runtime

Explore the fundamentals of multi-agent systems and learn how to design more powerful and complex agentic applications. This guide provides a conceptual overview of various architectures, from single-agent setups to sophisticated networks. Discover the pros and cons of common…

Chapters

#langchain#clip#aillm

The Case for Multi-Agent Systems

Single-agent systems, defined as an LLM that calls tools, can face limitations as complexity grows:

Too many tools: Performance degrades when an agent has too many tools (sweet spot is 5-10).
Complex context: A long history of tool calls and interactions can overwhelm the LLM's context window.
Need for specialization: A single agent struggles to be an expert in multiple domains (e.g., planning, coding, math) simultaneously.

Multi-agent systems address these issues by offering greater modularity, specialization, and control.

Common Multi-Agent Architectures

Several patterns exist for structuring multi-agent systems, each with different trade-offs.

Network of Agents: Agents communicate freely amongst themselves, deciding who acts next. Frameworks like Swarm and CrewAI use this pattern.
Important
This architecture's loose communication can lead to unreliable, slow, and expensive systems, making it generally not recommended for production.
Supervisor Agent: A single agent acts as a router, delegating tasks to specialized sub-agents. This centralizes control flow and allows sub-agents to focus on their specific tasks.
Supervisor with Tools: A simplified version where sub-agents are implemented as tools for the main supervisor LLM. Communication happens via tool call parameters rather than a shared state.
Hierarchical Agents: A layered structure where a supervisor agent can call another supervisor agent, creating teams of teams for highly complex tasks.

Tip
The most common and successful architecture for production is a custom cognitive architecture. This involves borrowing concepts from standard patterns but tailoring the system's logic and communication pathways specifically to your domain.

Agent Communication Patterns

How agents exchange information is a critical design choice.

Shared State: Agents read from and write to a common state object. Agents with different internal states can still communicate as long as they have some shared keys to pass information.
Tool Calling: One agent invokes another as if it were a tool. Information is passed only through the tool's input parameters, and the result is returned as a standard tool output.

Note
The key difference between a Supervisor and a Supervisor-with-Tools architecture lies in their communication method. The former typically passes the entire shared state to sub-agents, while the latter only passes tool call parameters.

Managing Shared Message History

When multiple agents collaborate on a shared list of messages, you can choose what to record:

Append Everything: Add all messages—including internal thoughts, tool calls, and final responses—to the shared list. This creates a complete, but potentially very long, transcript.
Append Final Responses Only: Add only the final output of each agent to the shared list. Keep each agent's internal monologue and tool calls in separate, private message lists.

Introduction to Multi-Agent Systems

This video is a conceptual guide to how we think about multi-agent systems. So LangGraph 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.

From Single-Agent to Multi-Agent Systems

When talking about multi-agent systems, it's helpful to start with what a single-agent 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 the most common issues are too many tools. The agent might have too many tools at its disposal and as a result, it makes poor decisions about which tool to call next. Anecdotally, we've seen that around 5 to 10 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.

Benefits of Multi-Agent Architectures

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 LangGraph which gives you really low-level control, you can explicitly control the communication patterns between these agents.

Agent Network vs. Supervisor Architectures

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's 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 sub-agents.

A simplified version of this is when you actually pass these sub-agents as tools to a central LLM. Your individual sub-agents 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 sub-agents, what it's passing to those sub-agents 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.

Hierarchical and Custom Cognitive Architectures

In a hierarchical approach, you you just keep on layering up these supervisor agents. So you might have one supervisor agent which can call into a separate sub-agent, but that sub-agent 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 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 borrowing aspects of that but is 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 LangGraph.

Agent Communication: Shared State vs. Tool Calling

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 2, and it just fills out the parameters that it wants agent 2 to see as part of the tool call that it generates. Agent 2 then takes those parameters and nothing more, goes do work, and then comes back with the final response, and that's passed back as a tool call response to agent one.

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.

Handling State Between Different Agents

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, 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.

Managing Shared Message Lists

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 LangGraph, and often times you might have agents reading from and writing to that same list of messages. 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 tool calls and agent two tool calls. Another approach that you could take is just only put the final responses on this shared message state. You then could have a separate message list that just tracks this internal tool calls for each agent.

Conclusion and Key Takeaways

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 LangGraph 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.