Multi-Agent System

Multi-agent system (MAS, also written multiagent system) is a computational system in which two or more interacting agents operate in a shared or connected environment. Each agent has some capacity to observe conditions, pursue objectives and select actions within its assigned role. Their interactions—through communication, coordination, cooperation, negotiation or competition—shape the behavior and results of the system as a whole. Agents may share one overall objective, have partly different objectives or act in pursuit of competing interests. The concept belongs to the wider field of artificial intelligence and distributed computing.

In practical terms, a multi-agent system organizes several decision-making participants so that they can address a problem together or operate in the same environment. One agent might identify a fault, another examine possible consequences and a third prepare a response. In a different setting, agents representing separate robots, vehicles or market participants may act independently while coordinating their activities or competing for resources. The result depends on more than the intelligence of any one agent: it also depends on how tasks, information, authority and feedback are shared among them.

Modern enterprise multi-agent systems often use large language models to interpret goals and select software tools. However, multi-agent systems are older than generative AI and do not require language models. A group of autonomous robots or rule-based agents can also form a multi-agent system. The article AI Agent describes an individual agent; Agentic AI describes a broader goal-directed approach that may use one agent or several. This article concerns the system of interacting agents, especially its architecture, coordination and collective behavior.

Meaning and scope

The defining characteristic of a multi-agent system is interaction among distinct agents. Merely using several AI models, running separate API calls or splitting a program into conventional software functions does not necessarily make a system multi-agent. An agent should have a meaningful operating role, such as choosing an action, responding to observations or pursuing a delegated objective. Its independence may be narrow or extensive; an agent can operate under a predetermined process without having unrestricted authority.

The word system matters equally. Independently capable agents become a multi-agent system when their relationships, shared environment or exchanges affect the joint outcome. They may operate through a central coordinator, communicate as peers, use common state or influence one another through changes to the environment. Some systems are designed for a single organizational goal. Others model parties with interests that overlap or conflict, such as negotiators in a resource-allocation setting. Earlier research examined these interactions long before the development of modern LLM-based software agents.

Distinguishing question	What to examine	Why it matters
Are there multiple agents?	Whether two or more components act as agents with identifiable responsibilities, observations or action choices.	Several prompts or functions are not automatically several agents.
Do the agents interact?	Messages, task handoffs, joint decisions, competition, shared state or effects on a common environment.	Interaction creates system-level behavior and coordination requirements.
Whose goals are pursued?	A shared goal, separate goals or a mixture of cooperative and conflicting objectives.	Different incentives can require different coordination mechanisms.
Who has authority?	Each agent's permissions, the coordinator's powers and the conditions for human approval.	Technical ability does not establish permission to change a business system.
How is success established?	Whether the resulting environment or business process reaches an independently checkable state.	Plausible agent messages alone do not demonstrate a successful overall result.

In the current enterprise technology market, multi-agent is sometimes used loosely for any application with several named specialists. The term is more informative when the description also identifies the agents' autonomy, interaction pattern, shared or separate state and actual decision rights. The same arrangement may be described as multi-agent AI, an agent team or an agent orchestration, but these labels do not by themselves establish its architecture or effectiveness.

How a multi-agent system works

A multi-agent system combines individual agent behavior with an interaction mechanism. In a task-oriented enterprise example, a request or event establishes an objective. A coordinating component or agent assigns work; agents gather relevant information or act on the environment; messages and outputs return through defined interfaces; and the system determines whether to continue, recover, escalate or complete. In a decentralized environment, there may be no single manager: the agents instead negotiate, follow shared rules or react to one another's actions.

An illustrative enterprise operating cycle is:

1. Establish the task and constraints. Define what constitutes completion, permitted information sources, prohibited actions and any approval boundaries.
2. Assign work. A coordinator, fixed workflow or peer mechanism selects which agents should participate and what each one should produce.
3. Observe and act. Each agent processes its inputs, uses permitted tools or responds to its environment within the scope of its own role.
4. Exchange results. Messages, verified records or shared artifacts convey necessary findings, status and outstanding requirements between agents.
5. Coordinate and reconcile. The system combines results, resolves inconsistent information, checks dependencies or redirects work when a condition changes.
6. Verify and close. A system-level check determines whether the intended result occurred; otherwise the process stops, retries within limits or escalates.

