Four Architectural Classifications of Multi-LLM-Agent Systems (MLAS)

Recently, the X (Twitter) timeline has been filled with talk of AI agents. I'm kagaya(@ry0_kaga).

Coming from a software engineering background, I find the architecting of multi-agent systems and compound AI systems—which link multiple agents and components—to be a fascinating theme.

In this post, I will summarize the architectural classifications of Multi-LLM Agent Systems (MLAS) presented in the paper "Multi-LLM-Agent Systems: Techniques and Business Perspectives," partly to deepen my own understanding.

The paper itself is a study by a research team from Shanghai Jiao Tong University and the OPPO Research Institute, analyzing Multi-LLM Agent Systems (MLAS) from both technical and business perspectives.

The paper does not describe the architectural details in depth, so the author has independently interpreted and supplemented some of the explanations.

4 Architectures of MLAS

In "Multi-LLM-Agent Systems: Techniques and Business Perspectives," MLAS (Multi-LLM Agent Systems) are classified into four architectures.
(I don't recall it explicitly stating they were inspired by network topologies, though.)

Regardless of the pros and cons, organizing them by analogy with existing patterns makes them quite approachable.

1. Star Type
   • A central orchestrator controls the entire system.
2. Ring Type
   • Effective when pipeline processing is clearly defined.
   • Fits scenarios assuming a chain of steps like "Input → Preprocessing → Analysis → Proofreading → Output."
3. Graph Type
   • A design with a network structure where flexible and multi-directional collaboration is required, allowing agents to communicate freely with each other.
4. Bus Type
   • Standard flows and procedures are clear, and tasks are assigned in an event-driven manner.

Star Architecture

The Star architecture is a design with a radial configuration centered around a central agent (orchestrator).
As the name suggests, there is an agent responsible for orchestration at the center, which calls upon specialized agents as needed. Since the central agent supervises all tasks and governs planning, it has strengths in orchestration.

Conceptual diagram created by the author

• Centralization of Control
  The central agent divides the overall task and assigns them to individual agents. It also centrally manages communication and progress between agents, making resource management and workflow visualization relatively easy.
• Leveraging Specialization
  Each peripheral agent specializes in a specific function and executes its role upon receiving instructions from the central agent.

Scenarios

• When complex workflow management is required
  Situations where the progress of tasks needs to be tracked centrally.
• Experimental or incremental system deployment
  A design where new agents are added step-by-step around a central agent.

Because roles are concentrated in the central agent, the Star architecture combines simplicity and practicality, making it ideal for initial MLAS construction or simple use cases.

Ring Architecture

The Ring architecture is a design where agents are arranged in a ring, and direct communication occurs between adjacent agents.
This format is highly effective for sequential processing of data and tasks, and its characteristic feature is the ease of implementing simple pipelines.

Conceptual diagram created by the author

• Simple communication flow
  Tasks progress just by each agent communicating with its predecessor and successor, making the communication structure simple and intuitive.
• Scalability
  Since interactions only occur with adjacent agents, adding new agents is relatively easy to consider.

For example, if a document review workflow is configured in a Ring type, processing is handed over sequentially as follows:

1. Preprocessing Agent
   Organizes the format and content of the document.
2. Analysis Agent
   Analyzes the content and extracts summaries or key points.
3. Proofreading Agent
   Verifies the accuracy of language and expression, then produces the final output.

By pipelining tasks in stages such as Preprocessing → Analysis → Proofreading, each agent works in coordination to progress the processing.

Scenarios

• When sequential data processing is required
  Situations where data or tasks are processed in stages.
• Tasks with simple dependencies
  Circumstances where each task can directly use the result of the previous stage.
• Decentralized and incremental processes
  Structures where tasks flow continuously between agents.

Challenges and Mitigations

One challenge of the Ring type is that because it is a pipeline structure based on passing the baton between adjacent agents, if even one agent stops, all subsequent work comes to a halt.

This refers not only to system failures; the more the pipeline relies on the output of the previous stage, the more likely it is that an error in one agent's output will propagate downstream.

Nevertheless, because the Ring architecture allows for flexible design while keeping the task flow clear, it is useful for systems requiring simple processing or gradual task progression.

Graph Architecture

The Graph architecture is a design with a network structure where each agent can communicate freely with one another.
Each agent independently determines "which information is currently needed" and interacts with multiple agents simultaneously. This architecture allows for the most autonomous behavior and is likely what people imagine when they think of "AI agents."

Conceptual diagram created by the author. The agent names in the diagram are for illustrative purposes.

• High Flexibility
  All agents can communicate directly with any other agent in the network. This makes coordination between agents extremely flexible, allowing them to handle complex tasks.
• Decentralized:
  Each agent makes decisions autonomously and collaborates with other agents to perform tasks. This allows for building more flexible systems that do not depend on central control.

Scenarios

• Tasks with complex dependencies
  • In Star or Bus types, the structure mainly follows a predefined workflow.
  • In situations where branches or decisions that a simple "serial pipeline" or "central orchestrator" cannot handle occur frequently, and interactions expand in multiple directions.
  • In the Graph type, any agent can collaborate directly, allowing the system to express and execute complex dependencies while delegating part of the reasoning and judgment to the LLMs.
• Collaboration between diverse agents
  • Cases where agents with independent specialties (translation, summarization, analysis, fact-checking, etc.) must be combined flexibly.
  • Scenarios where "Agent A produces a result, Agent B verifies it, Agent C adds supplementary info, and A and B engage in further discussion..." naturally involve multi-directional exchanges.
  • The Graph type is ideal for scenarios where multiple role-specific agents collaborate and deliberate in parallel to form a consensus.

Challenges and Mitigations

In a Graph architecture, because communication paths are generated freely, the complexity of communication and difficulty of management become significant challenges. It becomes harder to visualize and control "which agent is communicating with which" and "under what logic or thought process." Therefore, establishing mechanisms to grasp and manage agent relationships and reasoning—such as observability and monitoring tools—is essential.

• Difficulty in tracking prompt flows and thought logs
  • Since multiple LLMs think and discuss in a chain, it’s not as simple as managing a single "request-response" API call; it becomes difficult to track "which interaction led to which conclusion."
  • Thought processes can be hidden within the LLM, making them hard to collect as audit logs.
• Trade-offs between context sharing and confidentiality
  • When multiple AIs interact freely, there is an increased risk that sensitive data or confidential tokens provided to one agent might unintentionally leak to another.
  • Preventing this requires strict communication control rules, access restrictions, and automated checks.
• Model updates and version management
  • When running multiple LLMs in parallel, updating one model can lead to compatibility issues with other agents, such as incompatible prompt formats or shifts in output style.

While it provides "high freedom and emergence," the potential for "chaotic coordination and versioning" is a defining characteristic of AI agents in a Graph architecture.

Bus Architecture

Bus architecture has a structure where tasks flow through a central "bus" (data flow path). It takes a format where multiple agents process tasks sequentially while following a pre-defined workflow, such as Standard Operating Procedures (SOPs).

To be honest, I haven't quite grasped this one yet, but as I read it, I thought it would probably be close to pub/sub or event-driven patterns in actual implementation. I believe the goal is to orchestrate the flow of processing centrally while assigning tasks to each agent, keeping the agents loosely coupled and making it easier to achieve standardized flows.

While it may look similar to the Ring type in that it "processes steps in stages," the Ring type moves tasks in a baton-passing manner, whereas the Bus type manages the progression of the workflow or events strictly at the center.

While the Ring type has a strong "pipeline" flavor because agents hand over tasks directly to their neighbors, I perceived the Bus type as having a stronger "event-driven" nature when considering its implementation.

Scenarios

• Loose coupling of agents
  Environments where functions are independent for each agent and do not depend directly on other agents.
• When workflow clarification is needed
  Situations where you want to centrally manage and visualize the process from input to output.

It could be said that the advantage is that it allows for easy visualization of standardized flows that are difficult to implement with other architectures while keeping agents loosely coupled (probably).

Combining Architectures

When implementing actual systems, it is likely that multiple architectures will be combined.

• Example 1: Star Type + Ring Type
  • The central orchestrator directs each agent, while detailed processing is handled by a Ring-type pipeline.

The commonly discussed approach of an agent calling a workflow can be seen as similar to a design where a Star-type orchestrator agent calls Ring-type processing.

While it is easy to visualize the implementation and operation of Star and Ring types, and the Graph type captures the essence of "AI agents," the latter also brings unique challenges.

Architecture	Characteristics, Scenarios, Considerations, and Risks
Star Type	- Characteristics: The central orchestrator directs all agents, and centralized management is easy. - Scenarios: Trial operations, security-focused scenarios, incremental expansion. - Considerations / Risks: Failure or bugs in the central agent affect the entire system.
Ring Type	- Characteristics: Agents are arranged in a ring to build a sequential pipeline. - Scenarios: Workflows where sequential processing is essential, simple additions and expansion. - Considerations / Risks: One agent failure stops subsequent steps / Struggles with complex mutual communication.
Graph Type	- Characteristics: All agents communicate directly with each other; most flexible and redundant. - Scenarios: Dynamic collaboration of diverse expert AIs, large-scale distributed environments, and real-time adjustments. - Considerations / Risks: Communication can easily become complex / Mechanisms for management and observability are mandatory.
Bus Type	- Characteristics: Manages standardized procedures (SOPs) via a central bus; clear inputs and outputs. - Scenarios: Fixed workflows, assigning tasks in an event-driven manner. - Considerations / Risks: Bus failure stops the entire system / Unsuited for flexible mutual communication, watch for central load.

Conclusion

I have introduced the four architectures: Star, Ring, Graph, and Bus.
Thinking about architectures based on network topologies was a fresh perspective for me, so I decided to share it.

I've noticed this becoming more common in papers and OSS implementations, and I feel like designs incorporating event-driven elements could become even more prevalent.

That's all for this time!