Multi-Agent Interaction Language

Submission to FIPA's CFP1

Overview of Proposal

This proposal addresses the First FIPA Call for Proposals in the technology areas as described by Sections 5.2 and 5.3 of the CfP. It proposes the Multi-Agent Interaction Language (MAIL), as originally developed in the IMAGINE Esprit Project (Nr. 5362), incorporating the latest developments by Siemens AG in the MAI²L/MECCA agent development framework.

Background and Terminology

Agents in this proposal are considered to be autonomous entities (software or hardware) capable of perceiving and altering their environment in a rational manner. Each agent must react flexibly to its environment yet has to be predictable in its future course of activities in order to contribute to the system. Agents interact in a cooperative way to extend their individual capabilities and thus form complex systems.

Agent interaction not only includes shared execution of tasks but also some preparative activities such as establishing common goals and elaborating shared plans (including their schedules). These concepts are used to model the problem solving process and must be shared among all participating agents. Furthermore, a common representation of the domain must exist. We do not, in this proposal, describe how the domain should be represented, indeed, this may vary from domain to domain, and is dependent upon the appropriate domain-specific standards. We also refrain from relying on and describing the agent's internal architecture, as this may vary among vendors.

Environment
Each agent manages a relevant abstraction of its environment in a world state. The world state is the context in which untyped information, goals, etc. are evaluated in order to prove their validity or feasibility, respectively. The world state receives updates from the environment by external events or by inform messages. The world state is organized as a knowledge database.

Action
An agent's basic capabilities are described as actions. Each action must define the situation (in the domain) in which the action is applicable as well as the effects it has on the environment. An agent may additionally have internally represented a specific procedure which it uses to accomplish the action, this, however, is private to the agent. The agent makes certain of its capabilities known to other agents via its Agent Directory Service.

Goal
A goal describes a desired state of the environment which is specified by a set of objects and conditions on them. It also has a timepoint associated with it specifying when the goal is to be achieved. It is up to the individual agent as to specifically how its goals may be activated, or how they are handled.

Task
A task describes a specific action which is scheduled for execution. It thus describes when and by which agent the task is to be executed, and to which agent the result of task execution is to be reported. Tasks need not be immediately specified to the last detail; indeed they are ultimately the subject of negotiation among agents.

Plan
A plan is a structure to represent the problem solving process in a particular state. As such, it consists of a partially ordered set of goals and tasks. Initially, the plan may only consist of the goal to be achieved, which is then broken down into subgoals with their respective timely order, which in turn are replaced by tasks to achieve the goals. A plan is executable as soon as the last goal node is replaced by a task node.

Agent Management

Agent Interface Description Language

An agent is described by its address, type and the public actions it can perform (capabilities). This information is registered with an appropriate Agent Directory Service, which makes the information available to other agents.

An agent's address consists of

• agent name
• list of supported communication protocols with additional information depending on the particular protocol

For example, an agent may be able to interact via e-mail and via direct TCP/IP connection. In the former case, the agent's e-mail address would be given, in the latter, the host and port number to which the agent is connected.

Possible communication transport protocols with which agents may interact include: intra-process, TCP/IP, HTTP, E-mail, voice telephone and fax (the latter two contigent either on automated voice recognition or OCR or on presence of human agents). Asynchronous interaction is essential. It is suggested that Microsoft IDL be used for the representation of agent addresses.

A capability of an agent is represented by an object consisting of the name, preconditions and effects of the action. The agent's public capabilities may be stored by the agent's ADS in an array associated with the agent's name. (How this is represented internally in the agent or in the ADS is immaterial.)

Agent Lifecycle Model

An agent is created by specifying its name, type, capabilities, available communication means and another agent called its Agent Directory Service (ADS). Upon initialisation of the appropriate processes, the agent initiates a register interaction protocol with its pre-specified ADS. This protocol consists of an order(assert(<agent-data>))message. order is used as a guarantee that the ADS indeed takes note of the agent. In principle any agent could act as an ADS, however, a hierarchy of ADS (ala Internet Domain Names) may be useful.