This is an explanatory cycle, not a mandatory standard or universal sequence. Concurrent agents may work in parallel; agents in a physical swarm may act continuously; and a competitive multi-agent system may have no single outcome that all participants want. Some steps may be executed by deterministic software rather than an agent. That is often desirable where accounting, authorization or system integrity requires predictable behavior.

Coordination is different from communication

Communication transmits information: for instance, a task identifier, observation, proposed action, evidence file or completion status. Coordination determines how several agents' activities fit together: which agent works next, whether tasks can proceed in parallel, who owns a decision and what happens when results conflict. Agents can communicate extensively and still fail to coordinate if nobody has responsibility for integrating their work.

An agent-to-agent handoff therefore needs more than a conversational message. It may need a precise objective, expected output, identifiers for supporting records, quality criteria, relevant deadlines and a failure or escalation destination. Reliable state exchange is especially important when one agent must resume after another has stopped or when several agents access the same business record.

Components of a multi-agent system

The exact architecture depends on whether agents are software assistants, physical machines, simulation actors or a combination. In enterprise AI applications, a system commonly contains the following functions. They may be implemented in separate services or combined in a smaller number of components.

Component	Role in the multi-agent system	Important design question
Agent identities and roles	Identify participating agents, their capabilities, delegated goals and operating limits.	Can the system distinguish agents, owners and authorized actions?
Coordination mechanism	Determines delegation, ordering, concurrency, handoffs and completion.	Is work assigned by a supervisor, fixed rules or negotiation among peers?
Communication interfaces	Convey requests, observations, outputs, acknowledgments and errors.	Are formats, versions, sender identities and trust boundaries explicit?
Task and shared-state management	Tracks task IDs, dependencies, progress, intermediate outputs and recovery points.	Who owns a state change and how are concurrent updates reconciled?
Models and decision logic	Supply reasoning, planning, classification, optimization or learned policies within individual agents.	Does each task require the same model, or a different mechanism?
Tools and external systems	Connect agents to records, applications, simulations, sensors or actuators.	Are read, write and high-impact permissions independently enforced?
Validation and human control	Check results, enforce business constraints and obtain approvals where needed.	Which failures or decisions must stop automated progress?
Observability and evaluation	Capture traces, agent actions, errors, costs, outcomes and audit records.	Can operators reconstruct the entire task, including cross-agent handoffs?

The structure shows why adding specialized agents is not simply a matter of copying one chatbot several times. The combined system needs explicit boundaries between information exchange, authority, action execution and result verification. The choice of coordination mechanism is an architectural decision; it does not eliminate normal software engineering concerns such as transactions, availability, privacy and recovery.

Organizational patterns for interacting agents

Multi-agent systems can be organized in several ways. These patterns describe relationships and control, not universally separate product categories. A physical robot fleet, for example, may use centralized task allocation and decentralized collision avoidance at the same time.

Centralized or supervisor-led systems

A central coordinator or supervisor receives an objective, assigns tasks and integrates results. Specialist agents may have different tools, data access or expertise. This arrangement can make assignment, traceability and completion easier to manage, although the coordinator can become a bottleneck or single point of operational failure. The coordinator does not necessarily have to be an LLM; it may be deterministic software or a separate agent.

Hierarchical systems

A hierarchical arrangement allows one agent to delegate to intermediate agents that manage further specialized participants. This can help separate broad planning from detailed execution, but additional delegation levels make error propagation, accountability and cost harder to trace. Every level needs clear rules about whether it may authorize actions, create additional agents or only recommend next steps.

Decentralized and peer-to-peer systems

Agents communicate or respond to each other without one universal decision-making center. They may negotiate task ownership, exchange local observations or pursue partially independent goals. This structure can support local responsiveness and tolerate the loss of some participants, but agreement, consistency and conflict resolution can be difficult. Decentralization does not automatically mean the absence of common policies or human governance.

Swarms and hybrid arrangements

Swarm generally describes many agents whose relatively local interactions produce collective behavior. Applications may involve physical robots or simulated participants; the term is also used more loosely for software-agent teams. A hybrid architecture combines arrangements—for example, a central planner assigning work to peer agents, with local autonomous decisions inside each assignment. Not every collection of agents should be labeled a swarm merely because it has multiple members.

