normalized interactions between autonomous agents

Computer Supported Cooperative Work: The Journal of Collaborative Computing 5: 201-222, 1996. 201 @ 1996 Kluwer Academic Publishers. Printed in the Netherlands.

Normalized Interactions between Autonomous Agents A Case Study in Inter-Organizational Project Management

JEREMY PITT,* MATTHEW ANDERTON** and JIM CUNNINGHAM Department of Computing, Imperial College of Science, Technology, and Medicine, 180, Queen's Gate, London, SW7 2BZ, U.Ko E-mail: {jvp, mta, rjc}@doc.ic.ac.uk; URL: http://medlar.doc.ic.ac.uk/

Abstract. The CEC Project GOAL (Esprit 6283) aims to develop generic software tools to support a new project management paradigm, in which projects are collaborative, decentralised and inter-organizational. To support inter-organizational interaction, communication and cooperation, we are developing a design framework for formalizing the flow of information between organizations, specifying access to and provision of project services, and defining project-wide standards and procedures. This framework is based on normalizing interactions .between autonomous software agents by specifying messages and protocols for inter-agent communication and cooperation. This paper reviews the framework, and then focusses on the specification and implementation of a case study, the automation of a distributed document review procedure. This is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies can support inter-organizational project management. It also points the way to 'agent brokering', an enhancement of object brokering in distributed open systems, where the satisfaction of service requests can be subject to negotiation.

Key words: Intelligent agents, cooperative systems, project management

1. Introduction

The CEC GOAL Project (Esprit 6283) aims to develop generic software tools to support a new project management paradigm: "the extended enterprise". Some distinguishing characteristics of projects in the new paradigm are that they are collaborative, decentralised and inter-organizational. This means that general issues in project management (such as risk and uncertainty) take on an extra dimension, and there are many new problems to be addressed, such as information access, dissemi- nation, and security, the coordination of independent partners, and communication between partners at remote sites.

We are particularly concerned with the inter-organizational aspects of communication and interaction which enable participating organizations to complete

* Supported by CEC Esprit Project GOAL (Esprit 6283) and CEC Esprit BRA Medlar ~ (Esprit 6471).

** Supported by CEC Esprit Project GOAL (Esprit 6283).

202 J. PITT ET AL.

shared tasks and to achieve shared goals - i.e. computer-supported cooperative work (CSCW) for inter-organizational projects. The GOAL Cooperation Services Framework (henceforth CSF) is proposed to enable the specification of project- wide standards for normalized interactions between autonomous software agents acting in a federated information system, so providing mechanisms to:

i normalize inter-organizational terminology and the flow of messages and information between organizations;

ii structure inter-organizational interactions with respect to contractual relationships and local working practices;

iii enable each organization to provide/use project services required/offered by other organizations.

The CSF could therefore be used to enhance the object brokering capabilities of open distributed systems, by providing a framework for agent (rather than object) interaction, i.e. agent brokering, where requests can be negotiated, delegated, distributed etc.

Sections 2 and 3 of this paper review the background and the technical elements of the CSF, while Sections 4 and 5 focus respectively on the specification and implementation of a case study, in which the framework is used to automate a distributed document review procedure. This, we believe, is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies - like distributed AI, automated reasoning and multi-agent programming - can be used to support management procedures in inter-organizational projects.

2. B a c k g r o u n d

2.1. THE GOAL PROJECT

Each organization in an extended enterprise supported by the GOAL method oper- ates a GOAL system which facilitates its participation in the project. This system incorporates a data repository, common interface and CSCW services. The data repository, called the Information Model, contains a description of the people in the organization participating in the project and the jobs they do, the project tasks, activities and their timescale, and the relationships which bind these things together in the real project. The common interface enables users to access other software tools (e.g. word processors, spreadsheets, etc.) and to transfer information between such tools and the data repository. The service provider offers computer-supported cooperative work via the GOAL Workflow tool, and communication with other GOAL systems via X400 email.

The Advanced Research stream of the GOAL project is investigating (inter alia) the application of Artificial Intelligence technologies to extend the service provider via the Cooperation Services Framework. The aim of the CSF is to support advanced CSCW services, i.e. agreed working practices for performing shared project tasks and accessing distributed project information, whilst respecting the local working

NORMALIZED INTERACTIONS BETWEEN AUTONOMOUS AGENTS 203

practices and various security policies of individual organizations. Autonomous software agents operating in this framework enable project management procedures for inter-organizational projects to be normalized and executed.

2.2. COOPERATION PROTOCOLS

The mechanisms by which project management procedures are executed in the CSF is by autonomous agents following cooperation protocols (cf. Burmeister et al. (1993)). The following 'glossary' defines our terms of reference in the Cooperation Services Framework:

Agent: An agent is a GOAL system application which enables two or more users and/or other GOAL applications to participate in inter-organizational (and intra-organizational) tasks and activities. Users and applications communicate their intentions and requirements to other users and applications via agents which act as their intermediaries. Agents can understand both etiquette and savoirfaire, where etiquette is the specification of the communicative behaviour expected between two agents, and savoir faire includes taking actions, decision-making and interacting with a user (should it be necessary);

Message: Agents communicate by message passing. A message is therefore the basic unit of interaction between two agents. Message passing is performed as an action (i.e. a "speech act"), which determines the type of message, its contents, and between whom the message is passing. We refer to a speech act as a message action to distinguish between message passing and other actions that an agent can perform;

Protocol: A protocol is the formal definition of a structured exchange of messages which constitute a declarative agreement for communicative behaviour. For each type of message, its protocol specification determines the space of possible responses, i.e. the etiquette. More complex protocols can be defined using the given protocol specifications. At one level of specification, a protocol is application and domain independent. It needs to be reified for a particular application or domain by including a specification of an agent's savoir faire. The protocol then constitutes a mutually understood procedure for performing a particular inter-organizational task or activity.

