FIPA: Requirements for Agent Applications and Systems

This document is a refinement of the requirements document (nyrequirements.doc) generated at the second FIPA meeting in New York, which was then further revised by Agostino Poggi (fipareq.html). The original list was unstructured. Agostino introduced some structuring categories, and proposed that some requirements should be mandatory, and others are useful in some, but not all, circumstances. In this revision, I have attempted to further refine the categories, and clarify the requirements that agent systems will generate, for which there may be a number of potential solutions.

Intended use of this document

This document is one of a set of inputs to the FIPA standardisation activity. Other documents suggest a framework for agent applications, and identify potential applications of agent technology. Here, we attempt to characterise the requirements of agent technology consumers (see below), in order to assist the evaluation of agent technology components for inclusion in the FIPA standard.

Target audience for this document

We can consider, roughly speaking, three groups of consumers of agent technology:

• end-users, who make use of agent-based systems or applications to complete their tasks and activities;
• designers and developers, who identify user needs, then develop and market or otherwise make available the agent-based solutions to the end-users;
• designers and developers of agent tools, frameworks and shells.

This document is for use by members of FIPA, to help us to consider appropriate pieces of technology that will be of value to one or more of the above groups and help to meet their requirements. The requirements below are stated on behalf of these groups. In addition, we may hypothesise a fourth, rather harder to define interested party, in which we assume the future existence of a shared, large scale agent community. Analogously to the Internet today, individuals or companies may contribute components (agents or other resources) to the community independently, with no one group in overall control. Arguably, this scenario, if it comes to pass, will not introduce any fundamentally new requirements, but will make several of the existing ones even more stringent - for example: security, trustability, scalability and interoperability.

List of Requirements

The sections below characterise, informally, the requirements that the above listed stakeholders in agent technology. Clearly, no single agent system will exhibit all of these requirements simultaneously, nor will they place uniform emphasis on the importance of each requirement that the system does have. This list then may be used to evaluate proposals for technologies to be included in the standard by considering the degree of support for requirements they address, and whether the technology makes more difficult the meeting of any other requirements. Understanding the trade-offs implied by a proposed technology will be a key part of the process of developing the FIPA standard.

1. Agent to agent interaction