Coordination and orchestration patterns

Architecture describes who interacts with whom. Orchestration patterns describe how work moves between participants. Modern LLM-based multi-agent applications often use the following arrangements, sometimes in combination.

Pattern	How the agents interact	Suitable task relationship	Main caution
Sequential or pipeline	One agent produces an output consumed by the next.	Later activities depend on completed earlier work.	An early error can contaminate later stages.
Parallel or concurrent	Several agents independently process different subtasks or perspectives before results are combined.	Work can proceed without a shared mutable state dependency.	Results may conflict; cost and synchronization can increase.
Supervisor or manager-worker	A lead agent dynamically delegates work to specialized participants and synthesizes the responses.	Broad requests require adaptive decomposition.	The lead can become a bottleneck or delegate unnecessary tasks.
Handoff or routing	An agent transfers responsibility for the next stage to another agent with the appropriate scope.	Different specialties or permissions are needed as the context changes.	Task ownership and context can be lost during transfer.
Group conversation or debate	Several agents contribute to a shared discussion or maker-checker review, often with a turn manager.	A result benefits from critique or iterative refinement.	Circular discussion and false consensus can increase time and cost.
Peer coordination or negotiation	Agents exchange proposals or observations to allocate shared resources or agree on actions.	Participants hold local information or partly independent objectives.	Disagreement, deadlock and strategic behavior require resolution rules.

The distinction between a predetermined workflow and dynamic delegation is consequential. A workflow engine can decide the next stage using fixed rules; an agent can also select a next participant based on observations. Many practical systems combine both: fixed rules enforce non-negotiable approvals, while agents handle interpretation or exploration within approved boundaries. A predetermined sequence of conventional scripts is not necessarily a multi-agent system simply because its steps have specialist names.

Types of multi-agent systems

The term type can refer to several dimensions. Treating them as a single classification can give a misleading impression that every multi-agent system belongs to exactly one category.

Dimension	Variants	What varies
Relationships among objectives	Cooperative, competitive or mixed-motive.	Whether agents work toward a common result, pursue separate outcomes or negotiate trade-offs.
Agent composition	Homogeneous or heterogeneous.	Whether participants have similar capabilities and logic or specialized models, tools and roles.
Control distribution	Centralized, hierarchical, decentralized or hybrid.	Where task allocation and decisions occur.
Physical setting	Software, simulated, embodied or cyber-physical.	Whether agents act on information systems, models of an environment or the physical world.
Decision mechanism	Rules-based, optimization-based, learned, LLM-based or combined.	How agents select actions or interpret information.
Interaction timing	Synchronous, asynchronous or event-driven.	Whether agents must wait for one another or can proceed independently.

A fleet of warehouse robots may be homogeneous in its hardware, decentralized in local navigation and cooperative toward a shared task. A software research application may use heterogeneous tools and roles under a central supervisor. Neither design is intrinsically more intelligent; their suitability depends on the environment, objectives and constraints.

Communication, interoperability and shared state

An interaction can involve a message, an artifact, a shared database entry or an action that changes the environment for other agents. For software systems, messages should clearly distinguish requests, observations, proposed actions, execution results and verified outcomes. Without that distinction, a downstream participant can mistake an agent's plausible statement for authoritative evidence that something actually happened.

Useful message fields include a task identifier, sending agent identity, intended receiver, objective, relevant data or artifact references, the source and freshness of important information, the required output, validity conditions and status. These are general integration-design elements, not a mandated universal message schema. Where messages can be retried, a stable operation identifier and duplicate-handling rule help prevent repeated side effects.

Agent-to-agent and agent-to-tool communication

The Agent2Agent (A2A) protocol is an open interoperability specification intended to let independent agents discover capabilities, exchange information and manage collaborative tasks across products or vendors. Its published specification describes discovery, task management and security-related interactions. As of the version reviewed in November 2026, the A2A project identifies version 1.0.0 as its latest released specification.

By contrast, the Model Context Protocol (MCP) addresses connecting AI applications to tools, data and external capabilities. A2A and MCP serve different interface purposes and can be used together; neither is mandatory for every multi-agent architecture. Agents within one framework may coordinate using that framework's internal mechanism rather than an external A2A service. A communication standard also does not grant authorization or guarantee that an agent's output is correct.