Conversation: A conversation is a protocol in execution, and is composed of a sequence of messages which comply with the protocol definition. The current state and history of a conversation is maintained independently by all participating agents.

Cooperation Services: The Cooperation Services exported by a GOAL agent are the set of protocols that it 'understands'.

For the current application, inter-organizational project management, the value of our agents is the services they provide for users, for example, in making local working practices transparent, in helping to cope with information overload, and

2 0 4 J. PITT ET AL.

in smoothing the execution of distributed management procedures. We describe these agents as autonomous, although we anticipate that while they execute independently, their decision-making is configured by users and user interaction may be required. 'Fully' autonomous agents is a subject for further research.

3. T h e c o o p e r a t i o n s e r v i c e s f r a m e w o r k

We propose a two-tiered approach to the design and specification of cooperation services: a 'higher' level for specifying agent interactions via protocols and message passing, and a 'lower' level for specifying internal processes which determine how an agent behaves in a protocol. The specification of a protocol at the higher level is agent, application and domain independent, and protocols are then configured at the lower level for particular applications and domains, by specifying the agents' decision-making processes and message parameters. These two levels of specification are reviewed in the next two sub-sections.

Our motivation for this approach is the view that (agent) programming can be regarded as successive transformations from global specifications to more refined and detailed specifications, which are then transformed into programs for the individual agents in an appropriate programming language, as demonstrated in the case study. The programming language we have used for the prototype implementation is IC-Prolog II (Chu and Clark, 1993), and our reasons for this choice are outlined in Section 3.3.

3.1. HIGH LEVEL SPECIFICATION: DEONTIC LOGIC

At this level of specification, we are exploring the possibilities offered by Deontic Logic (Meyer and Wieringa, 1993). Deontic Logic is the branch of modal logic which has been developed to reason about behaviour by means of such modal operators as obliged, permitted, and forbidden. Deontic Logic has been applied in computer science for specification of fault-tolerant and safety-critical systems, organizational behaviour, and secure databases.

A Deontic Action Logic (Maibaum, 1993) has a standard logical syntax and can be given a semantics by a reduction to dynamic logic. It has two sorts of modal operators:

- deontic modalities O (obliged to) and 79 (permitted to), and - parameterized agent-action modalities, where if A is an agent and a is an

action, then [A, a] is a modality. The agent action modalities can be used for system specification by stating axioms of the general form:

PreCondition --+ [A, a]PostCondition

whose intuitive meaning is that if the PreCondition holds in the current state, then after agent A performs action a the PostCondition should hold in the resultant state.


Deontic operators are used in the pre- and post-conditions to specify the conditions under which an action is permitted to occur and any resultant obligations on other agents; e.g. the axiom:

T~(a, boss(b))--+ [a, demand(b, tea)] O(b, make(tea))

states that if a is permitted to boss b about, then after a demands tea from b, b ought to make some.

In the CSF, Deontic Action logic is used for specifying messages and protocols (examples are given in Section 4.2). Message passing between agents in our framework is, like in many others, based on speech act theory, and, since a speech act is formalised as an action modality in the logic, much akin to the language/action perspective of Winograd (1988). Using a set of given protocol specifications as the basic building blocks, we then define further protocols in the logic. This is done by defining action schemas, which give an initiating action and extra constraints that the participants in the protocol should observe. The course of a conversation following the protocol is determined by the range of message actions defined as a response to the initiating and subsequent messages.

The formal semantics underlying the logical specifications can be used for: - automatically generating a standard 'network-style' specification from the

protocol specifications and definitions, which can be extended and emended by interactive editors (cf. Kaplan et al. (1991));

- animating protocols for validation purposes, e.g. evaluation of the dynamic behaviour specified by the protocols (cf. Costa et al. (1990));

- expressing and reasoning with aspects of time and causality, authority and security, and non-normative behaviour (i.e. what happens when something goes wrong, and what to do about it).

These issues are being actively researched, but are not in the scope of the present work. The deontic specification of agent communicative behaviour can also be seen as the first pass at an agent theory (cf. Wooldfidge and Jennings (to appear)), which needs to be refined and developed in further research.

3.2. LOW LEVEL SPECIFICATION: DE GREEF SPECIFICATION

To reify protocols for particular applications and domains, we are experimenting with the language proposed by de Greef et al. (1993) for writing what herein we refer to as "de Greef specifications". Although we call this a "low" level specification, this is only "lower" relative to deontic logic specifications: de Greef specifications are still "high" level.

The language proposed by de Greef et al. can be used to specify protocols which include conversations between two or more agents, to blur the distinction between 'client' and 'server' agents, and to be more specific about what data is being passed between agents, and when. The language inherits (most) features

2 0 6 J. PITT ET AL.

of a logic programming language, and also provides for the notion of an agent, communication mechanisms, and sets.

The exchange of a message is written:

sender_agent: message(argl . . . . . argn) --+ receiver_agent

Similarly, messages are sent to a set of agents thus:

sender~gent: message(argl . . . . . argn) -+ Receivers

and received from a set of agents by writing:

Msgs = {(r,, argl . . . . . argn) ] r: message(argl . . . . . argn) -+ sender within

timeout}

The value of timeout is measured on sender~gent's clock, and ensures the instruc- tion will terminate because there is no guarantee that all receiving agents will respond.

Message passing can be included in "plan schemas" which assign sub-tasks to agents or agent variables. For example, a plan schema to calculate a percentage might be:

agent: percentage_of( part, whole, percentage ) =

agent_database( divide, Agentl ),

agent: request( divide, part, whole ) -+ Agentl,

Agentl : inform( divide, fraction ) --+ agent,

agent_database( multiply, Agent2 ),

agent: request( multiply, fraction, 100 ) --+ Agent2,

Agent2: inform( multiply, percentage ) -+ agent.

Assuming agent has no mathematical skills, it looks in an agent database for an agent offering the appropriate service, and sends a request to that agent asking it to perform the operation on the accompanying data. Having done so, that agent returns the result. This is done for both the divide and multiply to calculate the percentage of the original input.