The agent then tries to accomplish its active goals. Goals may be activated either by the environment, by a human user or by another agent in a propose(goal...) message. The agent may query its ADS to locate other agents to help it achieve its goals. (The search may be restricted to other agents registered with the same ADS, or to agents registered with other ADS' in the same domain.) It selects from and negotiates with these agents via appropriate interaction protocols (e.g. contract net).

When an agent is finished, or needs to be terminated, it first (if possible) deregisters itself from its ADS via an order(retract(<agent-data>)) message. If it is not possible to deregister itself (e.g. its host machine was switched off unexpectedly), the ADS and other acquaintance agents must be able to deal with the situation via conventional error handling routines.

During the course of its lifecycle, some of the agent's public attributes may change (e.g. host name, E-mail address). It notifies its ADS (and possibly any acquaintance agents) accordingly via an order(modify(<agent-data>)) message. Furthermore, an agent may even change its ADS (for reasons of minimizing communication overhead, etc.). In this case, the agent must de-register itself from its old ADS, then register itself with the new one.

Agent/Agent Communication

Messages

Throughout this proposal we rely on a message passing mechanism allowing agents to send messages to individual agents as well as groups of agents. It must also provide for receiving messages from individual agents as well as from several agents with a timeout.
Apart from communication specific information, each message consists of a message type indicating the illocutionary role of the message and the message contents.
In order to embed agent interaction in an object-oriented framework, messages themselves are represented as instances of the class (or type) Message. The communication channel among agents must support the transmission of objects. The exact coding of objects for transport over a network is beyond the scope of this proposal; we represent objects as streams of characters representing the following minimal set of data types:

A message, thus, is an object containing the following keys:

type : propose | refine | modify | accept | reject | order | query | inform

name : msg_id (name)

content : < see below >

sender : < name of the sending agent >,

s_role : < role of the sending agent >,

recipient : < name of the receiving agent >,

r_role : < role of the receiving agent >,

coopid : < unique identifier (name) of the current interaction protocol, determined by the initiator >,

protocol : < type of the current interaction protocol, e.g. 'contract_net >,

[reply_by] : <optional key specifying the timepoint by which a reply is expected >,

[reply_with] : < list of  message types expected in the reply; if this slot is not specified, all valid response message types are allowed >

[reply_to] : < optional key specifying the receiver of the reply; it defaults to the sender >,

Message Types

The following is the list of message types supported in this proposal.

propose
A proposal initiates a discussion among agents about the content of the message (an object in the cooperative problem solving process). The message content transferred by a proposal to other agents is in some sense hypothetical as the agents sharing this information have not yet committed to it.

refine
An agent sends a refinement if it cannot commit to the original, preceding proposal, but its evaluation of the proposal has led to a further instantiation of the proposal.

modify
A modification is similar to a refinement, except that the message content differs in more than just an instantiation of the previous proposal. Refine and modify represent counter-proposals, but do not fully commit the agents.

accept
An agent indicates its acceptance of the message content to other agents. Both sides, the sender and recipients are then committed to the content. This message type terminates the discussion about the message content.

reject
A rejection is used by an agent if it cannot commit to the proposed content. This message type terminates the discussion about the message content.

order
An agent ordering a message content imposes the acceptance of the object on the recipients. (E.g. if the content is a task, the recipients must execute it. However, the recipients may still fail in executing the task, in which case they should inform the appropriate agent of task failure.) An order is only applicable if either the object has been previously discussed (and accepted) or an appropriate authority link between sender and receiver(s) is established (as, for example, between an agent and its ADS).

query
An agent can query information (either domain-dependent or about the problem-solving process) from another agent.

inform
The inform message is used to communicate results of an execution or an answer to a query for information. It is up to the recipient to decide upon whether to add the information to its knowledge base. (That is, there is no guarantee that the recipient incorporates this knowledge. A guarantee can be accomplished by using order(assert(<knowledge>)), as used by an agent when registering with its ADS).

The valid combination of message types is discussed in the section Interaction Protocols.

Message Content

Generally, the message content is encoded as an object. The content of a message is either an entity in the domain (knowledge) or a problem-solving object. Domain objects can be encoded as described previously. The domain-independent problem-solving objects along with their attributes are defined in this section. This forms the basis for a domain-independent shared ontology.

content ::= Goal | Plan | Task | Domain-dependent Type

The message content contains a type key, a name key and further slots depending on its type.

The goal description is a predicate which the sender and the receiver can evaluate in their world states. A goal is acceptable if the evaluation of its description does not contradict other goals, plans etc.

A plan represents a script an agent has to follow, when the plan is executed. Plan scripts can be represented by the following syntactic elements reflecting the timely structure of the plan:

Appropriate synchronisation points (via messages if the tasks are to be carried out by two different agents) link task_sets.

Tasks may take input parameters and return results, thus execution of a task may be referred to as: O₁,O₂,... = Task(I₁,I₂,...)

Note, that because we allow plans to be message contents, the number of message types can be held to a minimum. For example, a request by a client to a server for regular reports of certain information can be represented by the following:

plan(

'name = 'inform_until,

'script = {while (CurrentTime < EndTime) do

    (inform(Client,Information))}

)

and

Client:order(Server,'inform_until)

The action R:Msg = S:Type(R,Content) is shorthand for agent S sending a message with message type Type and content Content to agent R.

Interaction Protocols