A multi agent system is a system in which several agents make decisions and interact within a shared environment. In a business application, those agents might investigate different parts of a request, propose actions or carry out permitted work. The system also needs a way to coordinate their contributions when they depend on the same information or resources.
A software company can have two agents produce sensible onboarding plans for two customers. If both plans need the same engineer on Tuesday, the combined plan is impossible. Each agent can be locally correct while the company makes a commitment it cannot keep.
This is the central design problem: giving agents useful responsibilities while keeping the overall result coherent. It requires clear boundaries around evidence, shared state and permission to act. Adding another model does not resolve those boundaries by itself.
What makes a system multi agent?
The broader field of multi agent systems predates language models. The foundational textbook Multiagent Systems, published in 2009, describes autonomous participants with different information or interests. Cooperation is one possibility; agreement on every objective is not a requirement of the field.
For a company building with AI, the useful interpretation is usually a cooperative team. Each participant has a defined responsibility, receives some view of the work and can choose how to proceed within its permissions. The agents interact through messages, delegated requests or shared records. IBM's introduction describes this use of multiple AI agents working collectively on tasks.
One agent calling a search tool is still normally described as a single agent system. Renaming the same prompt several times does not establish meaningful specialization. A practical distinction is whether separate participants make decisions whose results must be coordinated.
The terms also describe different aspects of a design. A multi agent system describes its participants and their interactions. An agentic workflow describes how work proceeds. A workflow can use one agent or several, and can contain ordinary code and human decisions alongside model calls.
When does another agent earn its place?
A separate agent should solve an identifiable problem. An account agent might interpret customer requirements, while an engineering agent assesses the technical work. Their instructions, evidence and access needs differ enough to justify separate responsibilities.
Parallel work is another reason. Several independent investigations may proceed at once, provided their results can be combined without hiding disagreements. Independent review can also be useful when a second participant checks a concrete requirement against source evidence. Giving an agent the title of reviewer does not establish that its judgment is correct or independent.
There is an important cost to separation. Participants need to receive context, communicate findings and recover when a dependency changes. Microsoft's architecture guidance recommends using the simplest level of complexity that meets the requirement. It also warns about concurrent changes to shared state and the need to resolve conflicting results.
The research is similarly conditional. In Towards a Science of Scaling Agent Systems, researchers compared several coordination architectures across four benchmarks under controlled tool and token budgets. Multiple agents helped some tasks that could be divided, but hurt performance on others with sequential dependencies. The study's environments, prompts and model configurations limit how far those results generalize. It is evidence for testing the architecture against the task, not a universal formula for choosing an agent count.
Start by writing down the limitation of one agent. If the limitation is an unreliable source, a second agent reading that source may simply repeat the error. If it is a deterministic capacity calculation, ordinary code may be the right addition. An extra agent is most useful when it contributes a distinct decision or investigation that the system can evaluate.
Example: two customer launches, one integration team
Consider a software company helping two new business customers connect its product to their existing systems. One customer is a retailer; the other is a distributor. Both want to start using the product that week.
This is an illustrative design example, not a customer case study or a report of work executed in Swarm. The company supplies the requirements, correspondence and staffing information. No automatic access to a customer system is assumed.
The team assigns three agent responsibilities:
A retailer onboarding agent checks the retailer's requirements, outstanding questions and proposed launch plan.
A distributor onboarding agent does the equivalent work for the distributor, within that customer's permitted information.
An integration review agent checks technical prerequisites and compares the engineering capacity needed by both plans.
The customer success lead owns the final commitments. The agents may prepare recommendations; they cannot promise a launch date, book staff or send customer messages unless separately authorized to do so.
The agents receive one shared outcome: propose a feasible onboarding plan, identify anything that prevents a launch and keep external commitments pending for human review. Each customer agent also receives a bounded assignment for its own account.
Separate plans reveal a shared conflict
The retailer agent finds that the customer's sample data is ready. It proposes using the integration engineer on Tuesday, followed by customer testing.
The distributor agent finds that its customer can provide the necessary access on Tuesday. It proposes the same engineer on the same day. Both recommendations are plausible when considered alone.
The integration review agent compares those proposals with the current staffing record. Each customer needs a full day of that engineer's attention. Tuesday cannot support both. The distributor's earlier launch expectation also assumes work that has not yet been completed.
The combined result should preserve this conflict. A polished summary saying that both customers are on track would discard the most important information the agents discovered.
The lead needs a decision packet: the two proposed plans, the source for each dependency, the capacity conflict and the choices still available. Those choices might include moving one launch, assigning another qualified engineer or narrowing an initial rollout after technical review. The agents should not silently choose which customer absorbs the delay.
Resolve the commitment, then confirm the action
Suppose the lead prefers to give Tuesday to the retailer and propose a later launch to the distributor. That is a proposed resolution until the necessary people accept it. The distributor agent can draft an explanation, but a draft is not a message sent to the customer or an agreed change of date.
Before any authorized booking, the system must check that Tuesday is still available. Another team may have reserved the engineer while the proposal was under review. The system that owns the booking must enforce capacity when it accepts the change. Two agents reading the same earlier availability snapshot must not both receive a valid reservation for an exclusive slot.
A note saying that the engineer is reserved does not implement that control. The booking application or service needs a reliable way to reject conflicting writes. If it cannot provide that guarantee, keep booking under a person's control and make the uncertainty explicit. Shared conversation alone is insufficient.
The same distinction applies to customer communication. Record the approved wording and intended recipient, then confirm the send through the communication system's returned record. A recommendation, approval and completed external action are three different events.
Give each handoff enough structure to be checked
An agent's output should let the next participant decide whether it is usable. A short, consistent handoff can include the requested outcome, source references, unresolved assumptions, proposed action and the decision still needed. The receiving participant also needs to know which version of the plan it is reviewing.
In the onboarding example, a useful finding is specific: the distributor can provide access on Tuesday, according to a named correspondence record, but the engineer is already requested by the retailer. That is much easier to verify than a conclusion such as “the integration should be straightforward.”
Distinguish observations from inferences. A customer saying that access will be ready is evidence of an intention. It is not confirmation that the credentials work or that the required data is available. The technical reviewer should identify the missing check without manufacturing a result.
Keep ownership equally explicit. A participant can own the preparation of a plan without owning approval of its consequences. When a requirement changes, identify the affected proposal and request a revision from its owner. Quietly replacing another agent's conclusion makes it harder to reconstruct why a commitment changed.
The handoff should also say when to stop. A missing source, contradictory requirement or exhausted attempt budget can be a valid reason to return the work for a decision. Repeatedly passing the same uncertainty among agents consumes time without improving the evidence.
Share the right records, not every conversation
Shared memory gives participants a place to recover the current objective, accepted decisions and relevant evidence. Each agent still needs a focused view. The retailer's commercial correspondence need not be copied into the distributor agent's prompt just because the projects share an engineer.
The integration reviewer may need a limited capacity request: required skill, duration, dependencies and acceptable dates. Customer details unrelated to that decision can remain within their original access boundary. A coordinator should receive enough information to identify the conflict without assuming unlimited access to every account.
This is where context engineering matters. The information stored for a project and the information supplied to a particular model request are different things. Select the evidence needed for the current decision, preserve its source and make important omissions visible.
Freshness matters as much as retrieval. If the customer changes its access date, the earlier plan may still be useful history, but it no longer describes the current proposal. Participants need a clear way to identify the revision that applies and the decisions that remain valid. A later message should not erase the evidence behind an earlier commitment.
Shared memory also does not make a statement authoritative. Two agents repeating one unsupported assertion still provide one unsupported assertion. Preserve the original source so that apparent agreement can be checked against independent evidence.
Choose how agents coordinate
The shape of communication should follow the decision. In this example, the two customer investigations can happen independently, while the capacity check needs both results. A person can coordinate the final choice; there is no requirement to create another model based manager.
For a larger workload, a coordinator can distribute bounded assignments and collect proposals. That role needs clear limits: what it may delegate, which results it must inspect and what it must return for human judgment. Central coordination can simplify ownership, but a coordinator can still misunderstand or omit a result.
Peer collaboration can help when two specialists need to challenge a shared assumption directly. Give that exchange a purpose and a stopping condition. A conversation that ends when everyone sounds satisfied provides a weak completion rule for a business decision.
Connection protocols address a different concern. A2A's documentation describes a protocol for interaction between agent applications. MCP connects an AI application with exposed tools and data. These connections do not, by themselves, determine which customer gets Tuesday or who can approve a new commitment. Those rules still belong in the application and its operating process.
How can you tell whether the system helps?
Evaluate the complete outcome against a simpler baseline. For the onboarding example, compare one agent using the same permitted records with the proposed team of agents. Keep the task, available evidence and acceptance criteria comparable. Include the coordination and human review effort in the comparison.
A usable plan must respect capacity, expose unfinished prerequisites and distinguish proposed dates from accepted commitments. It should let the lead locate the evidence behind a recommendation without rereading every conversation.
Test situations that make coordination difficult:
Both customer agents request the same exclusive slot.
Staffing availability changes after the proposals are written.
A customer record is unavailable to one participant.
One agent returns an incomplete result or does not finish.
A proposed launch date appears in a draft message before approval.
A second attempt tries to repeat a booking that may already have succeeded.
These are proposed tests, not measured results. A successful response may be a pause with a precise explanation of the missing decision. Returning two attractive but incompatible plans is a failure even if every agent reports that its own assignment is complete.
Measure accepted outcomes, conflicting commitments, unsupported claims, elapsed time, resource use and human correction effort. More messages or more completed agent steps are weak substitutes for those measures. Count the cost of reconstructing a decision when the team needs to challenge it.
For investigation after a problem, AI observability helps connect the available execution records, source evidence and results. It cannot recover information the system never retained or prove an external effect from an agent's statement alone.
Where Swarm fits
Swarm Spaces provide shared records around work: context, discussion, outputs, Runs and human decisions. In the onboarding example, a team could retain the supplied requirements, separate account proposals, technical findings and accepted coordination decision so that another person or connected agent can continue the work.
An authorized agent can inspect relevant Space records and eligible context sources before preparing its contribution. The connected application still controls what reaches its model. A saved Task is a brief for work; a Run records an attempt. Actual execution needs an available, permitted execution route.
Access must be configured deliberately. Linking a source does not grant permission to read it. Sharing a result into another Space is a separate decision from accessing the original evidence. Human approval requirements remain with humans, and an agent cannot approve its own result where human approval is required.
These records support coordination, but the team still needs to implement its booking control, customer system connections, conflict rules and recovery behavior. Creating a Space does not automatically supply a reservation service or every routing rule described here. Nor does this example claim a native A2A integration. The public connection guide describes supported ways to connect agents and inspect their scope.
Begin with a coordination problem you can name
The first useful question is what the work requires from separate participants. A software company might need customer specific context, engineering judgment and a decision about shared capacity. Those are concrete responsibilities that can be assigned and evaluated.
Start with one bounded outcome and a small set of roles. Keep the source evidence, make conflicting proposals visible and identify who can turn a recommendation into a commitment. Add another agent when it brings a capability the system needs and can verify.
A good multi agent system leaves the company with a feasible next action and an understandable record of the decision. That is a more useful goal than having agents appear busy together.