Conceptual Guide: Multi Agent Architectures

this video is a conceptual guide to how we think about multi-agent systems so L graph 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 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 seate 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 L graph which gives you really lowle 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'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 superviser 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 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 lingraph 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 gener 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 pass 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 Fu key and let's say it's generating that and it's also using bar and bass it also has this foar 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 fuk key it also has its own separate internal Keys ABC and XYZ but then it's going

to return its result as Fubar 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 Lang graph and often times 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 to calls and agent two two 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 dress 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 lra 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