The main drawback of this specification language is that it does not have a semantics, although de Greef et al. believe "a formal semantics can be defined". We have persisted with this language because we have found it useful in writing 'formal', precise specifications whose intended meaning, at least, is intuitively clear.

3.3. AGENT PROGRAMMING IN IC-PROLOG II

IC-Prolog II (Chu and Clark, 1993) is an implementation of Prolog that was designed to address distributed applications, such as automated support for inter-


organizational project management. IC-Prolog II is well-suited to multi-agent programming (Chu, 1992) and was chosen as a demonstrator platform for the CSF because of the following features:

- multiple threads: each thread is a distinct Prolog process and each currently runnable thread is allocated a timeslice during which it executes. Independent programs and goals can be explicitly forked and run concurrently in pseudo- parallel;

- high-level communication primitives: IC-Prolog II provides a number of mailbox primitives which allow threads to communicate by sending and receiving messages sent to/removed from mailboxes, enabling a form of connection- oriented communication to be implemented;

- an object oriented extension: IC-Prolog II supports objects, plus the usual notions such as inheritance, self/super and message passing, which is a con- venient way to structure agents (Chu, 1992).

The execution of an IC-Prolog II program will typically give rise to a set of explicitly forked sequential processes, which run concurrently. If a mailbox server is running, then a set of programs can communicate (asynchronously) by registering with the server. This allows programs (and their forked processes) which are executing concurrently and on separate workstations to cooperate over a network. This describes the behaviour of our agents and the environment in which they are expected to operate.

4. D i s t r i b u t e d d o c u m e n t rev iew: spec i f i ca t ion

4.1. INFORMAL SPECIFICATION

The situation we will consider is quality control in a stereotypical Esprit Basic Research Action, where the deliverables are largely technical papers. Suppose the project office aims to ensure quality by having each deliverable reviewed by (say) three referees, some of whom may be internal and some may have been nominated by the Commission. Partners in the project submit their deliverables to the project office, complete with document identifiers (authors(s), title, etc.), an abstract and a set of keywords. The project office then broadcasts to the network of referees that it has a review job to do with a proposed resource allocation of (say) five days, and invites bids to undertake the work.

If enough reviewers respond favourably, then three of them are chosen and are appointed. If insufficient reviewers accept the initial terms, then the project office selects what it considers to be a set of appropriate referees (based on the referee's areas of expertise and the deliverable's keywords), and engages in one-on-one negotiation with each in an attempt to get a commitment to review the deliverable. This continues until either enough reviewers have been found or the set of potential reviewers has been exhausted. In the latter case an alert is raised.

Our intention is for a GOAL system to handle the selection, communication and (if the referees chose) the commitments automatically. To do this, the project

208 j. PITT ET AL.

[s, inform(r, I)] lCr(I)

[s, query(r, Q)] (lEt(Q) -+ O(r, inform(s, yes))) A

(1Cr(~Q) --+ (9(r, inform(s, no)))

~P(s, command(r, A, A)) --+

Is, command(r, A, A)] O(r, A) A [r, A]O(r, inform(s, done(A, A)))

Figure 1. Agent-action modalities for basic protocol specifications.

office, hereafter referred to as the Chair, and each referee, hereafter referred to as Reviewers, run a software agent which enables them to participate in this distributed document review procedure. The core of the agent can be supplied by the project office, but in addition each referee can extend his/her agent by also specifying the conditions under which he/she will agree to review a deliverable. This is illustrated in more detail in Section 5. First, though, we specify the interactions and the protocols.

4.2. DEONTIC SPECIFICATIONS

Basic protocol specifications

The three most basic protocol specifications (implicitly universally quantified) are inform, query, and command, as illustrated in Figure 1. These correspond to the three major types of sentence in English, respectively declaratives, interrogatives and imperatives (Quirk et al., 1985). Note the modality specifying the speech act is parameterized with an agent (i.e. the "utterer" of the "speech act") and an action (the "speech act" itself). The action also has parameters: these include the recipient of the message, an action for the recipient to perform, and some additional resources or 'terms and conditions' A, which need not be specified further at this level of specification. In some cases, receipt of a message will require (oblige, as indicated by the modality O) a response from the receiving agent, which is itself another message action, i.e. to send another message.

Some further points to note about these three protocol specifications are:

- the result of an inform message is that the recipient r now "knows" the information content (I) of the message. This is represented by the parameterized modality/Cr (I);

- a query has been represented here as a so-called yes-no question, i.e. one demanding either a 'yes' or 'no' answer, with intuitively the sender asking is Q true and the receiver answering yes if it "knows" Q, and no otherwise. Queries can, of course, be far more complex than this, and the answers much more so (cf. Pitt et al. (1994));


Is, propose(r,A, A)] O(r, inform(s, reject)) ® O(r, accept(s,A, A)) ®

