English | EN 
Designing an agentic system depends on several factors, starting from the specifications of the task to automate. Assigning too much responsibility to a single agent leads to more hallucinations, loss of context, harder debugging, and increased processing time sometimes.
A core best practice is therefore to « give each agent a single, well-defined responsibility — the agentic equivalent of the single-responsibility principle in software design. »
The question today is no longer whether to distribute processing across multiple agents, but how — which pattern fits the task, the constraints, and the error handling strategy.
Since a multi-agent system is fundamentally a distributed system, many architectural patterns from that field can be adapted to guide their design. We present here some canonical architectures borrowed from distributed systems that are widely used to build LLM-based multi-agent systems.
Multi-agent system architecture
Routing architecture
In this architecture, a set of specialized agents is coordinated by a routing agent that acts as a classifier. Its sole responsibility is to analyze the incoming task and forward it to the most appropriate specialized agent.
This architecture is useful when the system contains several independent agents with non-overlapping areas of expertise.A concrete example is a natural language search system spanning multiple document bases. Consider a company with three knowledge domains — administration, sales, and after-sales support — each served by a dedicated agent with its own knowledge source. When a user submits a query, the routing agent classifies it and forwards it to the relevant agent, ensuring the response comes from the right knowledge base without the user needing to know which one. One limitation of this pattern arises when a query matches several agents simultaneously. Two complementary strategies can address this. If labeled data is available, a small LLM can be fine-tuned specifically for the classification task, producing a more reliable and cost-efficient router. When data is scarce, a few-shot learning approach — providing the router with representative examples of each domain directly in the prompt — can be used to resolve most ambiguous cases.
Master–Slave Architecture
This architecture relies on a central orchestrator that decomposes a complex task into independent sub-tasks, each delegated to a specialized worker — such as a Database, CRM, or Web-Search agent — for parallel execution. The orchestrator then aggregates all outputs into a single, coherent response.
This pattern is ideal for multi-source research and high-complexity analytical tasks. A real example from our projects is automated portfolio generation: the orchestrator breaks the request into sub-tasks (financial history, risk profile, market data), dispatches each to a dedicated agent, and synthesizes the results into a unified report. The main advantage is throughput — parallelism significantly reduces processing time. The key risks are error propagation from workers and aggregation failures. These can be mitigated by adding a validator agent to review outputs before aggregation, or by involving a human in the loop for high-stakes tasks.
Sequential Architecture
This architecture is used when a task can be broken down into an ordered sequence of subtasks, where each agent’s output becomes the next agent’s input. A real example from our projects is a data ingestion pipeline: one agent resolves data quality issues, a second extracts metadata, and a third transforms and loads the data.
The main drawback is cumulative latency — each agent must wait for the previous one to finish, which can be slower than a single-agent approach. This improves in streaming contexts, where the first agent processes block n while downstream agents concurrently process earlier blocks.
LLM-as-Judge Architecture
This architecture pairs two LLMs: a generator and a validator. The generator produces content or completes a task, while the validator verifies whether the output matches the original prompt’s requirements.
Two risks are worth noting. First, if both models share the same biases, the validator may approve incorrect outputs — using different model families for each role mitigates this. Second, the feedback loop can run indefinitely; setting a maximum number of retries prevents this. A real example from our projects is using an LLM to validate that a generated JSON file contains exactly the fields specified in the input schema.
Peer to peer LLM
In a P2P multi-agent architecture, LLM agents operate as a decentralized set of autonomous nodes, eliminating the single point of failure inherent in centralized systems. Agents communicate directly with one another, giving the system high resilience and scalability — at the cost of increased operational complexity, since no global controller has a complete view of the system’s state.
To address this, dedicated tooling has emerged: LangSmith provides monitoring, tracing, and debugging with visibility into individual agent behavior, while LangGraph enables structured orchestration through a graph-based state machine model — supporting both centralized and decentralized coordination patterns within the same workflow.
Combine, don’t choose
In production, architectures nest naturally. A routing system can hand off to a sequential pipeline, which may delegate one stage to a master–slave pattern for heavy parallelism, with an LLM-as-judge loop validating final outputs.
The key is to understand the business problem, identify which parts can be automated, and select the architecture — or composition of architectures — that best fits each stage of the workflow.