types of multi agent architectures

Table of contents

overview

Previously, we’ve created a simple research agent equipped with a web search tool to find the latest information based on the user query.

However, what happens when we want it to do more? For example, asking it to “Compare the top 5 climbing shoes by features and pricing”.

The agent would have to:

• Decide which shoes to research
• Search for information on each shoes
• Figure out a way to grab the pricing and features
• Remember which shoes it’s currently researching
• Keep track of what it has found
• Compare and summarize everything
• Format the final output

The research agent context fills up with multiple search result from the tool call, potential errors from trying interact with websites and formatting attempts, all while trying to remember the user query.

It’s stretched too thin, too much noise in the agent memory can degrade its performance and accuracy. E.g. the long conversation with ChatGPT or Claude usually falls off after a certain point.

So how can we overcome the following issues?

We can use multi agent architecture. It allows us to create multiple sub-agents with its own memory and context.

The sub-agents will run independently and only return the final result to the main agent for further processing, and the next section covers how to think about it.

scenario

Remember how a single agent is like a chef with access to kitchen equipment? We can think of multi agent as having multiple chefs, in a kitchen, sharing the same equipment, working together to serve a dish for a customer.

Imagine this, a large scale restaurant serves up to 1000 customers daily. A single chef would probably be overwhelmed trying to handle all the orders.

To handle this demand, the restaurant hire different chefs to spread the workload. With each team member doing a single task and delivering the final result.

• the chef owner decides the menu
• the head chef coordinates the kitchen and ensures dishes are assembled correctly before serving
• the prep cook will do the mass preparation, like cutting the ingredients, blanching stock, mise en place and so on
• the grill chef will handle any grilling of the meat
• the sauce chef will handles any of the sauce creation

Tying it back to multi agents, to answer the research on “rock climbing shoes”, we’d have a:

• planner agent to decide the research strategy (head chef)
• search agents to gather data for each shoe (prep cooks)
• summarizer agent to create the final comparison (assembling the dish)

Hopefully the scenario gave a clearer picture of what a multi agent architecture is.

the different architectures

From here on, we’ll cover a few of the architectures I’ve worked on.

There a lot more architectures out there, if you’re interested in more, see https://agentic-patterns.com/.

architecture 1: plan and execute

The plan and execute pattern separates thinking from execution. Such as, having an architect design a building before the construction crew starts work. It’d be unwise for the either the architect to do both building AND construction, vice versa.

the planner agent:

• engages with the user to clarify requirements by asking questions
• creates a detailed, step-by-step plan
• presents the plan for approval and ask for feedback (if any)

the executor agent(s):

• receives the approved plan as a task list
• works through each task
• refers back to the original plan if it loses focus

example

User query: “Compare top 5 climbing shoes”

Expand for the full flow!

architecture 2: supervisor

The supervisor pattern uses predefined agents and a coordinator that assigns work intelligently. It’s like a project manager with a roster of domain experts.

the supervisor agent:

• receives the user query
• analyzes what expertise is needed
• select appropiate agent(s) from the roster
• evaluates the result

the specialised agents (examples):

• web search agent: find current information online
• data analysis agent: process and analyzes data
• document writing agent: create formatted report

example

User query: “Find recent news about semiconductor export restrictions and analyze how they might affect our tech investments”

Expand for the full flow!

afterthoughts

While multi agent architecture is relatively new to AI but the framing of solutions to a common problem isn’t new. This is called patterns, and it have existed for a while in software engineering, a good example of this is: https://refactoring.guru/design-patterns.

Knowing which pattern / architecture to work from helps us to focus on the implementation and not be stuck on thinking: how should I design this?

Also, I want to highlight a few benefits to using multi agents architecture:

• choosing the right llm for the job.
  • not all llms are created equally, some are equipped with reasoning capabilities (more expensive) and others aren’t (less expensive). by balancing out which model to use for which scenario, not only do we save cost, but also optimise performance and reduce latency.
    • e.g. using opus 4.5 to create a plan and use sonnet 4.5 to handle execution. the thinking has been done, all that’s left is execution
• mitigating context rot through isolated context and memory.
  • context rot occurs if one agent contains all the information when it should only be caring about the final result
  • when a subagent has its own context and memory, it can work the information before returning the final result to the main agent for summarising

next steps

Now that you understand the concepts, let’s see how to build this in practice.

In the next (and final) article of this series, we’ll implement a Plan and Execute multi agent architecture with LangGraph, it’ll contain:

• code examples
• human in the loop approval
• state management between agents

See you next time!