A software agent is a computational entity that is capable of autonomous behaviour in the sense of being aware of the options available to it when faced with a decision-making task related to its domain of interest. Furthermore, such an entity is seen as part of a community of similar though heterogeneous software processes that are designed to interact with each other, often acting co-operatively to achieve mutual goals. Numerous applications exist for such software agents often in various fields of electronic commerce [Magedanz96], network management [Appleby94], intelligent user interfaces [Chin91] and real-world situations such as power management [Wittig92] and air traffic control [Steeb88].
A critical step in realising such a vision is that software agents developed by a range of enterprises are able to interoperate with one another. The need for interoperability is at the heart of an international effort to try and arrive at common specifications of the interfaces through which agents may interact. Further, an underlying requirement for seeking standard ways of interactions among agents is an agreed understanding of the basic features of all agents, that is, an agreed architecture that would apply to all agents within a community. There is a strong element of risk reduction in adopting a new technology when it is coordinated and managed by an international effort. By this we mean that an agreed architecture and form of implementation can save vast amounts of resources that an individual company would be need to expend to develop such an architecture independently.
A group of international companies and academic institutions came together in 1996 and formed an ad hoc group with the aim of seeking common specifications for software agents that may subsequently be developed further for targeted applications of interest to each individual company. This group took the name of the Foundation for Intelligent Physical Agents (FIPA) and started work in 1997. The word physical in the name of this organisation derives from the fact that some members thought that the potential applications that FIPA standards might address could include physical entities as well as software entities, ranging from robots to manufacturing applications. It is also worth noting that FIPA began its work not by articulating a common architecture but by first describing a range of application scenarios that were of interest to the founding members. These applications are mentioned further in section 4.4.5.
In the next section we briefly discuss the nature and characteristics of software agents. Section 3 is devoted to FIPA as an organization that has played an active role to create standards related to software agents. This section also described the inner workings of FIPA. Section 4 then discusses the nature of FIPA specifications: the types of documents produced by FIPA and the status of these documents as they progress through their life cycle. Additionally, this section should prove useful to those wishing to visit the FIPA web site and make sense of the various documents that are available in the FIPA specification repository. Although FIPA as a body does not implement any of the specifications produced, many of the members of FIPA acting on their own or in partnerships with other organisations create these implementations which are of interest to FIPA. Section 5 is concerned with these implementations of FIPA specifications and many are open source; readers interested in developing their own agent systems may find this section of interest. Section 6 of this paper describes current interests and activities that are occupying the members of FIPA and will therefore feature in the future output of FIPA. Concluding remarks are included in the final section of this paper.
The two most important features of agency that this paper is concerned with are autonomy and communal interaction (there are others, see [Wooldridge95]).
Autonomy implies intelligence in the sense that the autonomous behaviour of a software entity is directed with respect to its pursuance of some goal; the level of intelligence required is directly related to the complexity of this goal.
Communal interaction does not itself imply direct communication between agents since software entities may act communally merely by co-operating in carrying out a shared task without actually sending messages to one another. However, here we are interested in communicating agents, since co-operation without communication can be seen as a special case.
There are at least two other characteristics of agency that should be described. The oldest is that used by artificial intelligence (AI) researchers to refer to the rational behaviour of an intelligent software entity. AI researchers have discussed planning and goal-oriented agents as early as 1970s and here the interest is mainly focused on the behaviour of a single rational entity that can reason about its behaviour and interactions. Inter-agent communication does not play a significant part in such an analysis.
More recently, an agent has been seen as a mobile software entity that visits remote locations to discover whatever may be of interest to it [Chess95]. Again mobile agents do not rely on their ability to communicate with other similar agents, but rather on their ability to roam wide-area networks..
For the purposes of this paper, it is the feature of communication between agents that is central to the notion of agency. This is what makes standardisation a matter of importance because communicating agents need to have an agreed language to use for enable communication [O'Brien98, Charlton00]. Communication plays such a key role within the standardisation effort of software agents that autonomy and intelligence often become of secondary concern. Yet, intelligent communication does play a part in the FIPA agent communication language. One of the dominant methods of implementing intelligence within the agents of the type we are discussing here is what is known as a beliefs, desires and intentions architecture [McCarthy79]. This views an agent as having an explicit set of beliefs about itself and the rest of the world, a set of desires for goals to be achieved and intentions for carrying out actions to achieve those goals. Given that an act of communication is an action (known within the community as a communicative act for that very reason), then the semantics of such an action are given in terms of what the agent believes to be true, what it believes about the state of knowledge of another agent and its desires to make another agent come to believe some fact of mutual importance. That is, the meaning of communicative acts between agents are explained in mentalistic terms, such as what an agent believes to be true and what it desires to bring about. The standardised communicative acts that FIPA has defined have exactly such underlying semantics and are described in section 4.4.4.
This has led to a lot of research (philosophical: [McCarthy79, Dennett87] and practical: [Shoham93, Fisher94] since mentalistic semantics can only be verified by examining the way an agent is implemented in software. However, FIPA does not advocate how a developer is to implement an agent, and thus, FIPA agents do not explicitly implement such semantics, only that FIPA developers are required to implement the agents in such a way as though these semantics were being applied. One can easily see how this could become a source of concern, particularly since it is taken for granted that a standard needs a test of compliance and these semantics make compliance testing very difficult. In actual fact, we suggest that this is an inherent problem with any group of intelligent entities communicating with one another and not enough reason to prevent a standard mode of communication from being specified. This issue has motivated many researchers to look for alternative semantics that perhaps relies on some social agreements and social commitments.
Communication between software agents has other more operational details that also need attention and FIPA's agent management and message transport standards address these. It is taken as read that communication between agents will occur over a wide-area network, such at the Internet. Therefore, this requires communication that is be asynchronous and also possibly intermittent in nature. Other tasks include: Ensuring that an agent is known within a community as it comes into existence (registration); that it can be found by those wishing to communicate with it (directory and naming services); and that its deletion is properly recorded. Maintaining reliable communication between agents flows from the notion of agency that is core to FIPA agents and is thus of concern to FIPA as a standards organisation. All these various standards (termed specifications) are discussed in section 4 below, but first we give a brief further account of FIPA as an international standards making body.
The Foundation for Intelligent Physical Agents (FIPA) was formed in 1996 as a non-profit organisation registered in Switzerland, Geneva with the remit of producing software standards for heterogeneous and interacting agents and agent-based systems. To support this, FIPA has adopted and is working on specifications that range from architectures to support agents communicating with each other, communications languages and content languages for expressing those messages and interaction protocols which expand the scope from single messages to complete transactions. In the future, there are plans to extend this even further to cope with longer term relationships between agents.
In the production of these standards, FIPA requires input and collaboration from its membership and from the field of software agents in general to build specifications that can be used to achieve interoperability between agent-based systems developed by different companies and organisations.
FIPA undertakes its work at meetings that are held four times a year and conducts its standardisation process in a collaborative and open manner, that is, the standards are produced in an open, discussion-based environment and are agreed on by contributing companies and organisations.
In addition to creating standards for interoperability, FIPA also allows companies and organisations that attend and contribute to FIPA specifications to reduce the risk of their research efforts by creating useable software that will be implemented and supported by others.
The core mission of FIPA is to facilitate the interworking of agents and agent systems across multiple vendors' platforms. This is expressed more formally in FIPA's official mission statement:
The promotion of technologies and interoperability specifications that facilitate the end-to-end interworking of intelligent agent systems in modern commercial and industrial settings.
Note that the emphasis here is on the practical commercial and industrial uses of agent systems. However, FIPA also focuses on intelligent or cognitive agents, that is, software systems that may have the potential for reasoning about themselves and other systems that they may encounter.
The core message is that through a combination of speech acts, predicate logic and public ontologies, FIPA can offer standard ways of interpreting communication between agents in a way that respects the intended meaning of the communication. This is much more ambitious than, for example, XML, which only aims to standardize the syntactic structure of documents.
FIPA is organised and structured according to two groups; those involved in the administration and support of FIPA and those in the production and development of standards for interoperating software agents (see Figure 1).
The FIPA Board of Directors (BoD) are responsible for managing and conducting the business of the FIPA organisation. This involves deciding on working practices, policies and procedures that FIPA will adopt to help provide an environment in which standards for software agents can be developed.
Figure 1: Organisational Structure of FIPA
The FIPA Architecture Board (FAB) is the authority within FIPA that is responsible for ensuring the consistency, accuracy and suitability of technical work that is being undertaken by FIPA. It is the responsibility of the FAB to oversee the work being undertaken by Technical Committees and Working Groups, and to approve the advancement of FIPA specifications to a publishable state.
Input is taken through work plans and if the FAB approves a work plan, then it is assigned it to an existing Technical Committee or Working Group (or a new one is created).
FIPA's core standardisation activities are centred on the creation and maintenance of specifications that are carried out by Technical Committees (TCs). TCs carry out the technical work of FIPA and their remit is defined by a work plan that is approved by the FAB. This work plan contains a description of the work and goals that the TC will undertake for its lifetime. Normally, a TC will either create new specifications and/or modify existing specifications.
TCs are created by the FAB in collaboration with the BoD. To create or modify FIPA specifications, a work plan must be created which details the new specification to create or the modifications to make to existing specifications.
Working Groups (WGs) are designed to carry out other aspects of FIPA's work, which are not necessarily defined by technology; they may have an application focus or be responsible for coordinating implementation activities. As with a TC, their remit is defined by a work plan that is approved by the FAB and contains a description of the work that the WG will undertake for a given period of time. Normally, a WG will create informative documents or propose changes to existing specifications to either the appropriate TC or the FAB.
Special Interest Groups (SIGs) undertake auxiliary work that is of interest to sections of FIPA membership, such as liasing with other standards bodies and dealing with emerging technologies which might be suitable for standardisation.
FIPA specifications represent a collection of standards that are intended to promote the interoperation of heterogeneous software agents and the services that they can represent. To this end, as per FIPA's mission statement, the intent is to provide end-to-end interoperability between agent-based systems that conform to FIPA specifications.
In the past, FIPA used to release specifications on a yearly basis, with the past two published specification sets named FIPA97 and FIPA98. However, in January 2000, FIPA adopted a new procedure for classifying, organising and releasing specifications. This section aims to explain how FIPA operates with regard to its specifications in this new regime.
FIPA specifications are either components or profiles. A component specification describes a logically self-contained specification for a technology or tightly coupled set of technologies. Pragmatically, it is indivisible, particularly with respect to establishing conformance.
A profile specification describes how a set of component specifications may be used to collectively define a higher-order entity for the purposes of conformance.
Each FIPA specification is represented by a specification number and has a formal and informal specification identifier.
An informal specification identifier is designed to be used internally within FIPA to reference a specific instance of a specification at a particular point in its life cycle. Informal specification identifiers are composed from the life cycle status of the specification, its specification type and its specification number. For example, XC00023 is read as: "Experimental status component specification number 00023."
A formal specification identifier is designed to reference FIPA specifications from other FIPA specifications and external documents, such as conference or journal papers. A formal specification identifier is composed from the keyword FIPA and the specification number, for example, FIPA00023. A formal specification identifier does not refer to a specific instance of a specification, but refers instead to the latest version according to the specification life cycle.
Figure 2: Specification Life Cycle
FIPA specifications are published according to their position in the specification life cycle (seeFigure 2). The intent of this life cycle is to chart the progress of a given specification from its inception through to its ultimate resolution. Standard and Obsolete are end-states in the life cycle.
Preliminary status is the initial conception of specifications and are generated and approved by TCs. A Preliminary specification is considered to be a draft under construction. It is liable to undergo revisions and it has an informal specification identifier that begins with the letter P.
A Preliminary specification needs to be submitted and approved by the FAB to reach an Experimental status. An Experimental specification is considered to be stable for a period of two years and is judged to be suitable for implementation. It has a new informal specification identifier beginning with letter X.
When an Experimental specification has been successfully implemented in more than one FIPA-compliant agent platform and it has the approval of the FAB and the FIPA membership, it may be advanced to Standard status where it receives an informal specification identifier that begins with S.
A Standard status specification is considered to be a stable and formally published standard that has been approved and endorsed by the FIPA standards body. There is no advancement of a specification beyond Standard, except in the case where the specification becomes unnecessary and is moved to Deprecated status.
A Deprecated specification is one that has been identified as potentially unnecessary to the FIPA standard. Such a specification may have been rendered unnecessary due to technology changes or changes in other standards or FIPA specifications. All Deprecated specifications have an informal specification identifier that begins with D.
Deprecated status specifications have a grace period (normally six months) before they are moved to Obsolete status in which developers can modify their implementations to no longer use the technology contained in the deprecated specification.
An Obsolete specification is one that has been identified unnecessary to the FIPA standard. All Obsolete specifications have an informal specification identifier that begins with O.
FIPA specifications cover wide ranges of issues that are discussed shortly. It is important to note that FIPA specifications do not attempt to describe how developers should implement their agent-based systems, not do they attempt to specify the internal architectures of agents. Instead, they provide the interfaces through which agents can communicate.
Figure 3: Structure of FIPA Specifications
Each specification is given a subject association that describes general area in which it belongs in the FIPA specification structure (see Figure 3); these subject associations are described below.
The purpose of the FIPA Abstract Architecture [FIPA00001] is to foster interoperability and reusability. To achieve this, it is necessary to identify the elements of the architecture that must be codified. Specifically, if two or more systems use different technologies to achieve some functional purpose, then it is necessary to identify the common characteristics of the various approaches. This leads to the identification of architectural abstractions: abstract designs that can be formally related to every valid implementation.
By describing systems abstractly, the relationships between fundamental elements of agent systems can be explored. By describing the relationships between these elements, it becomes clearer how agent systems can be created so that they are interoperable. From this set of architectural elements and relations, a broad set of possible concrete architectures can be derived, which will interoperate due to the fact that they share a common abstract design.
Furthermore, because an abstract architecture permits the creation of multiple concrete realizations, it must provide mechanisms to permit them to interoperate. This includes providing transformations for both transport protocols and message encodings, as well as integrating these elements with the basic elements of the environment.
For example, one agent system may transmit messages using IIOP whilst a second may use IBM's MQ-series enterprise messaging system. An analysis of these two systems (how senders and receivers are identified, and how messages are encoded and transferred) allows us to arrive at a series of architectural abstractions involving messages, message encodings and transport addresses.
The FIPA Abstract Architecture makes a distinction between those elements which can easily be defined in an abstract manner, such as agent message transport, FIPA ACL, directory services and content languages, and between those elements that cannot, such as agent management and agent mobility. These are considered difficult to represent abstractly since they occur too close to the concrete realisation (implementation) of an agent system and very little commonality can be derived from analysing them. Yet, these issues will have to be addressed by developers and the abstract architecture will provide a number of instantiation guidelines in the future for specific groupings of implementation technologies.
The first concrete realization of the FIPA Abstract Architecture will be the JAS project that is being developed as part of the Java Community Process.
The FIPA Agent Message Transport Specifications deal with the delivery and representation of messages across different network transport protocols, including wireline and wireless environments.
At the message transport level, a message consists of a message envelope and a message body. The envelope contains specific transport requirements and information that is used by the Message Transport Service (MTS) on each agent platform to route and handle messages. The message body is the real payload and is usually expressed in FIPA ACL but is opaque to the MTS since it may be compressed or encoded.
Figure 4: Agent Message Transport Reference Model
The agent message transport reference model provides facilities for (see Figure 4):
· General support for an MTS within an agent platform [FIPA00067].
· Guidelines for using specific Message Transport Protocols (MTPs), such as IIOP [FIPA00075], HTTP [FIPA00084] and WAP [FIPA00076].
· Message envelope representations that are suitable for each MTP, such as an XML encoding for HTTP [FIPA00085] and a bit-efficient encoding for WAP [FIPA00088].
· FIPA ACL representations, such as a string encoding [FIPA00070], an XML encoding [FIPA00071] and a bit-efficient encoding [FIPA00069].
The MTS on each agent platform can support any number of message transport protocols and will normally translate between a FIPA-supported MTP that is used for interoperable communication between heterogeneous agent platforms (such as XML over HTTP) and an MTP that is used internally to the agent platform (such as Java objects over the Java Messaging Service).
Consequently, the components of the MTS are designed to be modular and extensible to handle different message transport protocols, message envelope and FIPA ACL representations in the future.
The FIPA Agent Management Specification [FIPA00023] provides the framework within which FIPA agents exist and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents.
Figure 5: Agent Management Reference Model
The entities contained in the agent management reference model (see Figure 5) are logical capability sets, that is, services and do not imply any physical configuration. Additionally, the implementation details of agent platforms and agents are the design choices of the individual agent system developers.
The reference model describes the primitives and ontologies necessary to support the following services in an agent platform:
· White pages, such as agent location, naming and control access services, which are provided by the Agent Management System (AMS). Agent names are represented by a flexible and extensible structure called an agent identifier, which can support social names, transport addresses, name resolution services, amongst other things.
· Yellow pages, such as service location and registration services, which are provided by the Directory Facilitator (DF).
· Agent message transport services as described previously in section 4.4.2.
In conjunction with the FIPA Agent Message Transport Specifications, the FIPA Agent Management Specification also provides support for intermittently connected devices, such as laptop computers and personal digital assistants through message buffering, redirection and proxying.
Communication between agents in FIPA is based on a model of semantically grounded communication, that is, communication that is pre-defined, semantically rich and well understood by agents.
The basis of communication between FIPA agents is through the use of communicative acts (also called performatives) that are based on speech act theory [Austin62; Searle69]. Communicative acts are illocutionary verbs that tell a receiving agent in which context to interpret the contents of the enclosed message. This method of communication is illocutionary in nature, not perlocutionary since the sending agent expects the message to be understood, but has control over the effect of the message. FIPA specifies a number of communicative acts, such as, request, inform and refuse, [FIPA00037] in a well-defined manner that is independent from the overall content of the message.
The message that is supplied with a communicative act is itself wrapped in a well-specified envelope, called an agent communication language (ACL). An ACL provides mechanisms for adding context to the message content and the communicative act, such as identifying the sender and receiver, and the ontology and interaction protocol of the message. The FIPA ACL [FIPA00061] was originally based upon ARCOL [Sadek92] with a number of revisions from KQML [Finin97]. The actual content of a message is expressed in a content language, such as the FIPA semantic language [FIPA00008], a constraint choice language [FIPA00009], KIF [FIPA00010] or RDF [FIPA00011].
Finally, the set of FIPA interaction protocols [FIPA00025-FIPA00036] were based on work by [Lux98] and [Haugeneder94], and describe entire conversations between agents for the purpose of achieving some interaction or effect, such as, auctioning, issuing a call for proposals, negotiating brokering services and the registration and deregistrations of subscriptions.
· Personal Travel Assistance: individualised, automated access to travel services [FIPA00080].
· Audio-Visual Entertainment and Broadcasting: negotiating, filtering and retrieving audio-visual information, in particular for digital broadcasting networks [FIPA00081].
· Network Management and Provisioning: automated provisioning ofdynamic Virtual Private Network services where a user wants to set up a multi-media connection with several other users [FIPA00082].
· Personal Assistant: management of a user's personal meeting schedule, in particular in determining the time and place arrangements for meetings with several participants [FIPA00083].
Additionally, the Agent Software Integration specification [FIPA00079] contains a guide for integrating legacy software, that is, software that does not communicate using FIPA ACL.
British Telecom (UK)
Communication Technologies (Japan)
Comtec Agent Platform
Java Agent Development Framework (JADE)
Fujitsu Laboratories of America (USA)
April Agent Platform (AAP)
Sun Java Community Process (International)
Java Agent Services (JAS)
Table 1: Available Open Source FIPA Agent Platform Implementations
Different companies and organisations have implemented sixteen FIPA platforms, and a number of them are freely accessible under open source (see Table 1). These FIPA platforms have been distributed and tested in large-scale projects, which collectively have been downloaded several thousands of times.
FIPA specifications are also being used to develop a number of agent-based applications:
· The AgentCities European Union project is encouraging the implementation of heterogeneous FIPA agent platforms and a test bed of services, such as tourist services.
· The CRUMPET European Union project is developing location-aware, context-driven services for nomadic users.
· The EDEN-iW European Union project will develop an agent infrastructure to support high-level access to and integration of distributed inland water data sources.
· The FACTS European Union project was aimed at implementing audio-visual entertainment and broadcasting, telecom service reservation and personal travel assistant.
· FETISH is an European Union project cluster for tourism with the CRUMPET project being one of about 10 projects in this cluster. The cluster aims to focus on a common infrastructure and ontology for e-tourism.
· The FIPA-NET project is implementing diagnostic and test tools for FIPA agent platforms.
· The LEAP European Union project is developing an extensible FIPA agent platform for small, wireless devices.
FIPA TCs and WGs are currently working on a number of areas that are being specified for standardisation:
· Domains and Policies TC
The general focus of this TC is the application and management of policies and constraints on agents and collections of agents to control their behaviour. This requires providing mechanisms for describing what policies can be applied to which agents and in what environments, for example, what controls are available and how to report inability or conflict when applying policies. The range of possible mechanisms for enforcing policies can extend from reputation and social sanctions to complete withdrawal of supporting services for a non-conforming agent. This TC will explore use cases in support of both pre-condition constraints and post-condition enforcement.
· Agreements Management TC
The FIPA Agent Management Specification places it focus on defining basic operations for managing small groups of agents which are regarded as simple and potentially unrelated entities. This approach allows FIPA developers to construct and execute small agent communities, but shows its limits in the large scale deployment of several thousands of cooperating and collaborating agents which are potentially spread across numerous, distributed platforms. The Agreements Management TC is concerned with providing support for agent configuration management which would allow agent platforms to manage and maintain large constellations of agent platforms and agents, to define configurations and dependency links between these entities and to provide management and configuration methods for controlling federated agent platforms and communities of agents. As part of this work, it is necessary to consider agreements, or contracts, between agents and to specify the services within those agreements. An agreement to provide a service of some kind is the goal of a process of negotiation between agents and the basis for their collaborative activity.
· Gateways TC
The aim of this TC is to enhance the nomadic application environment and its objective is to look at the interoperability of the existing FIPA message transport services by using different transport protocols and message encoding, and, to support messaging in the environment of nomadic application. This requires investigating issues such as support for disconnected modes of operation, roaming from one mediator to another one, profiles that specify capabilities of gateways and mobile terminals, and a bit-efficient representation of information, including the message envelope and the content of the ACL message.
· Product Design and Manufacturing WG
The objective of this WG is to promote and support the development of agent applications within the manufacturing domain, such as workflow management, enterprise integration, supply chain management, information management, scheduling, e-commerce and control of transportation.
· AgentCities WG
The AgentCities WG aims to encourage and support the development of a continually available, publicly accessible network of deployed FIPA agent services. This network is to serve as an experimental test bed for interoperability testing, application development and as a showcase for FIPA technology. An 'AgentCity' is a metaphor for a virtual set of agents and services that represent a real place or city and as the network of cities grows, there are rich potential interactions between many different agents and consequently the possibility of complex business models emerging.
Some FIPA SIGs are currently considering other technologies for standardisation:
· Ontology SIG
Will investigate the nature and realisation of ontologies and ontology descriptions within FIPA specifications.
· Security SIG
Will investigate the security-related issues within FIPA architectures and formulate a long-term strategy for the integration of security features into FIPA specifications.
· Peer-to-Peer SIG
Will investigate the links between FIPA technology and new paradigms for system-to-system interaction.
FIPA devoted its first years to specifying the basic elements of an agent-based world, defining an agent communication language, message transport system, management primitives and integration to existing software. This initial specification set has been implemented by several different organisations and companies and has shown the way for further improvement towards a more modular agent environment that is capable of evolution and can integrate new technologies, such as new transport protocols and moving towards higher levels of abstraction. Four of these new implementations are already accessible in open source and new FIPA implementations enable agents to run on small wireless devices such as PDAs. As such, FIPA is making an important contribution to the practical and commercial viability of agent systems by providing the basis to develop agent-based applications.
FIPA is now looking ahead to some of the major challenges that are already beginning to arise in the networked world and is working on specifications for:
· Domains, policies, agreements and contracts, security, dependencies between large numbers of agents, and agent usage of ontology.
· Key applications such as product design and manufacturing and peer-to-peer systems.
· Large-scale deployment of agent systems in open environments.
The authors would like to express their thanks to all of the people and organisations (both past and present) who have contributed to the FIPA standardisation process.
Appleby, D. and Steward, S, Mobile Software Agents for Control in Telecommunications Networks. In: British Telecom Technology Journal, 12(2), 1994.
Austin, J L, How to do Things with Words. Oxford University Press, 1962.
Charlton, P, Cattoni, R, Potrich, A and Mamdani, E, Evaluating the FIPA Standards and its Role in Achieving Cooperation in Multi-Agent Systems. In: Proceedings of HICS-33 on Software Technology, Multi-Agent Systems Minitrack, Hawaii, 2000.
Finin, T, Labrou, Y and Mayfield, J, KQML as an Agent Communication Language. In: Software Agents, Bradshaw, J (Ed), MIT Press, 1997.
FIPA Abstract Architecture Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA SL Content Language Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA CCL Content Language Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA KIF Content Language Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA RDF Content Language Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Nomadic Application Support Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Interaction Protocol Library Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Request Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Query Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Request When Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Contract Net Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Iterated Contract Net Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA English Auction Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Dutch Auction Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Brokering Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Recruiting Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Subscribe Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Propose Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA ACL Message Structure Specification. Foundation for Intelligent Physical Agents, 2000
FIPA Agent Message Transport Service Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA ACL Message Representation in Bit-Efficient Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA ACL Message Representation in String Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA ACL Message Representation in XML Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Message Transport Protocol for IIOP Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Message Transport Protocol for WAP Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Software Integration Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Personal Travel Assistance Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Audio/Visual Entertainment and Broadcasting Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Network Management and Provision Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Personal Assistant Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Message Transport Protocol for HTTP Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Message Transport Envelope Representation in XML Specification. Foundation for Intelligent Physical Agents, 2000.
FIPA Agent Message Transport Envelope Representation in Bit-Efficient Encoding Specification. Foundation for Intelligent Physical Agents, 2000.
Fisher, M, A Survey of Concurrent METATEM—The Language and its Applications. In: Proceedings of the First International Conference on Temporal Logic, Gabbay, D M and Ohlbach, H J (Eds), Lecture Notes in Artificial Intelligence, 827, Springer-Verlag, 1994.
Chess, D, Grosof, B, Harrison, C, Levine, D, Parris, C and Tsudik, G, Itinerant Agents for Mobile Computing. In: IEEE Personal Communications, 2(5), 1995.
Chin, D N, Intelligent Interfaces as Agents. In: Intelligent User Interfaces, Sullivan, J W and Tyler, S W (Eds), ACM Press, 1991.
Dennett, D C, The Intentional Stance. MIT Press, 1987.
Haugeneder, H (Ed), IMAGINE Final Project Report. IMAGINE Technical Report Series, 1994.
Lux, A and Steiner, D, Understanding Cooperation: An Agent's Perspective. In: Readings in Agents, Huhns, M N and Singh, M P (Eds), Morgan Kaufmann, 1998.
Magedanz, T, Rothermal, K and Krause, S, Intelligent Agents: An Emerging Technology for Next Generation Telecommunications? In: Proceedings of the INFOCOM Conference, San Francisco, USA, March 1996.
McCarthy, J, Ascribing Mental Qualities to Machines. In: Philosphical Perspectives in Artificial Intelligence, Ringle, J (Ed), Harvester Press, 1979.
Nwana, H, Ndumu, D, Lee, L and Collis, J, ZEUS: A Toolkit for Building Distributed Multi-Agent Systems. In: Applied Artificial Intelligence Journal, 13(1), 1999.
O'Brien, P D and Nicol, R C, FIPA—Towards a Standard for Software Agents. In: British Telecom Technology Journal, 16(3), 1998.
Sadek, M D, Bretier, P, Cadoret, V, Cozannet, A, Dupont, P, Ferrieux, A and Panaget, F, A Co-operative Spoken Dialogue System Based Upon a Rational Agent Model: A First Implementation of the AGS Application. In: Proceedings of the ESCA/ETR Workshop on Spoken Dialogue Systems: Theories and Applications, Denmark, 1995.
Searle, J R, Speech Acts. Cambridge University Press, 1969.
Shoham, Y, Agent-Oriented Programming. In: Artificial Intelligence, 60(1), 1993.
Steeb, R, Cammarata, S, Hayes-Roth, F A, Thorndyke, P W and Wesson, R B, Distributed Intelligence for Air Fleet Control. In: Readings in Distributed Artificial Intelligence, Bond, A H and Gasser, L (Eds), Morgan-Kaufmann, 1988.
Wittig, T (Ed), ARCHON: An Architecture for Multi-Agent Systems. Ellis Horwood, 1992.
Wooldridge, M and Jennings, N R, Intelligent Agents: Theories and Practice. In: Knowledge Engineering and Review, 10(2), 1995.
 See http://www.fipa.org/
 BDI, pronounced 'beady eye'.
 It is not anticipated that there is a need to generalize this further, since profiles can be defined in terms of other profile specifications.
 Java Agent Services, JSR-000087, see: http://www.java-agent.org/
 The message envelope representation for IIOP is expressed in IDL and is specified in [FIPA00075].
 IST-2000-28384 and IST-2000-28385.
 The Creation of User-Friendly Mobile Services Personalised for Tourism, IST-1999-20147.
 Environmental Data Exchange Network for Inland Water, IST-2000-29317.
 FIPA Agent Communication Technologies and Services, ACTS-1997-AC317.
 Federated European Tourism Information System Harmonisation.
 Lightweight Extensible Agent Platform, IST-1999-10211.