• Resource discovery: agents need to be able to discover the existence of other resources (for example, other agents able to perform given tasks or supply particular kinds of information) which they can make use of. A corollary is that resources must be able to be specified in a non location-specific way, that is, semantic or content-based addressing.
• Resource location: knowing the identity of a resource type or category, agents need to determine where they can access it (e.g. it's URL).
• Communication with other agents: an agent needs to have a means of communicating with other agents. This includes point-to-point communication, broadcasting, narrowcasting, etc.
• Communication bandwidth: agents may need to be able to communicate high-bandwidth signals (multimedia). Agents should be able to make decisions about the capabilities of the communications options that they have access to.
• Robust interaction: interactions between agents need to be robust, able to identify and recover from a variety of exception conditions
• Flexible interaction: interactions between agents need to be flexible and dynamic, that is, they are not precisely scripted in advance, and are subject to changes in the agents' environment
• Adaptable interaction: agents need to be able to interact with other agents whose capabilities are not known in advance, or with known agents in unpredicted ways.
• Security - authentication: agents need to be able to authenticate the identity and legitimacy of other agents, resources and transactions.
• Security - auditing: the activities agents need to be able to be audited, and may have to be legally defensible (e.g. purchasing decisions or contract agreements).
• Security - trust: some agent architectures allow agents to migrate. In such cases, the host of a mobile agents needs to be able to trust that an agent executing in the host's environment is trustworthy. Also, agents should trust that information they disclose about themselves, or more importantly their user, is not misused by other agents.
• Reasoning about self: agents need to be able to reason about their own state, that of other agents, or about the meaning of messages. Examples include: translation of messages into different formalisms, such as to or from natural language; making agreements that respect existing commitments; [others?].
• Enter into negotiations: agents need to be able to negotiate with other agents for the provision of resources, etc. Ideally, this would be without pre-commitment to a mandated negotiation mechanism (e.g. contract nets); the requirement is for a general protocol for negotiation, parties to which may be implemented differently.
• Enforce agreements: agents may need to have some means of recourse if a negotiated agreement is broken.
• Revise agreements: agents may need to change agreements they have entered into if their circumstances change.
• Advertising or publishing of services: agents need to be able to inform other agents, and users, of the services they can perform or the resources they represent. This requires a means of representing such services, and a means of disseminating this representation to other interested parties.
• Interaction in heterogeneous societies: agents with different cognitive architectures (e.g. deliberative, symbolic agents and reactive, neural-net based agents) need to be able to interact despite the lack of a common representational basis.

2. Agent interaction with the user

• Authentication: an agent needs to be able to authenticate that the user is who they claim to be. The user needs to be able to authenticate that they are indeed talking to "their" agent.
• Multiple interface modalities: users should be able to interact with agents via a number of interaction modalities, such as speech, visual, gesture etc. In general, different agents will use different modalities. In addition, some agents will themselves use multiple modalities, and will need to integrate them coherently.
• Interaction bandwidth: agents may need to send or receive high-volume signals, such as speech, video, music, virtual reality scenes, etc.
• Interaction semantic level: users may need to communicate mental states or other mental notions, such as their goals, constraints, beliefs or intentions. Agents need to be able to reflect these back to the user in the context for further interaction.
• Adaptability: some agents will need to be able to adapt their interaction to the preferences and interests of their users.
• Trust: users need to be able to trust that personal information that they disclose to an agent (e.g. credit card number) will not be misused by the agent, or some other agent that can access the internal state of the trusted agent.

3. Agent interaction with existing information sources

• Access to existing systems: Agents need to be able to access existing (legacy) information sources or corporate resources. This may include both reading and updating information.
• Integration with existing infrastructure: agents need to be able to integrate with, and where appropriate use for themselves, existing and emerging computational infrastructure. Examples include: TCP/IP networking, CORBA, TINA-C, http and OLE.

4. General requirements

• Scalability: Agent systems must scale well: that is, performance should not degrade unacceptably or suddenly as the size of various demand-related variables grows. The particular performance variables are system dependent, but might include: the number of agents in the society, the number of messages being exchanged, the number of agents at a particular location, the information sources that the agents. The agent society or system as a whole should be able to adjust itself to cope with increased demand or workload.
• Platform dependence: there will need to be agent solutions for a wide range of computational devices, including (but not limited to) lightweight, low power portable devices, personal workstations, set-top boxes and smart phones.
• Time dependence: some agents will need to be able to process large volume, time critical information, such as multimedia streams. Others will need to respond rapidly to real-world events. Other agents will simply need to ensure that a particular behaviour is completed in a timely way, or take some action if it is not.
• Situation awareness: agents will need to be able to adapt their behaviour to their situation. A corollary is that situations themselves must be able to be captured (sensed) from the environment, codified in some way, and computed with.
• Quality of service guarantees: developers of agent systems will want to be able to make statements about the guaranteed (i.e. minimum) and predicted quality of service of the agent system, for example the throughput of high-bandwidth signals in multimedia applications.

5. Agent design, construction, testing and delivery

• Development tools: we need to be able to design, develop, test and maintain a set of agents comprising an agent based system. Particular issues include support for a range of agent architectures and types (e.g. reactive, deliberative and hybrid), ensuring global system properties where behaviour is an emergent property of the interactions of the agents in the system, and testing and debugging the dynamic run-time behaviour of an agent.
• Agent embodiment: some agents will be embodied as physical, robotic agents, which will need particular support in their abilities to interact with the hardware components of the robot and the environment they inhabit.
• Agent capability characterisation: we will need some means of documenting agents and accurately characterising their behaviour to consumers or end-users.

Document notes

This version is dated 28 September, 1996.

Prepared by:

Ian Dickinson
Hewlett-Packard Laboratories
Bristol, U.K.

Please forward all comments and questions to the requirements working group: fipa-requirements@hplb.hpl.hp.com