Several taxonomies have been presented previously for the related field of DAI. One example is Decker's division mentioned above [7]. In this same survey of DPS, Decker presents four dimensions of DAI:
More recently, Parunak has presented a taxonomy of MAS from an application perspective [8]. From this perspective, the important characteristics of MAS are:
The taxonomy presented in this article is organized along the most important aspects of agents (as opposed to domains): degree of heterogeneity and degree of communication. Communication is presented as an agent aspect because it is the degree to which the agents communicate (or whether they communicate), not the communication protocols that are available to them, that is considered. All the other aspects of agents in MAS are touched upon within the heterogeneity/communication framework. For example, the degree to which different agents play different roles is certainly an important MAS issue, but here it is framed within the scenario of heterogeneous non-communicating agents (it arises in the other two scenarios as well). Domain issues are discussed separately in Section 4.2.
The three combinations of heterogeneity and communication considered in this article (homogeneous non-communicating agents; heterogeneous non-communicating agents; and heterogeneous communicating agents) are presented in order of increasing complexity and power (see Figure 2).
Figure 2: The major categories of the intrafield taxonomy and how they
relate to the major dimensions. Single agent systems are more
centralized and complex than multiagent systems.
Many of the issues that arise in the earlier scenarios also apply in the later scenarios. Nevertheless, they are only mentioned again in the later scenarios to the degree that they differ or become more complex. Notice that single agent systems are presented as being more complex than multiagent systems. The intuition behind this presentation will become clear as the article proceeds.
The complexity (and accompanying power) of the different scenarios is important, especially from the perspective of system engineering. In general, system builders should stay within the simplest possible multiagent scenario. Using a scenario with more power than is needed only makes programming and debugging unnecessarily complex and difficult. In a sense, this recommendation is the system designer's version of Occam's razor: it allows anybody trying to reverse-engineer the system to safely use Occam's razor!
The multiagent scenarios along with the issues that arise therein are summarized in Table 2. The techniques that currently exist to address these issues are described in detail in Sections 6 - 8.
Table 2: Issues arising in the various scenarios