Introduction

Introduction#

EvoFabric’s Multi-Agent module provides the capability to build “agent collaboration graphs.” The module adopts a scalable architecture, currently including the Swarm component (Swarm-style multi-agent), with additional orchestration strategies and components to be added subsequently.

What is multi-agent?#

Multi-agent systems complete complex tasks through a group of Agents, each with specific roles, collaborating. Each Agent is typically bound to specific capabilities (retrieval, planning, tool calling, code execution, writing review, etc.), and performs “relay-style” solving under agreed-upon topology and routing mechanisms to enhance controllability, observability, and robustness.

Why Choose Multi-Agent#

  • Decompose complex tasks into multiple specialized Agents (planning, retrieval, computation, tool call, writing, etc.), improving reliability and maintainability

  • Based on the ‘handoff (handover)’ paradigm, let Agent dynamically collaborate and relay in tasks

  • Utilize graph structure to control execution flow, avoid unnecessary loops, and constrain topology when needed.

  • Divide and Conquer and Maintainability: Break down complex tasks into stable sub-roles, with individual Agent prompts and tools being more focused, easier to test and evolve.

  • Reuse and Expansion: Different teams can accumulate domain-specific Agents and reuse them within larger workflows, or add/replace roles as needed without disrupting the core workflow.

Typical Use Cases#

  • Retrieval Enhancement and Writing Collaboration: Retrieval Agent, Integration/Review Agent, Writing Agent collaborate to complete information gathering and drafting.

  • Tool-oriented task orchestration: The “Scheduling/Planning” Agent triggers tools such as retrieval, database, search, and code execution, and routes subtasks.

  • Customer Service/Operations Automation: Organize roles according to the ‘Triage/Routing → Expert Handling → Quality Inspection/Summary’ process; in real-time voice or multimodal scenarios, ‘sequential handoff’ can be adopted.

  • Research and Data Workbench: Collaborative Multi-Agent Group Chat for Information Gathering, Comparison, Summarization, and Visualization.

  • Long workflow and human review: At key nodes, use an interruption mechanism to wait for human review decisions before proceeding with the process (approve/modify/reject).

Swarm’s Advantages#

  • Rapid Deployment and Low Cognitive Load: Concise API, convention over configuration, suitable for completing tasks in fewer iterations using the ‘planning + expert agent’ model.

  • Clear handoff semantics: The built-in handoff tool provides visible, measurable, and controllable interfaces for “who to hand off the task to and what information to carry.”

  • Topology constraints: Specify allowed edges via edges, supporting Star (centralized scheduling), All-to-All (exploratory validation), or Pipeline (pipeline).

  • Easy Integration: Seamless integration with EvoFabric’s AgentNode, ToolManager, ComponentFactory, and Pydantic State.

Swarm’s Key Components and Terms#

The following terms cover both the industry’s general multi-agent components and highlight Swarm’s specific features, facilitating understanding of migration:

  • Agent (intelligent agent) is a node that binds chat models, system prompts, and tool set. In Swarm, it is represented by AgentNode.

  • Tool/Function (Tool Calling) Agent interacts with the external world through tools, such as retrieval, weather query, time query, database operations, etc.

  • Handoff (handover, Swarm-specific focus) The current Agent actively “hands off the task to the target Agent” while carrying context or requirements. Swarm injects a customized handoff tool for each Agent, with optional targets automatically generated by edges or “fully connected (default)”.

  • Router/Planner (Routing/Planning) is used to determine who the next step is assigned to. Common patterns include: Centralized Planner (Star), Conditional Routing (based on messages/tool calls), and Finite State Machine/Hierarchical Scheduling.

  • Graph/Edges (Graph and Edges) Using “node + directed edge” to control reachable paths and conditional branches. Swarm uses edges to generate the allowed handoff target set and prints routing logs at runtime for debugging.

  • State/Memory (State/Memory) Swarm run graph requires a Pydantic state model, must include at least messages: List[StateMessage]

  • Termination (Termination Condition) Swarm defaults to terminating when it detects "FINISHED" in the response; it can also be customized via termination_pattern to "END" and others.

Contents