Single/Multi-Agent Design
🎯 Difficulty Level: Easy
⏱️ Reading Time: 5 minutes
👤 Author: Rob Vettor
📅 Last updated on: December 1, 2025
Blah
<!— Links:
https://medium.com/data-science-collective/stop-prompting-start-designing-5-agentic-ai-patterns-that-actually-work-a59c4a409ebb
—>
Don’t overload a single AI Agent with a bunch of MCP Servers
Use these multi-agent design patterns for clever orchestration...
Cursor AI, MS Copilot, Harvey AI, and many other companies are now rapidly moving towards multi-agent development and execution.
📌 This is because of 4 core reasons:
- Scalable automation through specialised agents
- Improved decision-making via collaboration
- Parallel Processing for Faster Results and
- Real-Time Adaptation to Changing Inputs and Environments
📌 But why should you choose a multi-agent workflow?
-
A single-agent system handles all tasks alone, limiting scalability and specialisation, while a multi-agent system uses coordinated, specialised agents for modular, efficient, and smarter workflows.
-
Companies are shifting to multi-agent architectures to tackle complex problems faster, scale capabilities dynamically, and build systems that mimic real-world team collaboration.
However, there are numerous ways to design a multi-agent system- which one to choose?
📌 Let me share 6 popular design patterns to help you move faster:
- Sequential
- Agents are chained one after another, where each agent refines or transforms the result in turn.
Use-cases: Data processing / ETL pipelines and Automated Q&A verification.
- Router Pattern
- A central “router” agent delegates to the correct specialist based on the query.
Use cases: Customer support agents and Service orchestration agents, where an API-gateway-style Router agent decides whether to call Authentication, User Profile, or Payment agents.
- Parallel Pattern
- A “Divisor” splits work into independent parallel subtasks, then aggregates results.
Use-cases: Real-time Information retrieval and Financial risk analysis agents or legal agents.
- Generator Pattern
- An iterative “divisor → specialist agents → generator → feedback” cycle for draft–refine workflows.
Use cases: Code generation agents, Automated design and documentation agents.
- Network Pattern
- A fully meshed “meta-agent → specialists ↔ specialists” collaboration model.
Use Caes: Architectural design, with separate Design, Security-Review, and Compliance agents all able to call each other bidirectionally under the oversight of a Meta-Agent.
6. Autonomous Agents Pattern - Decentralised agents interact in loops without a central orchestrator—ideal for fully autonomous coordination.
Use Caes: Autonomous embodied agents where multiple agents collaborate to sense and move around a certain path without human intervention.
If you are a business leader, we’ve developed frameworks that cut through the hype, including our five-level Agentic AI Progression Framework to evaluate any agent’s capabilities in my latest book.
🔗 Book info: https://amzn.to/4irx6nI
Architectural Evolution from Single to Multi Agent Systems
Strategies, Trade-offs, and Best Practices for Intelligent System Design
Introduction
When designing architecture of intelligent systems, developers should consider where their system should be on the spectrum of single-agent and multi-agent systems. Software systems may start as single agent systems and evolve into multi-agent systems. On this path there are implications on scalability, maintainability, adaptability, performance, and overall user experience. This document provides practical guidance for developers, outlining how to approach system design and growth including strengths and limitations of the architectures. For multi-agent architectures, this document examines two key paradigms for coordination: domain based agentic workflows and LLM-driven agent orchestrator workflows, highlighting their trade-offs and ideal use cases. We illustrate the decisions with real-world examples.
Executive Summary
The following decision flow summarizes the suggestions for choosing agentic architecture.
If task is well-defined narrow scope:
Use single agent
If task requires low latency:
Use single agent
If task decomposes to several clearly defined subtasks:
Use an agent per subtask
If task has a known execution order:
Use a classic programming approach with step-by-step execution
If task does not have a beforehand known sequence of steps:
Use dynamic multi-agent orchestrator
Single Agent Architecture
What is Single Agent Architecture?
A single agent architecture refers to an intelligent system composed of a single entity responsible for perceiving its environment, making decisions, using reasoning and acting to achieve a set of goals. This agent uses logic, knowledge, and actions necessary to fulfill its objectives.
When to Use Single Agent Architecture
• Single Task Domains: When the problem scope is well-defined, narrow, and can be reasonably managed by one entity.
• Centralized Control: When centralized reasoning and decision-making are preferable, such as in environments where coordination and communication between entities would add unnecessary complexity.
• Single Context: When all context for the task is in a single location and can be structured as single knowledge repository.
• Limited Resources: When system resources (computation, memory, energy) are constrained and cannot efficiently support multiple agents.
• Predictable Environments: If the operating environment is static or predictable, a single agent can often perform optimally.
• Maintainability: For applications that need to be simple to test, debug, or deploy, single agent systems are advantageous.
Pros of Single Agent Architecture
• Simplicity: Easier to design, implement, test, and maintain.
• Lower Overhead: No need for inter-agent communication, reducing computational and networking overhead.
• More Predictable Behavior: Feweryinteractions.
• Transparent Debugging: Easier to trace and diagnose issues with a single entity managing all logic.
Cons of Single Agent Architecture
• Lack of Scalability: As complexity grows, single agent performance suffers. Large context windows and RAG pipelines spread attention across more tokens, increasing compute cost and response quality variance. Long prompts often suffer from the “lost in the middle” effect, where relevant information buried deep in context is ignored. Adding more retrieved information chunks may dilute precision, amplifying noise and position bias. Having a large number of tools may lead to tool-selection errors and latency. All these effects increase brittleness of single-agent designs at scale.
• Limited Modularity: Harder to separate concerns and extend functionalities incrementally.
• Reduced Robustness: A failure in the agent can cripple the entire system.
• Poor Suitability for Distributed Problems: Not ideal for tasks naturally distributed across multiple dynamic entities.
Examples of Single Agent Architectures
• Personal Productivity Bots: Calendar assistants scheduling meetings for one user.
• Customer Care Agents: Agent performing customer care for customers of a business. More complex customer care systems may use multi-agent architecture.
Other examples:
• Chess-playing AI: Programs like Stockfish or AlphaZero operate as a single agent searching for optimal moves.
• Robotic Vacuum Cleaners: Autonomous units cleaning an environment without interacting with other agents.
Multi-Agent Architecture
What is Multi-Agent Architecture?
Multi-agent architectures comprise multiple autonomous agents interacting within a shared or distributed environment. These agents may cooperate, compete, or operate independently, each possessing unique capabilities, knowledge, or perspectives. Agents pursue local objectives while contributing to system-level goals through coordination or negotiation. Agents communicate via explicit messaging or shared context. Their coordination may be centralized, decentralized, or hybrid. Their autonomy is bounded by roles, permissions, and assigned domains/tasks.
When to Use Multi-Agent Architecture
• Decomposable Problems: When tasks can be partitioned and delegated among specialized agents.
• Dynamic and Complex Environments: Suited to environments where a single perspective is insufficient or when the environment changes rapidly.
• Scalability Needs: When the workload can be parallelized, or additional agents can be added to handle growth or redundancy.
• Distributed Control: For applications where no single centralized controller is optimal or possible.
• Dynamic or Unpredictable Paths to Solution: For situations where there is not a single fixed path to outcome.
• Fault Tolerance: Multi-agent systems can often recover from the failure of individual agents without collapsing.
Pros of Multi-Agent Architecture
• Parallelism: Multiple agents can work on different sub-tasks simultaneously for improved performance.
• Specialization: Agents can be tailored for specific roles[CJ1.1][RL1.2][CJ1.3], leading to better efficiency and adaptability.
• Redundancy: The system can withstand individual agent failures, increasing robustness.
• Emergent Behavior: Complex behaviors can emerge from agent interactions, enabling solutions to problems that are intractable for single agents.
• Modularity: Easier to add, remove, or upgrade individual agents.
Cons of Multi-Agent Architecture
• Increased Complexity: Requires sophisticated coordination, communication, and conflict resolution mechanisms.
• Higher Resource Consumption: Multiple agents may demand more computing and communication resources.
• Non-deterministic Outcomes: Emergent behaviors and interactions may make system behavior harder to predict and test.
• Risk of Compounding Errors: Errors in reasoning, planning, and goal evaluation may compound resulting in system failure. Corrective mechanisms may be required.
• Debugging Difficulty: Tracing bugs and understanding failures can be challenging due to distributed responsibilities.
• Optimization Difficulty: Due to high complexity, the optimization of the system can take a lot of effort.
Multi-Agent System Guidelines[CJ2.1]
• Specify and understand what agents should do and how they determine whether their objective is achieved.
• Clearly specify work division and subtask descriptions by orchestrator. This is needed to not duplicate work[NE3.1][RL3.2] or fail to accomplish subtasks.
• Specify task and subtask complexity and allocate agents appropriately.
• Parallelization of tasks and tool use among agents is critical to decrease time to result.
• Use subagent output to artifact store to avoid imprecise communication through orchestrator or other agents.
Challenges In Multi-Agent Architectures
• Sharing context between agents may be complex.
• Coordination and delegation may be challenging.
• Small changes to orchestration may lead to significant changes to the behavior and outcomes.
Examples of Multi-Agent Architectures
• Software Development System: Agents represent several roles: developer, architect, pm, code reviewer, security specialist, tester. Shown to outperform single agent systems.
• Research System: Agents pursue multiple research directions at once.[CJ4.1][RL4.2]
• Project Management System: Agents identify issues, assign issues to human programmers, run build and CI/CD pipelines, evaluate their results, summarize progress, and report it to project manager.
• Multi-Agent Conversational AI: Systems where various bots (e.g., booking, information, and troubleshooting agents) collaborate to resolve complex user requests.
Other examples:
• Smart Grid Systems: Agents representing power producers, consumers, and grid operators coordinate for optimal energy flow.
• Automated Financial Trading: Multiple bots [CJ5.1][RL5.2]with different trading strategies interacting in real-time markets.
• Collaborative Robotics (Swarm Robotics): Drones or robots working together for tasks like search and rescue, mapping, or delivery.
Deterministic Agentic Workflow vs. LLM Orchestrator-Based Agentic Workflow
Deterministic Agentic Workflow
A deterministic agentic workflow is one in which agent interactions, coordination, and task delegation are governed by explicit, predefined rules or protocols. The sequence of operations, agent responsibilities, and communication flows are specified in advance.
• Predictability: The system behaves more consistently under identical circumstances, which is beneficial for critical applications where reliability is paramount.
• Simpler [NE6.1][RL6.2]Debugging: Failures and unexpected behaviors are easier to trace.
Can be used in customer care scenarios, software development systems.
• Limitations: Less adaptable to novel scenarios, and often harder to extend as complexity grows.
LLM Orchestrator-Based Agentic Workflow
An LLM orchestrator-based agentic workflow leverages a large language model to dynamically coordinate, instruct, and mediate between agents. The LLM can interpret goals, synthesize strategies, assign tasks, and facilitate communication using natural language or structured prompts.
• Adaptability: The LLM can adapt workflows on the fly, accommodating new agents, unforeseen user intents, or changing environments.
• Natural Language Coordination: Agents can communicate and receive instructions in human-like language, facilitating integration and flexibility.
• Emergent Solutions: Capable of synthesizing creative and contextually appropriate strategies that may not be foreseen by rigid protocols.
Can be used for research systems where the number and directions of subtasks may not be known beforehand. Also used for computer control scenarios where the agents may need to perform different control, input and website information processing steps to achieve user goals.
• Limitations: Potential for non-deterministic or unexpected behaviors, harder to guarantee reliability, and greater resource requirements for running LLMs in production.
Choosing Between Deterministic and LLM Orchestrator Approaches
Deterministic Agentic Workflows:
• Best suited for well-defined, safety-critical, or regulatory environments.
• Recommended when system behavior must be explainable.
• Preferable for real-time systems where latency and predictability trumps flexibility.
LLM Orchestrator-Based Workflows:
• Ideal for open-ended, creative, or complex domains where adaptability is critical.
• Recommended when user interaction is dynamic or when integrating many specialized agents.
• Preferable for applications where workflow logic may change frequently or unpredictably.
Diagnostics Agent: Single-Agent vs Multi-Agent System
In this section we explore and contrast Diagnostics Agent implementation as a Single-Agent or a Multi-Agent system.
Single-Agent Diagnostics Agent
In a single-agent implementation, one agent is responsible for the entire process chain: planning the conversation flow, retrieving knowledge from databases or documentation, and invoking tools as required. This centralized agent maintains context and handles user interactions, ensuring a consistent and unified approach to each problem.
Advantages:
• Simplicity: With only one agent managing the conversation flow, the system is straightforward to develop, deploy, and maintain.
• Predictability: Behavior is more easily explainable and testable, making it a strong fit for diagnostics scenarios.
• Low Overhead: No communication and coordination overhead; one or few LLM calls per turn, reducing latency and resource requirements.
Disadvantages:
• Limited Scalability: As task complexity grows, a single agent may not be able to handle such tasks.
• Limited Intelligence: Single agent may not be able to perform reasoning, planning, tool choice and execution, as well as domain specific business rule compliance at expert level.
• Reduced Flexibility: Single agent follows a prescribed path for each turn and may not be able to adjust if certain turns require different behavior.
• Single Point of Failure: Single agent may not be able to intelligently recover from an error. It may not be able to detect that the plan contains incorrect or infeasible actions and to adjust it intelligently. This may require an additional validator or supervisor agent.
Multi-Agent Diagnostics Agent
A multi-agent implementation distributes responsibilities across specialized agents. For diagnostics, this might include separate agents for multi-turn planning, gathering relevant inputs from the customer, gathering knowledge from knowledge bases, selecting and executing the most appropriate tools, and agents for domain-specific subtasks, for example using a telemetry agent to obtain and process telemetry. These agents collaborate dynamically, orchestrated either deterministically or through an LLM-based coordinator, to handle diverse and evolving user needs.
Advantages:
• Scalability: For complex tasks work can be parallelized and distributed, providing viable solutions.
• Adaptability: Specialized agents can be updated or added independently, enabling rapid adaptation to emerging requirements or technologies.
• Robustness: Validator or supervisor agents [CJ7.1][RL7.2]can check plans and proposed agent steps detecting issues and intelligently suggesting changes.
Disadvantages:
• Complexity: Coordination, communication, and state management between agents introduce significant design and operational challenges.
• Increased Overhead: Orchestration requires additional resources, and system performance would be affected by multiple agent execution and inter-agent communication.
• Debugging Difficulty: Tracing the flow of information and diagnosing errors across multiple agents is more challenging.
In summary, a single-agent diagnostics system is simpler, more reliable, and more predictable. In contrast, a multi-agent diagnostics system offers greater power, flexibility, and scalability, at the cost of increased complexity and overhead. The choice between these approaches would be down to specific needs and constraints of the diagnostics system.
Conclusion and Best Practices
Choosing between single and multi-agent architectures should be grounded in a careful assessment of the problem domain, scalability needs, and operational constraints. Single agent architectures offer simplicity and predictability, making them ideal for contained, well-understood domains. Multi-agent architectures shine in complex, distributed, and dynamic environments, but require careful design to manage complexity.
For multi-agent systems, the choice between deterministic workflows and AI-based orchestrator approaches reflects a trade-off between predictability and adaptability. Deterministic workflows suit domains where workflow is straightforward, while LLM orchestration unlocks capabilities for creative and flexible solutions to problems with no fixed work path.
Key Recommendations for Developers:
• Clearly define the problem space and assess if it can be handled by a single entity or requires distributed intelligence.
• For any agent system, tool design and selection are critically important.
• Evaluate scalability, fault tolerance, and maintainability requirements.
• Choose deterministic workflows for simplicity and reliability; leverage LLM [CJ8.1][RL8.2]orchestration for flexibility and innovation.
• Continuously monitor and iterate on agent interactions, communication protocols, and orchestrator behavior to align with evolving system goals.
• Investigate agent self-improvement possibilities. Agents can improve their prompts and tool use given opportunity to do so.
By understanding these architectural paradigms and their trade-offs, developers can build intelligent systems that are robust, scalable, and well-suited to their intended applications.
References
1. https://www.anthropic.com/engineering/built-multi-agent-research-system
2. https://www.anthropic.com/engineering/building-effective-agents
3. https://cognition.ai/blog/dont-build-multi-agents
4. CRMArena-Pro: Holistic Assessment of LLM Agents Across Diverse Business Scenarios and Interactions https://arxiv.org/abs/2505.18878
5. https://blog.langchain.com/deep-agents/
6. https://github.com/microsoft/magentic-ui
7. Sequential Diagnosis with Language Models https://arxiv.org/abs/2506.22405
8. Self Evolving Agents https://arxiv.org/abs/2506.04651
9. https://the-agent-company.com/