State, memory and consistency

An agent may maintain a private task context while the system maintains a shared record of progress. Sharing every internal thought or full conversation is neither necessary nor automatically desirable. Agents often need only the information required for a delegated task and a verifiable reference to relevant source artifacts. Durable records can preserve outcomes across retries and long-running tasks without continually copying all context through the supervising agent.

Coordination becomes more demanding when several agents can modify the same object. Two agents might independently approve different changes, update a shared field, or assume that the other has completed a prerequisite. Systems need explicit rules for ownership, versioning, concurrency, idempotency, conflict resolution and recovery. The exact mechanism may be a database transaction, queue, workflow checkpoint or human approval rather than additional AI reasoning.

Autonomy, authority and human oversight

Agents may choose their next analytical step without being authorized to change external state. A research agent may search and synthesize, while a service-management agent may update a ticket and a financial agent may be prohibited from executing a payment. The permitted action is a property of the agent's identity and the application's security policy, not a natural consequence of how capable its model appears.

Decision or action	Illustrative system behavior	Boundary requiring control
Read an approved record	A specialist agent retrieves information relevant to its assignment.	The agent must not inherit access to unrelated private records merely because another agent has it.
Propose a change	An agent drafts a maintenance action or procurement recommendation.	A proposal must be distinguished from approval or execution.
Execute a low-impact operation	An agent updates a permitted internal field or creates a draft task.	The operation needs a real authorization check and an auditable outcome.
Cross a business or security boundary	One agent requests another's service in a different environment or department.	Reauthenticate or authorize the caller and the requested operation at the boundary.
Perform a high-consequence action	An agent proposes a payment, service outage, privileged change or binding decision.	Human or separately authorized approval may be required by policy or law.

Human oversight can appear as an approval gate, exception review, override, emergency stop, periodic audit or ownership of the final business result. These are different controls. A human observer who receives a transcript after an irreversible action has not exercised prior approval. Likewise, a supervising agent is not automatically an independent risk controller if it shares the same flawed assumptions or permissions as the worker it is supervising.

Applications and illustrative contexts

Multi-agent systems occur in both older distributed-AI research and newer enterprise software. Their value depends on a specific coordination requirement. The following examples illustrate plausible task structures, not universal performance claims or evidence that every sector has deployed these exact arrangements.

Context	Possible agent interaction	What needs verification
Research and information synthesis	Specialized agents investigate different sources or questions; a coordinator reconciles findings and checks citations.	Coverage, provenance, factual accuracy and whether parallel work improves results.
IT service management	Incident triage, infrastructure impact analysis and service communications run as bounded specialist tasks.	Change authority, incident ownership, record consistency and actual restoration outcomes.
Cybersecurity operations	Detection, investigation and response-planning agents assess different evidence streams before a controlled decision.	False positives, exposure of sensitive evidence and authorization to contain systems.
Software engineering	Code, testing, review and documentation agents work on separately defined tasks with reconciliation before release.	Test validity, review independence, change provenance and production access.
Supply-chain and purchasing processes	Agents compare approved supplier data, check document completeness and assemble evidence for a procurement decision.	Contracts, privacy, segregation of duties and whether final decisions remain authorized.
Robotics and logistics	Vehicle or robot agents coordinate routes, space or tasks in a shared physical environment.	Safety, collision avoidance, local control and behavior under communication failure.
Simulated markets or resource allocation	Participants represent buyers, sellers or resource users with partly conflicting incentives.	Whether individual strategies produce a stable or acceptable collective outcome.

Documented example: parallel research agents

Anthropic publicly described a multi-agent Research system in June 2025. Its first-party engineering report explains how a lead agent decomposes user questions, delegates separate searches to subagents and synthesizes results. The report also describes challenges with redundant delegation, long-running state, error propagation, synchronous bottlenecks and reliable resumption. This is evidence of a particular implementation and its reported lessons; it is not an independent demonstration that multi-agent designs outperform single agents in every application.

The example shows the distinction between agent capability and system-level success. A subagent may retrieve good information, but the whole result can still fail if important evidence never reaches the coordinator, two agents duplicate one another, citations lose their source context or the run stops before the requested synthesis is completed.

