Two obvious questions about any type of technology are:
The most important reason to use MAS when designing a system is that some domains require it. In particular, if there are different people or organizations with different (possibly conflicting) goals and proprietary information, then a multiagent system is needed to handle their interactions. Even if each organization wants to model its internal affairs with a single system, the organizations will not give authority to any single person to build a system that represents them all: the different organizations will need their own systems that reflect their capabilities and priorities.
For example, consider a manufacturing scenario in which company X produces tires, but subcontracts the production of lug-nuts to company Y. In order to build a single system to automate (certain aspects of) the production process, the internals of both companies X and Y must be modeled. However, neither company is likely to want to relinquish information and/or control to a system designer representing the other company. Perhaps with just two companies involved, an agreement could be reached, but with several companies involved, MAS is necessary. The only feasible solution is to allow the various companies to create their own agents that accurately represent their goals and interests. They must then be combined into a multiagent system with the aid of some of the techniques described in this article.
Another example of a domain that requires MAS is hospital scheduling as presented in [11]. This domain from an actual case study requires different agents to represent the interests of different people within the hospital. Hospital employees have different interests, from nurses who want to minimize the patient's time in the hospital, to x-ray operators who want to maximize the throughput on their machines. Since different people evaluate candidate schedules with different criteria, they must be represented by separate agents if their interests are to be justly considered.
Even in domains that could conceivably use systems that are not distributed, there are several possible reasons to use MAS. Having multiple agents could speed up a system's operation by providing a method for parallel computation. For instance, a domain that is easily broken into components--several independent tasks that can be handled by separate agents--could benefit from MAS. Furthermore, the parallelism of MAS can help deal with limitations imposed by time-bounded reasoning requirements.
While parallelism is achieved by assigning different tasks or abilities to different agents, robustness is a benefit of multiagent systems that have redundant agents. If control and responsibilities are sufficiently shared among different agents, the system can tolerate failures by one or more of the agents. Domains that must degrade gracefully are in particular need of this feature of MAS: if a single entity--processor or agent--controls everything, then the entire system could crash if there is a single failure. Although a multiagent system need not be implemented on multiple processors, to provide full robustness against failure, its agents should be distributed across several machines.
Another benefit of multiagent systems is their scalability. Since they are inherently modular, it is much easier to add new agents to a multiagent system than it is to add new capabilities to a monolithic system. Systems whose capabilities and parameters are likely to need to change over time or across agents can also benefit from this advantage of MAS.
From a programmer's perspective the modularity of multiagent systems can lead to simpler programming. Rather than tackling the whole task with a centralized agent, programmers can identify subtasks and assign control of those subtasks to different agents. The difficult problem of splitting a single agent's time among different parts of a task solves itself. Thus, when the choice is between using a multiagent system or a single agent system, MAS is often the simpler option. Of course there are some domains, such as chess playing, that are more naturally approached from an omniscient perspective--because a global view is given--or with centralized control--because no parallelism is possible and there is no action uncertainty [12]. Single agent systems should be used in such cases. Otherwise, when parallelism and modularity are possible, system designers should opt for the simplest multiagent scenario possible (see Figure 2).
Finally, multiagent systems can be useful for their illucidation of intelligence [7]. As Gerhard Weiß put it: ``Intelligence is deeply and inevitably coupled with interaction'' [13]. In fact, it has been proposed that the best way to develop intelligent machines at all might be to start by creating ``social'' machines [14]. This theory is based on the socio-biological theory that primate intelligence first evolved because of the need to deal with social interactions. Reasons presented above to use MAS are summarized in Table 3.
Table 3: Reasons to use Multiagent Systems