(9(r, offer(s, X , At))

Is, offer(r, A, A)] (9(r, inform(s, reject)) ® (9(r, propose(s, A', A'))

Is, request(r, A, A)] (9(r, inform(s, reject)) ® (9(r, accept(s, A, A))

Is, accept(r, A, A)] 7"(r, command(s, A, A)) ® (9(r, cancel(s, A, A))

[s, inform(r, done(A, A))] -~7"(r, command(s, A, A))

Is, cancel(r, A, A)] -~7"(s, command(r, A, A))

Figure 2. Protocol specifications for contracting work.

- the reading of the command message is that if s is permitted (indicated by the modality 7') to send a command to r, then after s commands r to do A with terms and conditions A, r is obliged to do A (indicated by the modality (9), and after r has done A it ought to inform s of the fact.

Figure 2 defines further protocol specifications required for the case study. The messages involved in these protocols particularly relate to performing tasks or getting other agents to perform tasks. Note that the response to a message is, in some cases, a series of exclusive obligations to reply with another message. This is specified by the logical operator ® for 'exclusive or'. Note also that by the D axiom of normal deontic logic, (9(A) -+ 7"(A), if an agent is obliged to perform an action, then it also has permission to perform it.

Notice that a requestto do A is non-negotiable: a negotiable request is apropose, which allows the agent responding to the message to make a counter-offer using the offer message. Once a contractual relationship has been established (when the respondent accepts what the initiating agent has proposed), the initiating agent is then permitted to command the responding agent to perform the action. This permission is revoked either by the responder informing the initiator that it has finished the job (note that this is a refinement of the inform specification above), or explicitly by the initiator itself sending a cancellation. Thus the response to an accept message is a permission to command or an obligation to cancel.

Restricting the use of the command message with the 7" modality is adequate for the case study, but is not sufficient for a general characterization of inter-agent authority. We hope to address this issue by exploiting the notion of institutionalised power (Jones and Sergot, 1994).

Protocol definitions

We are now in a position to define the protocols required for the distributed document review. These are the initial invitation to tender, which is a one-to-many

210 J. PITT ET AL.

interaction (i.e. a version of the well-known contract-net protocol), and an iterated one-to-one negotiation for undertaking a fixed task. These are described by the following two logical action schema announce and negotiate:

announce:

( s, announce(R, A, A) ) ~=

negotiate:

A O(s, request(r,A,A)) r E R

(s, negotiate(r,A,A)) £ O(s,propose(r,A,A)) A [s,propose(r, A, A)](7~(r, offer(s, A', A')) --+ (A = A' A A ¢ A')) A

[s, offer(r,A,A)](7'(r, propose(s,A',A')) --+ (A = A' A A ¢ A'))

Intuitively, the first line of the definition of the negotiate protocol reads as "in order to enter negotiation, you are first obliged to propose".

The designer of a protocol for a particular application can specify the necessary additional behaviour as required. In this case study, the objective of the negotiate protocol is to agree on performing a fixed task with negotiable terms and conditions. Hence after either a propose or offer message, the permission to respond (by, respectively, an offer or propose), is constrained by the consequences that the task A must be unchanged, and the terms and conditions A must be varied. Note that these constraints avoid trivial looping, but do not guarantee convergence on A. This logic is not adequate for expressing this requirement conveniently (more expressive logics are the subject of research in the Medlar II project). It has been enforced in the implementation as the agents negotiate over time for a review, and one agent offers successively greater times and the other successively less.

Note that further constraints on responses to messages could also be specified by extra axioms in the action schema. For example, if a basic protocol specification was [s, A(r)] O(r, X(s)) ® O(r, Y(s)), and if an the action schema included the axiom [s, A(r)]-~T'(r, X(s)), then from the logic it can be inferred that the only action available to r is Y.

The space of possible messages and responses according to these protocols can be determined from the logical specification. For the announce and negotiate protocols, these are illustrated in the finite state diagrams of Figure 3. In these diagrams, the 'legend' is: grey/white circles are states of the conversation, showing which agent is to send the next message; solid black circles are (unsuccessful) end states, empty white circles are (successful) end states, end states being those where no further actions are obliged; arrows from a state are the (exclusive) or-obliged actions, a dotted arrow indicates an action that is only permitted; and solid arrows joined by a labelled arc are N-way and-obliged actions.

NORMALIZED INTERACTIONS BETWEEN AUTONOMOUS AGENTS

inform(done)

c o m m a n d , " ~

211

,N /

~ r e j ~ inform(done)

mman ' '@ O

reject " - ~ e c t

propose inform(done)

command.'

Figure 3. Finite state diagram for announce and negotiate protocols.

4.3. DE GREEF SPECIFICATION

The deontic specification of the protocols specifies the agent behaviour through the message passing and responses i.e. the etiquette. There is content to the messages but it is under-specified at this level of abstraction. Thus the protocol specifications provide for application- and domain-independent aspects of multi-agent communication. In order to specify an agent's requisite saviorfaire for a particular application or domain, we need to reify the protocol specifications by specifying how agents make their choices of the next actions to perform (i.e. which message to send), and what is the precise content of the message.

In our case study, the project office agent uses the following 'algorithm': when a new deliverable is submitted, announce to all reviewers to see which will accept the task; if the number of acceptors is greater than 2, then select 3, command them to review the deliverable and reject the others; if it is less than 3, select some appropriate reviewers and negotiate with each; if as a result of successful

2 1 2 J. PITr E~r AL

Distributed Review chair, Reviewers : distributed_review( paper, time, timeout, Appointees ) (1) chair, Reviewers : announce( rewew( paper ), time, tzmeout, Acceptors ) (2) ( I Acceptorsl > 3, (3) select_3( Acceptors, Appointees, Rejectees ), (4) chair : command( review(paper ), time ) -+ Appointees, (5) chair : cancel( review( paper ), time ) -+ Rejectees (6) I I acceptors [ < 2, (7) select_appropriate( Reviewers, Acceptors, PossRevs ), (8) MoreAccept : { (r, atime) I r G PossRevs,

chair, r : negotiate(paper, time, atime), atime ¢ l }, (9) ] moreaccept l + I acceptors ] >_ 3, (10) select_enough( MoreAccept, I Acceptors I, Accepted, Rejectees ), (11) Appointees = Acceptors t3 Accepted, (12) chair : command( review(paper ), time ) ~ Appointees, (13) chair : cancel( review(paper ), time ) --+ Rejectees (14) I Moreacceptl + I acceptors [ < 2, (15) alert

Announce chair, Reviewers ." announce( review(paper ), time, timeout, Acceptors ) = (1) chair : request( review( paper ), time ) --+ Reviewers, (2) Acceptors = {(r, time) I r : accept( review(paper ), time ) --+ chair

within timeout, r E Reviewers }.

Negotiate chair, reviewer : negotiate( paper, time, agreetime ) = (1) chair : propose( review(paper ), time ) --+ reviewer, (2) chair, reviewer : do~egotiate( review, paper, time, agreetime ). chair, reviewer : do_negotiate( review, paper, time, agreetime ) = (1) ( reviewer : accept( review( paper ), time ) --+ chair, agreetime : time, (2) reviewer ." inform( reject ) -+ chair, agreetime : l , (3) reviewer : offer( review( paper ), rtime ) -+ chair, (4) chair : accept( review( paper ), rtime ), agreetime : rtime, (5) chair : inform( reject ) --+ reviewer, agreetime : ±, (6) chair : propose( review(paper ), ctime ) --+ reviewer, (7) chair, reviewer : do_negotiate( review, paper, ctime, agreetime )

).

Figure 4. Agent specification for distributed review procedure.

negotiations 3 reviewers can be appointed, select enough to go with the original positive responders and proceed as before, otherwise alert the (human) project manager.

Using the specification language of de Greef et al., introduced in Section 3.2, this 'algorithm' is specified in Figure 4. Note how the two cooperation protocols are used inside the overall specification of the distributed document review procedure. Note also that this specification only states what the agents should do, not how it should be done. This is coded by the programs for the individual agents, as described in the next section.


5. Distributed document review: implementation

In our case study we implemented a distributed review procedure as a multi-agent system based on the messages and protocols specified in Section 4. The system com- prised a single client agent, the Chair, and multiple server agents, the Reviewers. The agents were built from program modules which corresponded to elements in the CSF (announcement, negotiation, conversation, protocol specification) and the application domain (review task, agent knowledge and organization knowledge). We first present the requirements for our study and then discuss the implementation.

The role of the CSF is to facilitate negotiation between client and server agents over the terms under which a service will be provided to a client. As such it can be seen as an extension to existing frameworks for inter-object communication to provide the additional support required for inter-agent negotiation.

5.1. AGENT REQUIREMENTS

To demonstrate the Framework we require clients (service consumers), servers (service producers), a message passing infrastructure, a method of structuring negotiation and managing conversations, and a shared understanding between clients and servers of specific tasks within an application domain. We can identify further requirements for each element and so elucidate the implementation.

Client Agents require the ability to: (1) locate appropriate servers to perform a given task. For our case study the

Chair organization is given the names of potential reviewers. Typical open systems make use of a common service repository maintained by an object broker: servers register their interfaces with the broker and clients forward requests to the broker to be matched against known service providers.

(2) send messages and wait for corresponding replies. The negotiation process is driven by the client. When a client expects a response it creates a mailbox (using the facilities of IC Prolog II) and the unique mailbox Id is forwarded to the server with the initial message.

(3) check the validity of incoming messages with respect to the protocol specification. The client needs to know both the protocol specification and the history of messages in the conversation. Valid messages must be recorded in the conversation history.

(4) generate service proposals based on external triggers. Agents monitor and respond to changes in their environment. For our study it is enough that client agents react to external triggers by generating service requests, and that servers respond to incoming messages. The agent architecture may be extended to allow for persisten t goals, planning and scheduling (cf. Steiner et al. (1993)).

(5) formulate an initial service request or proposal. Domain knowledge is needed to identify the service name and parameters needed to instantiate the call; the

214 J. PITT ET AL.

circumstances of the individual agent and its organization will influence the initial terms.

(6) evaluate incoming service proposals by applying domain knowledge in the context of organizational knowledge, the current state of the client and the history of the negotiation to date. In addition the client must formulate appropriate responses. The decision-making intelligence of the agent is embodied in these evaluation rules. The rules are not themselves a part of the cooperation service framework which does not attempt to standardize decision making, only to structure the negotiation process within which decisions must be made.

Server Agents require a smaller set of similar basic capabilities; namely to: (1) communicate responses to clients (cf. client (2) above); (2) validate and record messages (cf. client (3) above); (3) evaluate service proposals (cf. client (6) above); (4) perform services in response to authorised commands. If a server provides tasks by service decomposition and delegation to other

agents (cf. (Chu, 1992)) then it combines the functionality of both client and server in a single agent. This case is a simple extension of the agents used in our study.

Structuring Negotiation. An agreed protocol specification such as that proposed in Section 4.1 is required. Certain message types are generated by clients, some by servers and some by both types of agents: clients propose, request and command, servers offer and accept, all can inform. For simplicity, our implementation combines the implementation of the whole specification into a generic module which is shared by all agents in the application.

Managing Conversations. Each agent manages an independent record of its conversations, hence each requires certain conversation management facilities: new conversations need to be created and closed as necessary; incoming and outgoing messages need to be allocated to conversations. Maintaining conversation histories enables an agent to validate incoming messages with respect to the protocol specification, make an informed analysis of service proposals, requests and offers, and provide organizations with a record of agent activities.

Service Description. A shared understanding of services requires a standard service representation which includes: the service name, a list of input parameters required to instantiate the call and an additional list of terms of execution which may be the subject of negotiation. For the case study we chose:

servicename( [ parameterl, ..., parameterN ], [ terml .... ,

termN ] )

Such service descriptions form the content of cooperation service messages (i.e. requests, offers, proposals, acceptances, rejections). For our example we have a single review task with two parameters and a single term over which negotiation is possible:

review( [ DocumentId, KeyWordList ], [ TimeAllotted ] )

NORMALIZED INTERACTIONS BETWEEN AUTONOMOUS AGENTS

Open systems typically use a standard interface definition language.

215

5.2 . AGENT IMPLEMENTATION

Agents are built from a number of reusable components. All agents share the following basic modules: Communicator, Protocol Specification, Conversation, Negotiation, Domain Knowledge.

A Chair (client) agent has, in addition to the basic modules, the following: Distributed Review, Announcement, Sequential Negotiation, Specific Chair Knowl- edge, and Specific Organization Knowledge.

A Reviewer (server) agent has, in addition to the basic modules, the following: Specific Reviewer Knowledge, and Specific Organization Knowledge.

Figure 5 shows the architecture of the Chair and Reviewer agents in the distributed review example.

Distributed Review implements the top level procedure by which the Chair secures the peer review of a document as described in Section 4.3. The submission of a new paper triggers the forking of a new process by which the requisite number of reviewers are commissioned to perform the review task. The Chair announces an initial service request: if insufficient reviewers accept the task request, the Chair proceeds to negotiate with individual Reviewers.

Announcement multicasts an initial review request from a client to a list of servers and collates and sorts the responses received within the time-out limit of the announcement. In our example the Chair retrieves the list of potential servers (reviewers) and the initial terms of the review task from its knowledge base. This implementation of the announcement protocol opens a new conversation with each member of the list. There are many possible variations, for example announcement may be used to issue a final service request to multiple servers at the end of a parallel negotiation process, in which case new conversations would not need to be created.

Sequential Negotiation manages a sequence of negotiations between the client and possible servers; ending when either sufficient servers have been found, or there are no further potential servers with which to negotiate. Again there are many possible variations on the management of multiple negotiations and these correspond closely to standard search strategies, breadth first, iterative deepening, etc. Complex negotiation strategies may involve interaction between parallel streams of negotiation, though it is questionable to what extent it is useful to attempt software agents that mimic human ingenuity.

Negotiation supplies the negotiation protocol as specified in Sections 4.2 and 4.3, i.e. it directs a cycle of proposal and offer messages between a client and a server until a negotiation reaches its conclusion. There are two sides to the negotiation procedure, one for the client and one for the server. The client proposes, requests or rejects; the server offers, rejects or accepts. Each agent evaluates messages from the other and acts on its evaluation. This is the core mechanism which enables

216 J.vn~rzT ~

Client Agent: Chair One

I

I Reviewer One Conversation

History

-!1

Client or Server Specific Module

I Reviewer One 1 Knowledge

iOrganisation Beta i Knowledge 1 <

Review Domain t J Knowledge |

Server Agent: Reviewer One

Figure 5. Agent architecture for the distributed review case study.

Legend

IS Agent i pecific Module 1

IOrganisati°nl Specific Module


the negotiation process. Evaluation routines are defined in the knowledge modules of the agent. The conversation module is called to open new conversations and produce new messages.

Protocol Specification implements the protocol specifications of Section 4.2. The module contains message validation rules defined in accordance with the protocol specifications.

Conversation maintains the history of conversations in which the agent par- ticipates. The protocol specification module is called to validate incoming and outgoing messages, while the conversation module provides services for creating and closing conversations, producing new messages and retrieving conversation data.

Communicator provides the basic message passing functions of the demonstrator application. Building on the communication primitives of IC Prolog II, this module implements the 'send message and wait' facility for the client side and the 'send reply' facility for the server.

Agent Knowledge Modules. The division of the knowledge base reflects the source of this knowledge, be it with the individual agent (e.g. agent name), the task domain (e.g. request evaluation rules) or the organization within which the agent is functioning (e.g. priority in which client requests are processed). For a demonstrator these divisions are largely arbitrary.

Reviewer Knowledge. Many Reviewer agents were used in the study, each has a composite knowledge base drawn from: Individual Reviewer Knowledge, which records the name of the Reviewer agent and the expertise of the reviewer; Orga- nization Knowledge, which implements the decision making procedures according to which review requests are evaluated; and Domain Knowledge which provides the top level request and proposal evaluation procedures.

Chair Knowledge. The study makes use of a single Chair agent with knowledge combined from the review task domain (top level offer evaluation routines), the organization (the list of known servers, the low level evaluation rules), and the agent itself (name).

5.3. RESULTS: THE COOPERATION SERVICES FRAMEWORK IN USE

Figure 6 is a screen shot of the distributed review case study during execution. Each window displays the messages sent and received by an individual agent. The chair1 agent window provides a transcript of the messages exchanged between the agents during the distributed review procedure. The three stages of initial announcement, subsequent negotiation and final appointment are clearly shown.

In this example the document under review is identified as pl and covers the subject areas a, b and c. For the initial task request reviewers are allotted 5 days to complete the review. Only reviewer1 accepts these terms. Two more reviewers still need to be found and so the client begins negotiation with those who rejected the terms offered in the first round. A task proposal is issued with the revised

218 J. PITT ET AL.

Distributed Review oF Document: p1 - Subject Areas: [a,b,c]

Review Task: review(Epl,Ea,b,e]],[5])

sendin9 messa9e to reviewer1 : request(review([pl , [a,b,c] ] , [5]) ) sendin9 message to reviewer2 C request(review([pi , [a,b,c] ] , [5]) ) sendin9 messa9e to reviewer3 ~ request(review([pl , [a,b,c] ] , [5]) ) waitin9 For reply . , . received reply : mesaage(chairi780431497.reviewerl.accept(review([pl,[a,b,c]],[5]))) waitin9 ?or reply ~.. received reply : message(chairi780448594,reviewer2,reject(review([pi,[a,b,cl],[5]))) waitin9 ?or reply ,~. received reply : messa9e(chair1780427495,reviewer3,reject(review([pl,Ea,b,cl],[53)))

All responses in

Be9innin9 ne9otiation with: [reviewer2.reviewer3]

sendin9 messa9e to reviewer2 : propose(review([pl , [a,b,c] l , [6])) sendin9 messa9e to reviewer~ : propose(review([pl , [a,b,c]] , [6])) waitin9 ?or reply ~** received reply : messa9e(chair178044757Z,revieuer2,o??er(review([pi,[a,b,c]],[7]))) waitin9 ?or reply o.. received reply : messa9e(chairi780436~42,reviewer3,accept(review([pl,[a,b,c]],[6]))) sendin9 message to reviewer2 : propese(review([pl , [a,b,c]] , [Zl)) uait in9 ?or reply ~.. received reply : message(chair1780447577,reviewer2,accept(review([pl,[a,b,cl],[71)))

Appointin9 Reviewers

sendin9 messa9e to reviewer1 command(review([pi,[a,b,c]],[5])) sending messa9e to reviewer3 command(review(lp$,[a,b,c]],[6])) sendin9 message to reviewer2 command(review([p$,[a,b,c]],[7])) waitin9 ?or reply .~. received reply : messa9e(chairi780431497,reviewerl,done(review([pi.[a,b,c]],[5])))

MESSAGE RECEIVED ; messa9e(85539,chair1780447577,chairi,propose(review([pi,[a,b, e l i , J6 ] ) ) ) chair$780447577 rev iew( [p i , [a ,b ,c ] ] , [6 ] ) sendin9 response . . . : ogger(review(Epl,[a,b,cl ] , [7]))

MESSAGE RECEIVED : messa9e(85538,chair1780447577,chairl,propose(review([pl,[a,b, c ] ] , [ 7 ] ) ) ) chair$780447577 rev iew( [p i , [a ,b ,c ] ] , [T l ) sendin9 response . . . : accept(revieu([p$.[a,b,c] ] , [7]))

MESSRGE RECEIVED ; messa9e(G5537,chair1780447577,chairi,cemmand(review([pi,[a,b, c ] ] , [ 7 ] ) ) ) Reviewin9 9ocument: p1 sendin9 response ~.. : done<review([p$,[a,b,c]],[7]))

Figure 6. T h e d i s t r i b u t e d r e v i e w c a s e s t u d y i n e x e c u t i o n .

assignment of 6 days. Reviewer2 now accepts the task while reviewer3 offers to perform the task in 7 days. The chair approves reviewer3's offer and sends an echo proposal back to the server which follows with a formal acceptance. Sufficient reviewers have been found and the reviewers are automatically appointed. Chairl issues the commands and awaits notification that the tasks have been completed.

The demonstrator is launched via a simple Tcl interface. Further interface dia- logues may be constructed to configure the knowledge bases of the individual


agents, e.g. to modify the parameters of the proposal and offer evaluation rules and to set the initial terms for task announcements.

6. Conclusions and further work

6.1. SUMMARY

We have reviewed the Cooperation Services Framework (CSF), an approach to the design of cooperative systems to support advanced CSCW functions in inter- organizational project management. We then focussed on a case study, which implemented agents and protocols to automate a distributed document review procedure. The case study showed how the CSF could be used to normalize interaction, communication and cooperation between organizations. This was achieved by specifying a range of possible messages and space of possible responses, which were consolidated in the form of (generic) cooperation protocols and then 'instantiated' in the implementation for the particular application.

The case study has shown how standardized project services can be provided based on agreed protocol specifications and a standard representation of domain knowledge. The study also illustrates how inter-organizational contractual relationships can respect local working practices, in that each reviewer's agent can be configured so that, for example, the way a negotiated agreement is reached can be different, the way a review is conducted locally can be different, domain, agent and organizational knowledge can be different, etc.

The modular design of the system allows for new message types and com- plementary protocols to be added as necessary. In practice the existing protocol specifications are sufficiently generic to support many applications; the given protocols too are application-independent, but there are many potential variations in negotiation strategy, especially when multiple agents are involved. With the CSF in place it is possible to develop and test a library of alternative high level communication protocols.

The case study has also shown the value of a framework of agent support services which allows agent developers to concentrate on the functionality of their agents rather than the mechanics of agent interaction. We believe that the use of generic message types and cooperation protocols is sufficiently flexible to encompass a wide range of application domains, particularly in the context of multi-organization systems. In this environment the ability to negotiate over the terms of service provision offers increased flexibility over traditional client/server systems.

At this stage in the development of the CSF, we should separate the principles behind the framework, which we believe are validated by the case study, from the technologies used to specify and implement it, for which there are several caveats. Deontic Action Logic is not with out subtle logical problems, but we expect well- found multi-modal logics (and reasoning systems for them) to emerge from our work on the Medlar II (Esprit 6471) project (Cunningham et al., 1991). De Greef

220 J. PITT ET AL.

et al.'s specification language does not have a semantics, so while it is adequate for present purposes and we know of nothing like it, design tools for verification and program transformation are distinctly problematic. Finally, IC Prolog II is a nearly-finalized product of the IMAGINE (Esprit 5362) project, so we stress that the implementation is a demonstrator only. However, IC Prolog II was useful for prototyping and points the way for future agent implementations, for which we intend to use the A p r i l programming language (McCabe, 1994).

6.2. RELATION TO OTHER WORK

The CSF is highly eclectic, and so owes its inspiration to a number of different sources. The language/action perspective of (Winograd, 1988) suggested to us that our earlier work on deontic and action logics could be relevant to formalizing speech acts and protocols. Our cooperation protocols themselves are similar to those of Burmeister et al. (1993), although we aim for a graphical (network) representation which can be generated from the formal (logical) specification. The two-tiered approach to specification, i.e. successively refining a specification from a global 'abstraction' to a well-refined description, can be related to the process of tailoring conversations in the ConversationBuilder system of Kaplan et al. (1991), although our approach is more in keeping with a traditional model of software development. If we extend the CSF by adding protocol design and verification tools, agent interface and configuration tools, etc., then ConversationBuilder's open architecture and user-interface suite serve as useful development guides.

The SHADE project (Kuokka et al., 1993) is setting standards in a shared agent ontology, a common agent communication language, and facilitator agents to ease communication between application agents, and all to support collaborative engineering. These are all issues pertinent to the CSF, and recent developments in KIF, KQML, KAPI and facilitation applications* have all had an impact on, and illuminated our thinking on the underlying knowledge representation for agents, the language of cooperation protocols, CSF user interfaces, and 'agent brokering'.

6.3. FURTHER WORK

The challenges ahead range from commercially-oriented development to a long- term research programme. In the first case, we are developing, in conjunction with our GOAL project partner FHG/IML (Dortmund), an implementation of the Coop- eration Service Framework based on the DEC ObjectBroker 2.5 implementation of the OMG's CORBA 1.1 specification (OMG, 1992). This implementation defines three enhancements to CORBA's object brokering capabilities, namely standard interface operations for clients and servers through which inter-agent negotiation

* References to KIF (Knowledge Interchange Format), KQML (Knowledge Query and Manipu- lation Language) and KAPI (KQML Application Programming Interface) can be found in (Kuokka et al., 1993).


and service invocation is conducted; expected behaviour for clients and servers, i.e. protocols for inter-agent cooperation; and common services which enable agents to manage conversations and verify the compliance of other agents with the agreed cooperation protocols.

For the research programme, we need to demonstrate genericity and config- urability of the protocols by re-use in other management procedures (e.g. change management, meeting scheduling, etc.), to examine issues of inter-agent authority and autonomous decision-making, and to investigate autonomous agents which are secure, self-configurable, and pro-active (cf. the July 1994 issue (vol. 37, no. 7) of the Communications of the ACM on "Intelligent Agents"). As indicated above, important elements in realizing this programme are developing technologies like A p r i l as the agent prototyping language, and multi-modal logics, not only for the design of protocols but also of rational agents, i.e. agents whose autonomy (in terms of their ability to select protocols according to their current plans, beliefs and environment) is founded in the logics of practical reasoning, the subject of research in Medlar II.

We have some way to go in achieving these goals, but the present work, construed as a feasibility study, is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies, such as distributed AI and automated reasoning, can be used to design and implement generic agents which can be configured to support particular applications, in this case management procedures in inter-organizational projects. However, the CSF should be applicable to any open computing environment which spans organizational boundaries. We therefore intend to develop the CSF as an enhancement to the object brokering capabilities of CORBA-compliant open distributed systems, to provide a framework for agent brokering, i.e. agent interaction where the terms and quality of service delivery are open to negotiation.

Acknowledgements

This work has been partially undertaken in the context of, and partially supported by, the CEC R&D project GOAL (Esprit 6283). The GOAL consortium is Alcatel ISR (F, lead partner), GSE (G), CETE (F), IML (G), MELT (F), SEL (G), City University (UK) and ICSTM (UK). For general information, contact Stephen McConnell, ARTTIC, 72 rue de Chateau des Rentires, 75013, Paris, France.

We would also like to thank the anonymous reviewers for their helpful com- ments and suggestions, and are indebted to Patrick Brezillon of the COOP'95 Program Committee, Manuel Zacklad and Alain Giboin for all their assistance in the production of this paper.

References

B. Burmeister, A. Haddadi, and K. Sundermeyer (1993): Generic configurable cooperation protocols for multi-agent systems. In MAAMAW'93.

222 J. PITT ET AL.

D. Chu and K. Clark (1993): IC Prolog II: A Multi-Threaded Prolog System. m/s, Department of Computing, Imperial College.

D. Chu (1992): IC Prolog II: A Language for Implementing Multi-Agent Systems. In Proceedings SIG on Cooperating Knowledge Based Systems, Keele.

M. C. Costa, R. J. Cunningham, and J. Booth (1990): Logical Animation. InProc. ofl2th International Conference on Software Engineering, pp. 144-149, Nice, 1990. IEEE Computer Society Press.

J. Cunningham, D. Gabbay, and H.-J. Ohlbach (1991): Towards the MEDLAR framework. In Esprit '9h Proceedings of the Annual Esprit Conference, pp. 822-841. Kluwer/CEC DGXIII.

R de Greef, K. Clark, and E McCabe (1993): Toward a specification language for cooperation methods. In GWAI'92 16th German AI Conference, volume 671, pp. 313-320. Springer Verlag.

A. Jones and M. Sergot (1994): Institutionalized power (preliminary report). CEC Esprit Project Medlar (Esprit 6471) Periodic Progress Report 2, Department of Computing, Imperial College of Science, Technology and Medicine.

S. Kaplan, A. Carroll, and K. MacGregor (1991): Supporting Collaborative Processes with Conver- sationBuilder. ACM.

D. Kuokka, J. McGuire, J. Weber, J. Tenenbaum, T. Gruber, and G. Olsen (1993): SHADE: Knowledge-Based Technology for the Re-Engineering Problem - 1993 Annual Report. Available in HTML from http://hitchhiker.space.lockheed.com/aic/shade/papers/shade-overview.html.

T. Maibaum (1993): Temporal Reasoning over Deontic Specifications. In J. Ch. Meyer and J. Wieringa, editors, Deontic Logic in Computer Science, pp. 141-202. Wiley.

E McCabe (1994): A p r i l : Agent PRocess Interaction Language. Department of Computing, Imperial College of Science, Technology and Medicine.

J. Ch. Meyer and J. Wieringa (1993): Deontic logic: A concise overview. In J. Ch. Meyer and J. Wieringa, editors, Deontic Logic in Computer Science, pp. 3-16. Wiley.

OMG (1992): The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1 (Revision 1.1), Wiley & Sons.

J. Pitt, J. Cunningham, and J. H. Kim (1994): Cooperative answering to natural language email queries. In E Anger, R. Rodriguez, and M. Ali, editors, Proceedings 7th Intnl. Conf. on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, pp. 273-281. Gordon and Breach Science Publishers.

R. Quirk, S. Greenbaum, G. Leech, and J. Svartvik (1995): A Comprehensive Grammar of the English Language. Longmans.

D. Steiner, A. Burt, M. Kolb, and C. Lerin (1993): The conceptual framework of MAI2L. In MAAMAW'93.

T. Winograd (1988): A language action perspective on the design of cooperative work. In I. Grief, editor, Computer Supported Cooperative Work: A Book of Readings. Morgan Kaufman.

M. Wooldridge and N. Jennings (to appear): Intelligent agents: Theory and practice. Knowledge Engineering Review.

normalized interactions between autonomous agents

Documents