Benefits, limitations and architectural trade-offs

Specialization can allow different agents to use the tools, information and models most appropriate to their tasks. Parallel processing may reduce elapsed time when work is independent. Modular boundaries may also help isolate security permissions or update components separately. These are potential advantages, not automatic properties or verified benefits of every multi-agent application.

The costs are equally important. Handoffs introduce communication overhead; parallel agents may create inconsistent versions of the same information; several agents can repeat expensive reasoning; and a larger number of participants produces more failure paths. A coordinator that incorrectly defines the task can make all downstream work irrelevant. A well-designed single agent with appropriate tools, or a deterministic workflow, may be easier to evaluate and operate.

Choice	Possible advantage	Cost or limitation
Add specialist agents	Different contexts, permissions or capabilities can be separated.	More interfaces, operating owners and dependency management.
Run agents in parallel	Independent work may finish sooner or cover more distinct evidence.	Extra resource use, merge conflicts and synchronization costs.
Use a central supervisor	One place to route work and determine completion.	Bottlenecks, supervisor error and concentrated failure risk.
Allow direct peer communication	Faster local coordination and flexibility when participants have separate knowledge.	Harder auditing, consistency and conflict resolution.
Use separate agent permissions	Limits the effects of a compromised or mistaken participant.	Requires careful identity, credential and policy management.
Keep the task within one agent	Simpler state, testing, latency and operational accountability.	May be inadequate when distinct boundaries or specialized contexts are essential.

The sensible comparison is between a multi-agent system and a competent simpler baseline: direct model use, a single tool-using agent, traditional software or a bounded workflow. The question is whether coordinating multiple agents closes a demonstrated gap that the simpler design cannot close acceptably. Microsoft and Google architecture guidance both caution against introducing multi-agent complexity without a corresponding task requirement.

Security risks and failure modes

Multiple agents create more than multiple instances of ordinary model error. A message or tool result from one agent may influence another's decisions and potentially cross a security boundary. The system may also propagate incorrect information, authority assumptions or unsafe instructions through a chain of otherwise plausible actions. The OWASP Agentic Security Initiative identifies security concerns specific to autonomous and multi-step agentic applications; these are risk categories for assessment, not evidence that every deployment is vulnerable.

Material failure modes include:

• Instruction or context manipulation: hostile text in retrieved content or messages may induce an agent to disregard its task or misuse a connected tool.
• Authority confusion: one participant treats another agent's suggestion as binding authorization, or reuses a credential beyond its permitted scope.
• Untrusted handoffs: agent messages omit provenance, scope or validation, causing an unsupported claim or malicious instruction to spread.
• Conflicting actions: concurrent agents modify the same business record or infrastructure resource without consistent ownership.
• Recursive or uncontrolled delegation: agents create unnecessary additional tasks, repeatedly invoke tools or enter an unbounded coordination loop.
• Compounding errors: an incorrect interpretation in an early stage becomes the assumed premise of subsequent decisions.
• Disclosure across contexts: information available to one agent is copied into another task, user context or less-trusted environment.
• Observability gaps: operators cannot reconstruct which agent requested an action, which tool actually executed it or what changed.
• False completion: several agents report success even though the intended end state has not been independently checked.
• Distributed unavailability: a failed coordinator, service, queue or dependent agent prevents work from completing or recovering.

Mitigations are correspondingly architectural. Enforce separate credentials and least-privilege permissions; validate inter-agent requests; distinguish instructions from retrieved data; limit recursion, spending and execution time; verify high-impact changes outside the language model; persist meaningful checkpoints; and ensure audit logs cover the whole chain. For sensitive operations, human approval must be enforced by the application rather than merely suggested in a prompt. Security requirements should remain proportional to the environment and consequences, with model risk and conventional software security assessed together.

Governance and organizational accountability

A multi-agent system has an overall business purpose, but responsibility does not disappear into its distributed components. A business process owner remains accountable for the outcomes and permitted actions; an application or platform owner maintains the coordination service; security and risk functions determine required controls; data and service owners govern their respective resources. Specific role assignments differ across organizations. AI governance defines the authority structure and assurance requirements within which this operating arrangement is used.

