The parts from which the agent is composed will in the following be denoted theagent constituent, while the structure of their composition is denoted theintra-agent architecture. The choice of intra-agent architecture is then an essential limiting factor of an agent’s capabilities. Indeed, it is likely that different problems can only be solved by agent-based systems which employ different intra-agent architectures#4.
The following agent constituents are identified as being necessary to build an agent as defined in section 1.1:
The deliberative constituent is responsible for the representation and maintenance of the agent’s mental state, and thus realises the agent’s pro-activeness and mentalistic aspects. In popular terms, the delibera-tive constituent can be described as the brain of the agent.
The reactive constituent is responsible for the agent’s perception of the physical environment, as well as its reaction to the environment, which includes effectuation of any actions intended by the deliberative con-stituent. The reactive constituent thus covers the agent’s autonomy and reactivity. In popular terms, the reactive constituent can be regarded as the motor, sensory and central nervous system of the agent.
The communicative constituent provides a means for the agent to in-teract with its social environment, thus covering the social ability. How-ever, in this document the communicative constituent is viewed solely as amedium as well as aprotocol for communication: only the reactive constituent can effectuate actions. Therefore, the communicative con-stituent will in popular terms correspond to the language and the air which is used to transfer verbal communication.
1.3.1 The Deliberative Constituent
The deliberative constituent has proven to be the most problematic con-stituent to realise in practice. Indeed, much effort (see e.g. [35, 36] for
1.3 What is Required to Build an Agent? 29 an overview) has been put into the question of developing logics which are computable as well as expressive enough to allow agent behaviour to be specified in terms of such logics. To date, two different approaches have been used with some success:
1. Specifying an agent in terms of temporal logic specifications, and di-rectly executing these specifications [8]. While providing a formal framework for specification and verification of agents [9], this does however put serious restrictions on the choice of an intra-agent archi-tecture.
2. Using a (restricted) first-order logical language in conjunction with modal operators in order to represent and to reason about the men-tal attitudes of the agent. Numerous examples exist: dMARS [3], is based on beliefs and intentions, using a temporal language to specify goals. AgentSpeak(L) [28] operates with beliefs, desires and inten-tions. PLACA [33, 32] adds plans to the beliefs, capabilities and commitments of Agent-0 [31, 30]. Interestingly, 3APL [19] allows an arbitrary (first order) logical language to be used for representation of beliefs.
While dMARS, AgentSpeak(L) and 3APL all have been formally specified, they do not directly provide the possibility of transforming an agent pro-gram into an implementation#12. The semantics of PLACA and Agent-0 has not been as strictly specified as the other languages just mentioned; on the other hand, they include an experimental interpreter [33, 34], which, however, enforces a specific intra-agent architecture#4.
1.3.2 The Reactive Constituent
In itself, implementation of a reactive constituent does not cause serious problems. However, when it comes to the balance between reactivity and deliberation, problems begin to occur. The question of how to make an agent’s beliefs correspond to the reality of its environment is by no means easily answered [27]. Furthermore, the balance between reactivity and de-liberation is not very well investigated, and few attempts have been made to address this problem: existing systems mainly focus on either of the two areas, instead of trying to unify them#5 [23]. For example, Agent-0 and PLACA assume a fixed execution cycle in which all received messages can be processed; such an assumption cannot be fulfilled in practice, where
multiple concurrently executing agents often will be desirable, if not re-quired.
1.3.3 The Communicative Constituent
Although the ability to communicate has been defined as synonymous with agency itself — “An entity is a software agent if and only if it communicates correctly in an agent communication language” [16] — such a definition is too narrow in practice: the ability to communicate is a necessary but not a sufficient condition when describing what an agent is1.1. The importance of communication should not be belittled, however: “It is because agents communicate that they can cooperate, coordinate their actions, carry out tasks jointly and so become truly social beings” [7]. Additionally, agent-based communication can be used as a means of ensuring interoperability with legacy systems [16, 22], if a suitable intermediate agent communication layer is added to the system.
In contrast to almost every area involved in building multi-agent systems, the area of of inter-agent communication has actually been the subject of a substantial standardization effort. Already in 1993, the first standardised ACL, KQML, was proposed [18]. Although the standard has never officially progressed beyond the draft stage, quite much subsequent work, most no-tably [24], has been carried out in order to improve the original proposal of [18]. Furthermore, KQML has actually developed into a de-facto standard for inter-agent communication [38], and many toolkits providing KQML functionality are available; one example of such a toolkit is described in [1].
A more recent development has been undertaken by FIPA, the result of which is FIPA ACL. Surprisingly, FIPA ACL’s syntax resembles KQML to a very high degree, but the language has been more thoroughly and rigorously specified in terms of its semantics, although it is still at the ex-perimental stage. As a notable feature, the specification of FIPA ACL has been split into many smaller specifications, each dealing with a separate area: Theinter-agent architecture(the infrastructure required to exchange messages) is the subject of theAbstract Architecture Specification[10]; Mes-sage structure (the syntax of a single message) is treated in the Message Structure Specification[11]; Languages to encodemessage contents(the in-formation which is transferred in a message) are described in theContent Language Library Specification [13] and the documents referenced therein;
1.4 How do Agents and Objects Correlate? 31