Hey folks, it's Sydney from Lingchain.

I'm super excited to chat with you today

about how to choose a multi-agent

architecture. First, I would actually

like to caution you. You might not

actually need a multi-agent pattern for

your system. Many agentic tasks are

actually best handled by a single agent

with well-designed tools. That being

said, when your tasks are increasingly

complex, multi-agent might be the way to

go. So, let's dive into chatting about

our scoring criteria for different

architectures.

So we have four criteria here. The first

is distributed development which is

exactly what it sounds like. Can

different teams maintain different

components or agents independently based

on their specialties? The second is

parallelization.

Can you execute multiple agents at the

same time? The third is multihop

conversational support. So does the

architecture support calling multiple

sub aents in series with the context

from previous calls? And the final

criteria is direct user interaction. So

the question here is can sub aents

converse directly with a user.

So our first pattern that we're going to

look at is sub aents often also called

the supervisor pattern. And in this

pattern a main supervisor agent

coordinates sub aents as tools. All of

the message routing passes through the

main agent which decides how and when to

invoke each sub aent.

Now we can talk about how this

architecture kind of scores along those

different criteria lines.

So we actually give distributed

development here a five out of five. The

sub aents architecture is great when

these different sub aents manages tools

are are managed across teams. The sub

aents architecture also does quite well

with parallelization.

Agents support parallel tool calling and

thus you can invoke your sub aents in

parallel. Multihop conversations are

also easy to organize here. This just

requires multiple cycles of the model

and tool calling loop. Finally, direct

user interaction is definitely where the

sub aents architecture falls short. With

lang chains architecture, you can

technically

achieve direct user interaction via

interrupts in your sub aents, but

there's no easy way for users to

interact directly with sub aents. Our

next architecture is the handoffs

pattern. In the handoffs pattern, agents

can use tool calling to hand off control

to other agents. And you can see that in

the diagram here. The user request is

sent to the entry point agent, which is

agent A. And then all of ages A, B, and

C have the power to hand off to one

another and then also to generate a

final response.

Distributed development is one of the

weak points of the handoffs

architecture. It's a bit difficult to

develop agents independently that need

capabilities to hand off to each other.

Parallelization is also not a specialty

of the handoffs architecture,

but the handoffs architecture is

particularly great for multihop

conversations and direct user

interaction.

In fact, this is probably the best

architecture to choose if you are

looking to have those two features. Our

third architecture which is sort of a

quasi multi-agent architecture is

support for skills. So skills are

specialized prompts and knowledge that

are loaded on demand. A single agent

stays in control while loading context

from skills as needed. This is a

practice called progressive disclosure

and it's becoming increasingly more

popular as a context management

strategy.

The skills architecture scores quite

high on the distributed development

front. Different teams can manage

different skills based on their

specialties.

We score a three out of five here on the

parallelization front. Even though you

can load multiple skills in parallel and

call multiple skills in parallel, it's

kind of a two-step process. And so

that's why we don't give it that five

out of five.

You can certainly have multiple calls in

series to the sub aents aka skills here.

So multihop scores at five out of five.

And then direct user interaction is also

a five out of five. Again, we really

just have that one core agent that the

user can easily interact directly with.

Our final architecture is the router

architecture. In this one, a routing

step classifies input and directs it to

one or more specialized agents and then

results are synthesized into a combined

response. And both the router and

synthesizer steps here can be agentic,

but they also don't have to be. They

could be more deterministic.

We score distributed development for

this case at a three out of five just

because there's no standard protocol for

the agents unlike in the sub aents

protocol or the skill protocol where you

can use tools or skills as standard

protocols. It's a little bit harder to

standardize here. So certainly possible

to do distributed development but not

quite as easy. We do though score

parallelization at a five out of five

here. The router can invoke multiple sub

aents in parallel or just one at a time.

Multihop we've scored at a zero out of

five here. The main point of support for

multihop is that you can have multiple

invocations of an agent in series which

is not super feasible with this

architecture. You can have stateful

routers but it's much more difficult to

manage. We actually recommend and you

can check out our new docs on this if

you do want a stateful router that you

just wrap your router in a tool.

Finally, we score direct interaction

with the user at a three out of five. As

you can see, there's router and

synthesizer steps on either side of the

agent invocation. So, this isn't as

direct as the interaction that we see in

some of our other architectures.

Putting this all together, we're sort of

using the fivestar scale here. Here is a

table summarizing all of our results.

And you can also check out our newly

rolled out multi-agent docs to learn

more about these comparisons.

Again, I would say that probably the

most important thing here is to start

simple. So start with a single agent and

build up from there as your problem gets

more complex. Thanks, folks.