Accountable area	Governance concern	Evidence worth retaining
Business outcome and ownership	Clear task purpose, accepted results and authority for any organizational decision.	Approved scope, outcome criteria and decision records.
Agent and tool inventory	Which agents can participate, invoke tools or delegate further work.	Versioned agent registry, tool and permission map.
Handoff and interoperability	Inter-agent identity, data classification, message contracts and retry behavior.	Interface definitions, test results, trace or event records.
Risk and security	Least privilege, external content handling, unsafe actions, privacy and incident response.	Threat assessment, control results, access records and exceptions.
Operation and recovery	Safe stopping, partial failures, checkpoints and updates to agent versions.	Run histories, recovery procedures, failure and rollback tests.
Performance and learning	Whether the collective system improves an actual task after overhead and errors.	Baselines, evaluation results, cost measures and post-deployment reviews.

The NIST AI Risk Management Framework (AI RMF 1.0) provides a voluntary structure organized around Govern, Map, Measure and Manage. Organizations may use it to organize risk thinking, while applying ordinary software security, privacy and domain-specific obligations as appropriate. It is not a multi-agent-specific product certification or a guarantee of safe behavior.

Organizations should also distinguish a system-wide control from an individual agent control. Limiting the coordinator's permissions does not help if a worker agent retains an unbounded privileged credential. Conversely, asking every agent for separate human approval may introduce unmanageable friction. Approval design should be based on the consequences of the operation and the trust boundary being crossed.

Evaluating a multi-agent system

Evaluation must examine both individual agent outputs and the combined end-to-end result. A good score for one agent's response may conceal a failed handoff, unreconciled conflict, unauthorized action or incomplete business task. Production measurements also need stable populations, baselines, time windows and documented changes to agent or tool versions.

Evaluation level	Example questions or measures	Interpretation limit
Agent-level capability	Did the specialist complete its assigned task accurately and within scope?	A competent agent does not guarantee a competent system.
Delegation and coordination	Were tasks correctly routed, duplicated, omitted or handed off with complete evidence?	Number of handoffs alone does not establish coordination quality.
State and recovery	Can the system resume after an interruption without double-applying changes?	A successful restart test may not cover concurrent failures.
Security and approval	Did each action respect permission boundaries and required human gates?	A written policy is not proof that enforcement worked.
End-state correctness	Did the requested business or environment state actually occur and remain consistent?	An agent-generated statement of success is not independent confirmation.
Operational performance	Completion time, compute and model cost, retries, incident rate and exception handling.	Faster internal reasoning may not make the whole business process faster.
Value against alternatives	Compared with a single agent or established workflow, did quality-adjusted outcomes improve?	Claimed advantage requires a comparable baseline and sufficient test coverage.

Tests should include normal requests, ambiguous instructions, missing data, conflicting agent results, tool failures, malicious or misleading inputs, long-running state, parallel writes, permission denials and attempted recovery after interruption. Evaluate whether the system stops safely when a required approval or external dependency is unavailable. After deployment, compare actual completion and downstream effects rather than counting only successful model calls. Tests may also be repeated after changing an agent, its model, a shared protocol or the coordinator because those changes can alter collective behavior even when other components remain unchanged.

Illustrative example: coordinating a major IT incident

Consider a hypothetical organization experiencing a widespread service disruption across several business applications. Its major-incident process already has a named human incident manager and established authority for emergency changes. The organization adds a bounded multi-agent support capability to gather evidence in parallel without transferring the incident manager's decision rights to software.

A triage agent collects incident records and current service alerts. An infrastructure impact agent examines approved monitoring data and dependencies. A business-service agent compares affected systems with the service catalogue and prepares an impact summary. Their separate access scopes limit unnecessary exposure; each returns a timestamped artifact linked to the same incident ID. A coordinator checks whether all necessary evidence arrived, reconciles conflicting observations and prepares a summary with uncertainty clearly indicated.

If a possible recovery action requires an emergency change, the system can assemble a draft proposal and hand it to the authorized change process. The agent team must not infer that the urgency of an outage permits it to bypass change authority. After a human-approved action is executed through the approved operational system, service health is checked independently and the incident record is updated. The system can preserve the current state if an agent or monitoring service becomes unavailable, rather than silently claiming that recovery succeeded.

This hypothetical example illustrates why a multi-agent design may be useful when distinct knowledge and access boundaries must be reconciled. It also shows the difference between coordinated evidence preparation and authority to change production systems. No claim of measured response-time savings, incident reduction or deployment by a real organization is implied.

Related and distinct concepts

A multi-agent system is a system architecture and research subject. Related terms describe the individual participants, methods or interfaces and should not be treated as exact synonyms.

Concept	Relationship to a multi-agent system
AI Agent	One goal-directed participant. A multi-agent system concerns the interaction of two or more such participants.
Agentic AI	A broader description of AI systems that pursue goals through actions. It may involve a single agent or multiple agents, depending on usage.
AI Orchestration	The coordination of tasks, models, tools and agents. Some orchestration uses multiple agents, while some coordinates a single agent or ordinary processes.
Large language model	A model that may power an agent's language interpretation or decisions; multiple LLM calls alone do not necessarily create a multi-agent system.
Agentic Workflow	A process arrangement in which agentic steps are coordinated; the workflow may use one agent, several agents or deterministic steps.
Robotic process automation	Typically executes predetermined software interactions; it can be combined with agents but is not necessarily multi-agent.
Distributed Artificial Intelligence	A broader research tradition concerned with distributed intelligent behavior, cooperation and coordination, of which multi-agent systems are an important part.
Multi-Agent Reinforcement Learning	A learning setting in which multiple agents learn policies while interacting with one another and an environment; it is a particular method, not every multi-agent system.
Agent2Agent Protocol	A communication standard that some independently implemented agents may use to interoperate; it does not define every multi-agent architecture.

Frequently asked questions

Is a multi-agent system the same as agentic AI?

No. A multi-agent system specifically involves multiple interacting agents. Agentic AI is commonly used for goal-directed AI behavior and may describe either one agent or several. Some modern usage closely associates the terms, but they answer different conceptual questions: how many agents interact and what kind of goal-directed behavior the system performs.

Does every multi-agent system use large language models?

No. Multi-agent systems include classical distributed reasoning, optimization, robotics and simulation approaches. LLMs have enabled newer software patterns for interpreting unstructured tasks and selecting tools, but the presence of an LLM is not a defining condition.

Is a group of chatbots automatically a multi-agent system?

Not necessarily. Multiple chatbots may operate separately without coordinated or interacting behavior. The relevant question is whether they function as distinct agents and whether their exchanges or actions are part of a common system or shared environment. A predetermined sequence of ordinary text transformations may remain a workflow rather than a multi-agent arrangement.

Do agents have to cooperate?

No. Some systems are cooperative, others are competitive or mixed-motive. A group of resource-allocation or simulation agents may pursue different interests and affect one another's outcomes. Coordination can involve negotiation or rules for resolving conflict rather than a shared common goal.

Is a supervisor agent always required?

No. Hierarchical and supervisor-led designs are common, especially in enterprise language-model applications, but decentralized systems can coordinate through peer communication, protocols or the shared environment. Whether a supervisor is preferable depends on goals, operational constraints and accountability requirements.

Are more agents necessarily better?

No. Each added agent can introduce communication overhead, duplicated work, cost, latency and new failure paths. A single agent or conventional workflow may be sufficient. A multi-agent architecture should be justified by a specific coordination, specialization or trust-boundary need and tested against a simpler baseline.

Can agents communicate securely using A2A?

A2A supplies a standard framework for agent interoperability, but secure use still depends on authentication, authorization, information classification, implementation and operational controls. It does not replace the organization's access policies or mean that every response from another agent is trustworthy.

How should a multi-agent system be judged successful?

Its end-to-end outcomes should be verified: whether the intended task completed correctly, safely, within authority and with acceptable cost and reliability. Agent-level responses, coordination traces and elapsed time provide supporting evidence. A system should also be able to recover from or stop safely on important failures.

See also

• AI Agent
• Agentic AI
• Artificial Intelligence (AI)
• AI Orchestration
• Agentic Workflow
• Large Language Model (LLM)
• Distributed Artificial Intelligence
• Multi-Agent Reinforcement Learning
• Agent2Agent Protocol
• AI Governance
• Model Context Protocol
• AI Agent Security