Page 1 of 36

AdaptAgent: Integrating Adaptive Workflows and Multi-Agent Conversations for

B2B E-Commerce1

By

N.C. Narendra

E-Solutions & Technology Center (ESC)

Hewlett-Packard India Software Operations Ltd; 29 Cunningham Road, Bangalore – 560 052; INDIA

Phone: +91-80-2051289; Fax: +91-80-2200196

Email: ncnaren@india.hp.com

Abstract

Adaptive Workflow and Software Agent technology have the potential to revolutionize B2B E-Commerce

in the 21st century. Adaptive workflow allows for dynamism in business process definition and enactment,

while Agent technology helps to automate decision making among the entities executing the adaptive

workflows. Hence integrating Adaptive Workflow and Agents is highly essential for effectively facilitating

B2B E-Commerce. However, efforts to integrate the two have been lacking so far. In this paper, which is

an extension of [18], we describe our work on developing and implementing an integrated architecture

called AdaptAgent where Adaptive Workflows and Multi-Agent Conversations are modeled, executed and

adapted together seamlessly. AdaptAgent extends our previous work on a 3-tier adaptive workflow

architecture [12]; it also builds on our earlier work on what we call “flexible workflow support” [14],

which provides a means for increased flexibility in defining and managing adaptive workflows. In addition,

the unique contribution of this paper is a flexible and lightweight mechanism for managing adaptivity in

multi-agent conversations. Indeed, we believe that this is the first serious attempt to rigorously categorize

and model adaptivity in multi-agent conversations, especially from an architectural perspective.

Keywords: agents, adaptive workflow, agent-oriented workflow, agent-oriented architectures for B2B

1. Introduction

There are two new technologies that have the potential to revolutionize B2B E-Commerce in the 21st

century: Adaptive Workflow, which aims to manage the ever-changing business processes automated by

1 This paper is a revised and expanded version of [18].

Page 2 of 36

information systems, and Software Agent technology, which promises to endow information systems with

the requisite autonomy and decision-making capability so as to make them adaptable to the constantly

changing business scenario that is a part of the 21st century business environment.

Workflow and Agent technologies are complementary to each other, and there has been a lot of work on

integrating the two [2, 5, 27]. However, there is one thing that stands out when reviewing the research work

in this area, and it is that there has been little work integrating Adaptive Workflow and Agents. In B2B E-

Commerce, adaptive workflows are essential for allowing dynamism in business process definition and

enactment. Over and above this, Agent technology is useful in automating cross-organizational decision

making, viz., determining new business processes, adapting existing business processes, negotiating (resp.

renegotiating) new (resp. existing) contracts, which would result in workflow creation (resp. adaptation).

Hence the need to integrate Adaptive Workflow and Agents in order to effectively facilitate B2B E-

Commerce.

In this paper, we present an integrated architecture called AdaptAgent, where the adaptive workflow

processes and multi-agent conversations are integrated and modeled seamlessly. Apart from this, the unique

contribution of our work, is the idea of “flexible workflow support”, drawing on our earlier work [14]. This

approach classifies workflow processes and agent conversations on the basis of a 3-tiered control level

approach consisting of loose, medium and tight control levels. The “tighter” the workflow or agent

conversation, the more centralized is its definition and adaptation. Using this approach, it is possible to

provide extra flexibility in supporting and managing agent-oriented adaptive workflow processes.

This paper is organized as follows. We present definitions and concepts in the next section. In Section 3,

we present our 3-tier adaptive workflow architecture. Section 4 discusses our flexible workflow support

approach, which also extends our 3-tier architecture. In Section 5, we present our integrated AdaptAgent

architecture. In Section 6, we extend the AdaptAgent architecture to incorporate mechanisms for managing

adaptivity in multi-agent conversations – this is the main extension of our paper over our earlier work

described in [18]. In Section 7, we briefly discuss related work. The paper concludes in Section 8 with

suggestions for future work.

2. Preliminaries

2.1 Workflows

Page 3 of 36

We borrow our workflow definitions from our earlier work on adaptive workflow [12], which is in turn

based on [38]: a workflow is modeled as a directed graph whose nodes are the tasks with edges denoting

the flow of control between the nodes. Nodes are of two types – work nodes and route nodes. In work

nodes actual task execution takes place, while route nodes are decision nodes that route the workflow

information to the appropriate work nodes based on evaluation of certain rules. Edges are of four kinds –

forward edge, loop edge, soft-sync edge and strict-sync edge. Forward edges depict the normal workflow

execution, which is in a forward direction. Loop edges are backward pointing edges that are used to depict

the repeated execution of loops.

The rules in the route nodes are mainly of the Event-Condition-Action (ECA) type [9]. That is, each rule

specifies a particular action to be performed, upon receipt of an event, provided the condition is met.

The “sync” edges are used to support synchronizations of tasks from different parallel branches of a loop,

and they are of two types:

• A “soft-sync” edge is used to signify a “delay dependency” between two nodes n1 and n2, i.e., n2 can

only be executed if n1 is either completed or cannot be triggered anymore. This type of synchronization

does not require the successful completion of n1.

• A “strict-sync” edge between n1 and n2 requires that n1 successfully complete before n2 executes.

Clearly, the use of such edges must satisfy some conditions:

• Redundant control flow dependencies between nodes and loops should be avoided

• A sync edge may not connect a node from inside a loop body with a node not contained within that

loop

An example workflow graph that illustrates these definitions, is shown in Figure 1 below.

Page 4 of 36

We can also define states for each node, depending on where it is during the workflow execution. Hence

we define the following states for nodes: NOT-ACTIVATED, ACTIVATED, DONE, FAILED,

SUSPENDED.

The definition of these states naturally leads to the conclusion that we can define the state transition

diagram that each node has to obey. Indeed, this means that the state of every node in the workflow

instance, is governed by the transition rules in the state transition diagram. This diagram is given in Figure

2.

2.2

2.2 Agents

Currently, there is not much consensus on what an "agent" is, and many definitions abound. For our

purposes, we will combine the following definitions:

♦ [11]: "An agent is a computer program that acts autonomously on behalf of a person or organization"

START A

B

F

C

D

G

E

H

END

RouteNode

Work Node

Soft/Strictsync edge

NOT-ACTIVATED

ACTIVATED

SUSPENDED

DONE

FAILED

Start

Suspend Resume

Commit

Abort

Figure 2: WorkflowNode States

Figure 1: WorkflowDefinitions

LoopEdge

Page 5 of 36

♦ [5]: "an autonomous software component that interacts with its environment and with other agents"

Hence we define an agent as "a software component that acts autonomously on behalf of a person or

organization, and is also able to interact with its environment and with other agents".

Agents can be characterized as "weak" or "strong" agents [26]. Weak agents possess the following

characteristics: autonomous (having goals and plans for achieving them), social (can interact with other

agents and their environment), reactive (can perceive their environment and respond to changes that occur)

and pro-active (affect their environment rather than passively allowing their environment to affect them). In

addition to the above characteristics, strong agents also possess the following characteristics: mentalistic

notions (have beliefs, desires and intentions), rationality (can reason about their actions and perform

actions which further their goals in line with their beliefs, desires and intentions) and learning (have the

ability to learn from their actions and their environment and other agents). In this paper, we will restrict our

attention to weak agents.

A 7-axis characterization of agents can be found in [5], and has the following dimensions: Adaptability,

Autonomy, Collaboration, Intelligence, Mobility, Persistence, Personality/Sociability. For our purposes, we

require our agents to have high adaptability, autonomy, collaboration and persistence. The other 3 axes, i.e.,

intelligence, mobility and personality/sociability, are not applicable for us, since we are concerned with

"weak" agents.

The Federation for Intelligent and Physical Agents (FIPA ), has been developing standards for agents and

multi-agent systems. Their reference architecture for agent platforms is accessible from [4].

There are many interesting linkages between workflow and agents, which we will be exploiting in this

paper [5]:

• Agents can collaborate to perform a workflow, e.g., telecom provisioning, service provisioning,

scheduling

• Agents can be used to make workflow more intelligent, e.g., by adding negotiation, reasoning or

decision points

• Workflow can be used to choreograph a set of agents, e.g., application management

Page 6 of 36

• Workflow can be used to coordinate interaction between people and agents, having agents delegate to

people or other agents, e.g., telecom management system alerting a human operator, or assigning a

repair or provisioning engineer

For our purposes, we recognize that the first two linkages represent agent-enhanced workflow (using agents

to enhance workflow systems, i.e., agents representing workflow systems) and the last two represent multi-

agent conversations (i.e., using workflow concepts to model agent interactions in multi-agent systems).

Later in this paper, we will realize that both types of linkages are essential for our AdaptAgent. Agent-

enhanced workflow will be used to define what we will call "macro-workflow"; and multi-agent

conversations will be used to model what will be termed "micro-workflow". Hence "macro-workflow" will

model Adaptive Workflows, whereas "micro-workflow" will model Multi-Agent conversations.

3. Three Tier Approach for Adaptive Workflow Management

3.1 System Architecture

In [12], we have developed a 3-tier approach to adaptive workflow management, which is based on the

graph-based workflow model described in Section 2.1. We have identified that adaptivity is basically of

three types:

• Adaptivity at instance level: here, only the workflow instances need to be modified, perhaps to make

them more efficient, or to make them easier to execute. The modules in our architecture that implement

this, are:

♦ Basic Workflow Model - stores the instances of our workflow model

♦ Workflow Change Model - stores the constructs for specifying dynamic workflow changes as

graph transformations

♦ Workflow Change Verifier - performs the syntactic and semantic checking of the graph

transformations

♦ Workflow-Schema Interface Manager - is an interface module that interacts with the next higher

layer, which is the Schema Layer

• Adaptivity at schema level : here, the workflow schema will need to be modified - this would arise if

certain "ways of doing things" change, and will necessitate radical modifications to all the workflow

instances of the schema in question. The modules that implement this, are:

Page 7 of 36

♦ Schema Handler - creates, versions and stores the workflow schema

♦ Schema Migration Manager - handles migration of workflow instance between schemas, and

interfaces with the Schema Handler

♦ Schema-Planning Interface Manager - interface module that interacts with the layer above, i.e,

Planning Layer

• Adaptivity at planning/goal level: here, the goals of the workflow may themselves have to be

modified in response to changing environmental conditions - this could cause radical changes in the

schema themselves, which could cause disruptive changes in the workflow instances. The modules that

implement this, are:

♦ Organizational Workflow Repository - organization-wide repository of all workflow processes

stored into the system; stores the workflow schemas and their instances, and also stores the goals

and sub-goals that led to the creation of the workflow in the first place.

♦ Goal Specification Module - through this module, the workflow designer first enters the goals and

sub-goals that the workflow has to satisfy. He/she can then look into the Organizational Workflow

Repository, for reusing any workflows from the past that can satisfy – either fully or partially – the

goals that he/she has specified.

♦ Workflow Design Module - with this module, and with the goal and workflow information from

the Organizational Workflow Repository, the workflow designer can design the workflow schema.

He/she will then check it into the Organizational Workflow Repository. The schema will then be

transferred into the Schema Handler via the Schema-Planning Interface Manager, where it will be

appropriately versioned and stored. The appropriate version number is then communicated to the

user.

The pictorial representation of this architecture is given in Figure 3 below.

Page 8 of 36

3.2 Workflow Adaptation

Any change to be made on-the-fly to an already executing workflow, has to proceed as per the following

steps:

• The proposed change has to be specified in terms of a graph transformation (as already mentioned in

Section 3.1)

• The graph transformation is verified using graph queries in the system; if the transformation is not

feasible, the user is notified, and the unsatisfied portions of the query are also informed to the user

• If the transformation is feasible, the user is informed and the query is executed.

Our algorithms are as follows.

Graph Transformations:

Schema - PlanningInterface Manager

WFRepository

SchemaMigrationManager

Schema Handler

Workflow - SchemaInterface Manager

WFDesignModule

GoalSpecification

Module

Users

PLANNINGLAYER

SCHEMALAYER

INSTANCELAYER

Figure 3: Three-Tier AdaptiveWorkflow Architecture

WorkflowChangeVerifier

BasicWorkflow

Model

WorkflowChangeModel

Page 9 of 36

If a change is needed to the workflow definition on the fly, then this will have to be specified by the user to

the system via graph transformations. Each graph transformation obeys the following sequence:

• Specify the sub-graph which needs to be transformed – this will involve isolating that part of the

workflow, by specifying the beginning and ending nodes of the sub-graph

• Specify what the sub-graph will be after the transformation – here, the user will have to specify the

new workflow sub-graph that will substitute for the old sub-graph

• Specify the basic operations needed in terms of node addition/deletion and edge addition/deletion, that

define the transformation – in order to get from the old sub-graph to the new sub-graph, the user will

have to specify the order in which the transformation, which is essentially a combination of node and

edge additions/deletions, will have to take place

Graph Queries:

The graph transformation provided by the user triggers certain queries within the graph-oriented internal

representation of the workflow model. The queries that are executed by the system, are:

• Checking syntactic correctness and consistency of the transformation (using the graph-theoretic

properties of the workflow model as in [38]) – these include the following:

Ø All input parameters of a node are supplied before the node is executed

Ø Nodes from different parallel branches of a loop are not allowed write access to the same data

element, unless they are synchronized by a sync edge

• Checking semantic correctness and consistency of the transformation (using the ECA-type rules

provided in the route nodes)

If the queries are executed successfully, the user is notified and the appropriate changes are made to the

workflow definition. If not, the user is informed as to which queries failed.

Changing the Workflow Schema:

Changing the workflow instance on the fly, naturally raises the question of whether – and if so, when – to

migrate the new instance onto the definition, so that the workflow schema itself changes. There are two

options here:

• Modify the workflow schema as soon as the new workflow instance is created

Page 10 of 36

• Mark the new workflow instance as a new version of the old workflow schema, thereby creating

version trees of workflow schemas and their associated instances (as described in [6])

For example, if a workflow instance I of a schema S is adapted to I', then one of two things can happen:

• I' is "rolled into" S, thereby changing S

• I' is stored as an instance of S-version2, where S is stored as S-version1

3.3 Typical Usage Scenario

In order to illustrate how our architecture is used, we sketch a typical usage scenario. We do this by

enumerating the possible reasons for a workflow designer to adapt the workflow.

(a) Changes in goals - the goals underlying the currently existing workflow processes may have changed,

necessitating a major change in the workflow schema (for example, the business will have to be

substantially reengineered and repositioned, or its product line itself may undergo a major change).

Perhaps the current workflow schema may have to be discarded and a new one created, along with its

associated workflow instances. This will have to be done at the Planning Layer.

(b) No changes in goals, but changes in business relationships and environment - this will necessitate a

change in the workflow schema, since the business models governing the workflow may have to

change, although the overall business goals may remain unchanged (for example, the workflow may

need to be implemented in a distributed fashion, by using sub-contractors, necessitating a change in the

workflow schema). This will have to be done at the Schema Layer.

(c) No changes in either goals or business environment, but the need to improve delivery efficiency or the

need to introduce alternative processes (this is sometimes referred to in the literature as "exception

handling [33]") - this will necessitate a change in the workflow instances only. This can be restricted

to the Instance Layer itself.

Hence we can look at the following typical scenario:

• The workflow designer perceives a situation in the organization where there is a need to change some

business processes. He/she then determines which of the situations above, viz., (a), (b) or (c) apply.

• In case (c) applies: In this case, only an instance of the workflow schema is being modified. This

may essentially be a one-time exception in order to deal with a special case that was not thought of

earlier. In this situation, as described in Section 3.2 ("Changing the Workflow Schema"), a new version

Page 11 of 36

of the workflow schema is created. After the workflow process has completed executing, the workflow

designer can then consider migrating all the workflow instance to the new workflow schema version,

and discard the old version, should he so choose. This can be done following the rules as described in

[6].

• In case (b) applies: This could have a serious impact on the business, since business relationships

may themselves have to be rewritten. This will involve evolving a new workflow schema, and ensuring

that all future workflow instances are derived from this schema and not the older one. Again, as

described above, migration of the existing workflow instances will have to be decided as described in

Section 3.2 ("Changing the Workflow Schema") and in [6].

• In case (a) applies: Such a situation would arise if the business itself is being reengineered or

repositioned. In such a case, the most likely response would be complete all the currently running

workflow instances (depending on whether they can be completed - this will have to be a business

decision) and starting the workflow design from scratch for future activities - to define new goals,

workflow schema and instances.

4. Flexible Workflow Support

Traditionally, workflow management has been regarded as being centralized, monolithic, rigid and not

easily amenable to adaptation; once a workflow process was defined, it was regarded as more or less “cast

in stone,” and to be executed with little change. Moreover, the monolithic nature of workflow has always

implied rigid centralized control, thereby forcing all users to follow the workflow without question.

However, this does not meet the needs of most businesses and B2B E-Commerce systems today, due to

their inherent dynamism and decentralized nature. To this end, in our previous work, we extended ideas

from [7] and developed an architecture for what we called “flexible workflow support” [14], containing the

following ideas:

• Any workflow can be classified to belong to one of the following three “control levels” – loose,

medium or tight

• Loose workflows can be defined, started and adapted by any user (not necessarily the Workflow

Administrator) in collaboration with the other participants in the workflow. Such a workflow can

adapt itself as much as possible, depending on the need and on the participants.

Page 12 of 36

• Medium workflows are also defined, started and adapted by any user, but need approval from the

Workflow Administrator, in order to ensure that they adhere to a particular workflow schema.

• Tight workflows are the traditional workflows, which are defined, started and adapted centrally by

the Workflow Administrator.

• In this regard, the following points are to be noted:

o Henceforth, in this paper, we will refer to the person defining the workflow (who can be any

user or the Workflow Administrator) as “workflow definer”.

o In this paper, we will not be discussing the issue of determining whether a workflow instance

adheres to a workflow schema. Rather, we will be leaving that to the judgement of the

workflow definer. Obviously, an instance can be said to adhere to a schema if it obeys the

"overall structure" of the schema, perhaps with a few exceptions and deviations. In the

literature [29, 30], there have been some techniques proposed for solving this problem, by

looking at the issue of "workflow inheritance" in a manner similar to that of object-oriented

inheritance, but this problem is far from being solved fully.

• Hence our extensions to Figure 3 to accommodate flexible workflow support, are the following (as

depicted in Figure 4 below):

Ø Logically separate the Workflow Repository for representing and storing these three types of

workflows.

Ø Have a Schema Discovery Module as part of the Goal Specification Module, which will assist

the Workflow Administrator in observing the execution of several instances of a loose

workflow and then “upgrade” it to medium level by designing a schema for it; all future

executions of this workflow will then have to be at medium level, adhering to the schema.

Ø Similarly, the Workflow Administrator can, using the Goal Specification Module, also

observe the execution of several instances of a medium workflow and “upgrade” it to the tight

level; the assumption behind this is that workflows that are executed sufficient number of

times are more closely understood and can be controlled centrally.

Hence the same workflow adaptation technique as described in Sections 3.2 and 3.3 can be used here, the

main difference being the new role of the workflow definer vis-à-vis that of the workflow administrator.

Page 13 of 36

• Extending this to distributed workflow means that there are two categories of workflows, which

can be at different control levels – the overall workflow and its constituent sub-workflows (which

could be executed at different workflow servers) – resulting in nine different combinations for the

three control levels. Essentially they are the following:

Ø If the overall workflow process is at loose level, this means that it is defined among the

workflow servers in a peer-to-peer fashion by the workflow definer. However, each

constituent sub-workflow can be at any of the three levels, and managing the constituent sub-

workflows becomes an internal matter for the individual workflow servers.

Ø If the overall workflow process is at medium level, this will need a Central Coordinator (also

known as CC – similar to that of Workflow Administrator) that will need to approve the

workflow before it is executed. The individual workflow processes can be at any control

level; however, the CC will ensure – from the viewpoint of the overall workflow process –

that the individual workflow processes are represented as “black boxes” with predefined

inputs and outputs, which the individual workflow servers will need to satisfy.

Ø If the overall workflow process is at tight level, then the CC itself is in charge of defining and

imposing the overall workflow process on the individual workflow servers. Here also, the

individual workflow processes are specified as “black boxes” with predefined inputs and

Users

Figure 4: FlexibleWorkflowPlanning Layer

Schema DiscoveryModule

GoalSpecModule

WF DesignModule

Loose WFs

Medium WFs

Tight WFs

WFRepository

To Schema-PlanningInterface Manager

Page 14 of 36

outputs, and it will be the responsibility of the individual workflow servers to design

workflow processes to satisfy the inputs and outputs.

v Hence the CC in this case is also an adaptive workflow system just as the one described

in Section 3 and pictorially depicted in Figures 3 and 4, with the important difference that

it supports and manages the overall distributed workflow process, with the constituent

sub-workflows being managed by (probably geographically separated) individual

workflow servers.

• Here, we see that adaptation can take place at many levels – at the overall workflow level, and at the

levels of the individual sub-workflows and their sub-workflows (if any), and so on. However, since

sub-workflows are always defined as “black boxes” at the level of their parent workflows, it is the

responsibility of the individual workflow definers to adapt their sub-workflows should there be a need

to do so, at their respective Instance, Schema or Planning layers. In other words, workflow adaptivity

here is defined in a "top-down" fashion starting at the CC, and is dependent on the overall business

goals.

5. AdaptAgent Architecture

The AdaptAgent architecture is envisioned as an extension of our 3-tier adaptive workflow and the flexible

workflow-derived Central Coordinator (CC) ideas described above, in order to accommodate multi-agent

interactions. That is, the CC not only coordinates the workflow processes but also the conversations among

the agents that represent the workflow servers. Our basic premise is that agents execute workflows as part

of meeting their goals; in addition, they would also need to interact with each other via conversations that

would involve message passing among them in a language such as KQML [10].

An example of this is a supply chain scenario, where the agents represent an automobile company and its

suppliers (which are also agents), working together to produce an automobile. All the agents will execute

the overall workflow process needed for automobile production consisting of its constituent workflows

which are executed by the individual supplier agents. In addition, the supplier agents will also interact with

each other and their CC via multi-agent conversations that would not necessarily involve the data transfer

or product delivery that is common with workflow process execution. One such example of a multi-agent

Page 15 of 36

conversation, would be a negotiation [26] over prices or delivery schedules, whereas delivery of an

automobile component would be an example of a workflow execution by a supplier agent.

Hence as defined in Section 2, workflow processes are modeled as “macro-workflows”, with agent

conversations being modeled as “micro-workflows”. The reason for this, is that micro-workflows can be

modeled as single tasks within the macro-workflows with predefined entry and exit criteria (which are

essentially boolean conditions); within a micro workflow, its related macro workflows are represented

within these entry and exit criteria. We therefore have to extend our CC architecture of Section 4 in order to

accommodate two types of distributed workflows – macro and micro workflows, with the following

additional characteristics:

• A micro workflow is defined after its respective macro workflows have been created. As explained in

the supply chain example above, the micro workflow is a conversation conducted by the agent

executing the macro workflow, jointly with the other agents involved in the conversation. The

conversation is started after the agent’s macro workflow execution has crossed the point represented by

the predecessor of the task representing the micro workflow. After the conversation is completed, the

agent will then resume its macro workflow execution from the successor of the task representing the

micro workflow. This will be the same for every other agent participating in the conversation.

Naturally, the outcome of the conversation could determine the course of the future macro workflow

executions of the agents, as per the macro workflow definitions. Hence it is necessary for the micro

workflow to be defined after its respective macro workflows have been created.

• Macro and micro workflow processes can be adapted relatively independent of each other; however,

when a macro (resp. micro) workflow is adapted, the effect of the adaptation on its related micro (resp.

macro) workflows will need to be considered before going ahead with the change. This is done as

follows:

Ø If the change is to a macro workflow instance or schema, then the affected micro workflow

instance will be syntactically and semantically checked. If, as a result of this, a change in the

micro workflow is needed, then it must also be adapted as per the procedure to be described later

in Section 6.

Page 16 of 36

Ø If the change is to the micro workflow, then if there is a corresponding change in its input or

output to any of its related macro workflows, the macro workflow may also need to be adapted as

per the procedures described in Sections 3 and 4.

• Macro and micro workflows can be at different control levels; however, this should not cause any

issues, due to the highly modular way in which the micro workflows have been modeled as “black

boxes” within macro workflows. This enables micro workflows to be managed independently of macro

workflows, as long as the input and exit criteria for the micro workflows are satisfied.

• Since multi-agent conversations are structurally different from macro workflows, they can be

represented as multi-graphs using techniques such as Dooley Graphs [24]. However, from the

viewpoint of the macro workflows, they are merely single tasks with predefined entry and exit criteria.

Similarly, the presence of the macro workflow is modeled in the micro workflow by means of the entry

and exit criteria.

• Agent Communication Languages (ACLs) such as KQML [10] can be used for implementing the

multi-agent conversations. Each edge in the multi-graph will represent a performative sent by an agent

to its recipients, which would either be a broadcast message to the recipients, request for information,

reply to an earlier message, etc.

6. Adaptive Multi-Agent Conversations

As already described in Section 5, multi-agent conversations can also, just like macro workflows, exhibit

adaptivity. However, adaptivity of conversations is quite different, for the following reasons:

• Conversations typically involve more than one party interacting with each other. Hence their structure

needs to be quite different from that of macro workflows.

• Unlike macro workflows, adaptivity in conversations can occur much more frequently and rapidly; it

is, after all, easier for an agent to change the “course” of a conversation than is it for a (human or

automated) worker to change the course of a workflow. This is because conversations consist of a

collection of “speech acts” [1, 23] that are primarily message exchanges between agents, and which

could easily change an agent’s internal state.

• Due to this, conversations are typically much more flexible and “lightweight” than traditional

workflows, and hence conversation management is quite different from workflow management.

Page 17 of 36

• While individual macro workflow tasks possess state (see Section 2.1), state information in

conversations is present only at the overall conversation level. This is because state information makes

sense only for entire conversations, i.e., whether the conversation is NOT-ACTIVATED,

ACTIVATED, SUSPENDED, FAILED or DONE.

Hence adaptivity in conversations requires to be studied quite differently from that of macro workflows.

6.1 Adaptivity in Multi-Agent Conversations

Due to the lightweight nature of conversations, it should be easier to adapt conversations extensively in

mid-stream without the need to change the Conversation Schema, since such a change would be disruptive

to all the participating agents. To that end, although we retain the original 3-tier architecture, i.e., Planning-

Schema-Instance for conversations, we split the Schema layer into two sub-layers:

• The “upper” sub-layer, will continue to be the Schema layer, and will interface with the Planning layer

• The “lower” sub-layer will be called the Conversation Mode Sub-Layer (CMSL) , and will provide the

necessary added flexibility and structure as explained below.

In the traditional macro workflow architecture, a Schema is essentially a process template, and an instance

is derived from it. In that sense, a macro workflow typically possesses a “linear” flow, in that possesses a

single beginning and a single end. A conversation, on the other hand, is the result of a multitude of speech

acts “uttered” by several agents, some of them simultaneously. Hence a conversation can be simultaneously

started and successfully completed by several agents acting together. Thus a conversation schema should be

an unordered set of speech act sequences along with some composition rules that dictate how the speech act

sequences should be composed. With this in mind, we define our layers as follows:

• The Planning Layer will contain the Goals that the conversation should meet, along with Policies

[21]. This layer will also store the Commitments [25] that participating agents make to each other,

which are derived from the Goals.

Policies are global rules that constrain how the Schema should be designed to meet the goals. They can

be regarded as boolean conditions in first-order logic. Hence they can be represented in computer-

readable form. For example, policies can be represented in the Z formal notation as in [28].

• The Schema Layer will contain the Conversation Schema (simply called Schema), which is essentially

an unordered set of legal (as per the Policies) sequences of speech acts.

Page 18 of 36

• The CMSL will contain a subset of the speech act sequences belonging to the Schema, and this is the

Conversation Mode (simply called Mode). If the total number of legal speech act sequences in the

Schema is S, then there are theoretically 2S possible modes for a Schema.

• The Instance Layer will consist of a Conversation Instance (simply called Instance), which is a

particular legal (as per the Policies) arrangement of the speech act sequences in the mode.

Hence the following mappings can be made with our original 3-tier architecture of Figures 3 and 4:

• Planning Layer:

Ø The WF Repository will store conversations along with their associated macro-workflows

Ø The Goal Specification Module will store the conversation goals and their associated policies in

addition to macro-workflow goals

Ø The WF Design Module will be used by the workflow definer to define conversation

schema/modes/instances also

• Schema Layer :

Ø The Schema Handler creates, versions and stores the conversation schema along with the macro-

workflow schema

Ø The Schema Migration Manager will handle schema level adaptations for agent conversations and

macro workflow. In addition, for managing Modes, this module will contain an additional module

within it called Mode Handler, which will also play the role of the CMSL.

Ø The Schema-Planning Interface Manager interacts with the layer above, i.e., the Planning Layer

• Instance Layer:

Ø The Basic Workflow Model stores the conversation instances along with the macro workflow

instances

Ø The Workflow Change Model will store the constructs for specifying changes to conversations,

and also for macro workflows

Ø The Workflow Change Verifier will check whether the proposed conversation changes are

consistent with the Policies, just as it also verifies whether proposed macro workflow changes are

syntactically and semantically valid.

Ø The Workflow-Schema Interface Manager will interface with the Mode Handler

Page 19 of 36

Hence the CMSL provides both flexibility and structure in the following way:

• It provides a structure to the conversation by limiting the number of possible speech act sequences in

the Mode as a subset of the Schema

• It provides flexibility through the ability to “mix and match” the speech act sequences in the Mode,

subject to the Policies

In Section 6.5, we will provide an example that illustrates all these ideas, especially the utility of the

CMSL.

6.2 Adaptive Conversation Architecture

In Figure 5 below, we provide a UML-like class diagram representation of our adaptive conversation

architecture. The diagram describes the different components of the architecture, and how they relate to

each other, as described in Section 6.1. In this section we will also focus on how this architecture could

actually be implemented in practice.

Page 20 of 36

Figure 5

Conversation Goals

Conversation Policies

Commitments

Conversation Schema

Conversation Modes

Conversation Instances

Speech Acts

Conversation States

Combinations of Speech Acts

0..*

11

1..*

1

1..*

1

1..*

1

1..*

1

1..*

1..*

1..*

1

0..*

1

0..*1

1..*

<<Constrained by>>

<<equivalent to>>

<<contains>>

0..*

1

<<contains>>

<<belongs to>><<signifies>>

Page 21 of 36

As already stated earlier, a multi-agent conversation is an ordered sequence of speech acts that should

fulfill certain Goals. The goals are constrained by zero or more Policies [21] that are essentially constraints

on how Schemas can be derived to meet the goals. A Goal would be met by the participating agents

meeting one or more Commitments [25] to each other. A Schema consists of at least one Mode which, as

defined in Section 6.1, is a subset of the speech act sequences belonging to the Schema. From a Mode, one

or more Instances can be derived. Each such instance consists of at least one Speech Act. A combination of

zero or more speech acts represents a State of the conversation (if no speech act has been executed at all,

then the conversation remains in NOT-ACTIVATED state). A state signifies either meeting or violating

zero or more commitments; for example, for a conversation that is in DONE state, all commitments made

by the participating agents (and hence all the goals of the conversation) are expected to have been met. For

a conversation in any of the other states, not all the commitments may have been met.

In [17] we have shown how distributed macro workflows can be adapted, based on the state information of

individual macro workflow tasks. Basically, a macro workflow adaptation consists of a combination of task

addition and/or task deletion, and workflow adaptation can happen in one of two ways: by aborting or

rolling back tasks.

Only tasks that are in either ACTIVATED, SUSPENDED, DONE or FAILED state can be rolled back.

Likewise, only tasks that are in either NOT-ACTIVATED, ACTIVATED or SUSPENDED state can be

aborted, as long as the abortion does not permanently alter the state of the workflow repository. Also, tasks

that are being rolled back cannot be aborted, and vice versa.

Hence, since conversations as a whole possess state, the state management techniques for macro workflow

tasks as described in [17] need to be suitably tailored for conversations. To that end, we formulate the

following rules:

• Only speech acts of a conversation that is in ACTIVATED, SUSPENDED, DONE or FAILED state

can be rolled back, and those commitments made (if any) by those speech acts are nullified. This will

cause the conversation to move back to a state prior to the utterance of those speech acts.

• Only conversations that are in either NOT-ACTIVATED, ACTIVATED or SUSPENDED state can be

aborted, and this will also nullify any prior commitments that an agent may have made during the

course of the conversation.

Page 22 of 36

• If a part of a conversation is being rolled back, then the conversation cannot be aborted. Likewise, for a

conversation that is being aborted, no part of it can be rolled back.

Hence a conversation has to be aborted entirely, in which case it will return to NOT-ACTIVATED state (if

it is not already in that state); whereas, a conversation can be rolled back partially to the state that it was in

before the utterance of the speech acts that were deleted during the roll-back.

Thus, the crucial question that we have to answer, is how to relate speech act sequences to states and state

changes. For example, what does it mean for a conversation to change state from ACTIVATED to

SUSPENDED or DONE state? Hence support needs to be provided for the workflow definer to define

which combinations of speech acts will keep the conversation in the same state, and which will change the

conversation state. This information can be kept in tuples of the following form:

<From-state, To-state, {original speech acts for the From-state}, {added or deleted speech acts that cause

the state change from the From-state to the To-state}, {Policies that apply here}>

This information can be stored as a set of tuples in the Schema Layer, and it can be used for determining

which state the conversation is currently in, and when its state could change. Those Policies from the

Schema that apply here, are also stored in the tuple. Depending on the conversation state, the necessary

adaptation mechanisms are implemented, as described below in Section 6.3.

6.3 Conversation Adaptation Mechanism

Since a typical conversation will involve several agents, a well-defined protocol is necessary for adapting

conversations, as follows:

a) One of the agents feels the need for a change and proposes a change to the workflow definer (please

recall that multi-agent conversations can be at any control level, depending on who the workflow

definer is - whether loose, medium or tight control). Alternatively, the workflow definer may himself

decide to change the conversation.

b) The change is considered by the workflow definer, who will then create a new conversation instance.

Of course, before doing so, the conversation is syntactically and semantically checked to ensure that it

adheres to the mode/schema and the Policies, respectively - this checking can be done by the system in

a manner similar to that done for macro workflows in Section 3.2. If the conversation is at medium

level, then the workflow administrator also has to approve this change.

Page 23 of 36

c) The change is then implemented by the workflow definer, i.e., the conversation is adapted. Depending

on the nature of the adaptation - instance level, mode level or schema level - the appropriate

modifications are made to the instance/mode/schema. As we shall see in Section 6.3.1, this

implementation can be automated while preserving safety and correctness properties.

d) Similar to the approach described in Section 3.2, version trees of instances, modes and schemas are

also maintained, with appropriate links to each other. However, the major difference here, as compared

to macro workflows, is this: since a schema is an unordered set of speech act sequences, one schema

version can have multiple mode versions. Also, since an instance is a particular arrangement of the

speech act sequences in a mode, a single mode version can have multiple instance versions. This idea

will become clearer in Section 6.5, where it will be demonstrated in an example.

In order for the conversation to be adapted, it must be either aborted or rolled back, after which the new

conversation instance can start to be used. For this, the state information stored in the tuples mentioned in

Section 6.2 need to be first used, in order to determine which state the conversation is in.

The conversation is aborted by the workflow definer by the sending of an abort message to each

participating agent, that all speech acts that they have sent to each other during the course of the

conversation are null and void, and have to be erased from their individual memories. This is to be done so

that the (probably persistent) internal state of each agent is not permanently affected by those speech acts.

In the case of conversation roll-back , only those speech acts signifying prior commitments, need to be

deleted (and their associated commitments nullified, as already described in Section 6.2). This is done by

the workflow definer notifying all participating agents that these commitments are nullified, and deleting

the appropriate speech acts so as to nullify the commitments. This will cause the conversation to move back

to a state prior to the utterance of these speech acts, so that the adapted conversation can be introduced.

Sec 6.3.1 Ensuring Safety and Correctness during Conversation Adaptation

During on-the-fly conversation adaptation, one of the most important requirements is to maintain safety and

correctness properties while the conversation is being adapted. This is needed in order to ensure that the

adaptation does not cause inconsistencies in the conversation state. For example, if one of the conversation

goals has been met during the course of the conversation and the conversation is to be rolled back so that

the goal is to be nullified, then all the related speech acts should be deleted from the conversation. If the

Page 24 of 36

goal is to remain even in the modified conversation, then the related speech acts should be retained;

otherwise, the goal will not be satisfied, resulting in an inconsistency in the conversation.

Hence step c) of the adaptation protocol presented in Section 6.3 above needs to be elaborated in order to

ensure that consistency is maintained. In this Section, we present this elaboration.

Essentially, we utilize the relationships depicted in Figure 5. From that Figure, we see that the conversation

goals are satisfied by the collection of speech act sequences that make up the conversation schema. In

particular, a goal is mapped to a set of commitments that together help realize the goal.

Each commitment is a speech act by an agent to other agents in the conversation. Hence we can assume the

existence of a "commit" speech act as a "reserved" speech act for expressing commitments. This will then

help in keeping track of which goals have been satisfied so far in the conversation, via the

goalßàcommitments mapping for each goal.

As already described in Section 6.3, the conversation is either aborted or rolled back depending on which

state it is in. The following are the state changes that are possible:

• NOT_ACTIVATED à ACTIVATED

Ø This happens once an agent starts the conversation by sending a message to any other agent(s)

• ACTIVATED à SUSPENDED

Ø This is supposed to be done only by the workflow definer or the Workflow Administrator, by

sending a "suspend" speech act (another “reserved” speech act)

• SUSPENDED à ACTIVATED

Ø This happens once the workflow definer or the Workflow Administrator sends a "resume" speech

act (another “reserved” speech act) to the agents, and the agents once again resume the

conversation

• ACTIVATED à DONE

Ø The conversation ends successfully once all the necessary "commit" speech act have been sent by

the appropriate agents, which would result in all the conversation goals being satisfied

• ACTIVATED à FAILED

Ø The conversation is said to end in failure when the agents stop sending speech acts before all the

goals have been satisfied by their respective "commit" speech acts

Page 25 of 36

Based on the above preliminaries, we are now ready to describe the step c) in more detail below (please

note that this entire procedure can be automated, hence this means that the safety and correctness properties

can be preserved automatically):

• All the “commit” speech acts of that portion of the conversation that is to be adapted, are identified

• If the conversation is in ACTIVATED or SUSPENDED state:

o If the conversation is being aborted, all the relevant speech acts are to be erased from the

Workflow Repository and also from the internal memories of the participating agents. If the

conversation is being rolled back, only the “commit” speech acts are to be erased.

o Since, in either case, the “commit” speech acts will have to be erased from the conversation and

also the individual memories of the participating agents, the goalßàcommitments mapping is

checked to ensure that the related goals are also stored in the Workflow Repository as not

satisfied.

o Once this is done, the adapted conversation starts. If the conversation had been in SUSPENDED

state earlier, it is then brought back into ACTIVATED state by the sending of the “resume” speech

act

• If the conversation is in NOT_ACTIVATED state, then the adapted conversation simply starts in

ACTIVATED state.

• If the conversation is in DONE state, it can only be aborted. Hence in this case, all new conversation

instances will adhere to the new conversation mode or schema. If the earlier conversation has to be

aborted, then all the speech acts in the conversation are erased, and the conversation goals are stored in

the Workflow Repository as not satisfied.

• If the conversation is in FAILED state, then the situation is similar to that of the DONE state. The

major difference, however, is that only a few conversation goals may have been satisfied, in which

case only these goals are to be stored in the Workflow Repository as not satisfied.

6.4 Relation to Macro-Workflow

As already explained in Section 5, a multi-agent conversation is represented as a single task in a macro-

workflow with predefined entry and exit criteria. We now see that these criteria are nothing but the Goals

that the conversation has to meet. Hence if the related macro-workflows of the conversation change, this

Page 26 of 36

could trigger an adaptation of the conversation. Alternatively, a change in the conversation could trigger an

adaptation of the related macro-workflows.

6.5 An Example

In this section we present a simple yet non-trivial example that illustrates our basic definitions. This is a

variant of the well-known Contract Net Protocol (CNP) example that is used to illustrate multi-agent

conversations. In particular, our example is inspired by the CNP variants discussed in [19].

Basically, the CNP involves negotiations between a prime contractor and several sub-contractors; the prime

contractor wants to award a contract to one or more sub-contractors based on certain criteria determined by

it. In fact, we see that the prime contractor can be the automobile company (recall the example at the

beginning of Section 5), while the sub-contractors are the automobile company's suppliers.

Hence the goals of this conversation are the following:

G1 = The prime contractor should obtain the “best” bid as per its criteria

G2 = At least one sub-contractor is the winner (there could be more than one winner, depending

on the number and complexity of the criteria defined by the prime contractor)

G3 = The winners are those that have submitted the “best” bids

The goals G1 through G3 imply the following commitment that signifies that the conversation has reached

the DONE state:

C1 = The prime contractor commits to selecting one or more winners based on their bids

Hence the first step would be to define the Schema that will meet the goals. Our schema is therefore the set

of the following speech act sequences:

S1 = prime contractor accepts all bids, then chooses the “best” bids

S2 = prime contractor accepts the first M bids in first-come-first-served order, and chooses the

first bid(s) that meet its criteria

S3 = conversations between the prime contractor and sub-contractors, on issues/clarifications

regarding the contract and its criteria (i.e., the “fine print” of the contract)

S4 = prime contractor re-issuing the call for bids after a “time-out” period or after the first M bids

have arrived and are found unsuitable

Some example Policies accompanying the Schema could be the following:

Page 27 of 36

P1 = S1 and S2 should not occur together in the same Mode

P2 = S3 should be executed after S1 has started

P3 = S4 can be executed only after S1 has completed, and with the conversation being in FAILED

state

We could choose the following Mode from the Schema (we can see that this Mode obeys the Policies):

Mode1 = {S1, S3, S4}

From Mode1 we can generate the following Instance (let us call it Instance1):

In Instance1, the prime contractor will wait until all bids are received (as per the first S1). In the meantime,

it will negotiate with individual sub-contractors about the “fine print” of the contract (as per S3) and may

even award a few “winning” bids that may have come in early (as per the first S1). If no bids are submitted

within the “timeout” period the contractor will simply issue a fresh call for bids (as per S4). Finally, the

prime contractor will select the best bids among those received and award the contract to the winners (as

per the second S1 in Instance1).

From Instance1 we can see that there are multiple ways in which the speech act sequences in Mode1 can be

“mixed and matched”. For example, an example of Instance-level adaptivity would be to change from

Instance1 to Instance2, which is depicted below:

In Instance2, the prime contractor attempts to call for bids from all sub-contractors 5 times before settling

on winners. This is a minor deviation from Instance1; hence we see the utility of the CMSL (introduced in

Section 6.1) in helping us to quickly modify the conversation instance without having to refer to the

schema.

START S1 S3 S4 S1 END

START S1 S3 S4 S1 END

5 times

Page 28 of 36

If Instance1 has to be adapted to Instance2, and if this has to be done while the conversation is executing

S4, then it is still in ACTIVATED state. Also, since the second S1 is still to be executed, Instance1 can be

modified into Instance2 without aborting or rolling back the conversation (of course, the conversation can

still be aborted at this stage, since doing so would cause minimal impact; however, this is a decision that

the workflow definer has to take). If Instance1 has to be adapted to Instance2 while the second S1 is being

executed, then, depending on how far S1 is executed, some commitments that the prime contractor may

have made to a “winner” sub-contractor, may have to be erased/nullified (along with their associated goals

as described in Section 6.3.1), so that the execution of the second S1 can begin afresh, and can be done 5

times.

Mode-level adaptivity occurs if Mode1 is replaced by Mode2 (which also obeys the Policies), where

Mode2 = {S2, S3, S4}

Hence an instance of Mode2 could be Instance3, which is depicted below:

Thus if the Mode changes from Mode1 to Mode2, the conversation instance would change from Instance1

(or Instance2) to Instance3. Here also, if S2 has to replace the second S1 of Instance1 (or Instance2), then

the second S1 will have to be deleted (and its commitments, if any, erased/nullified along with their

associated goals as per Section 6.3.1) so that S2 can be introduced (i.e., another conversation roll-back).

In order to demonstrate Schema-level adaptivity, let us introduce a new sequence to the schema (with the

Policies remaining unchanged):

S5 = one of the “winners” expresses inability to execute his part of the contract as promised, hence

that part of the contract is cancelled

Hence we can define Mode3 (which also obeys the Policies) as follows, and which would replace Mode1 or

Mode2:

Mode3 = {S1, S3, S4, S5}

START S2 S3 S4 S2 END

Page 29 of 36

This could result in Instance1 (or Instance2) being replaced by Instance4, which is depicted below:

The meaning of Instance4 is that the prime contractor has to keep accepting fresh bids after one or more the

“winners” default due to inability to meet the terms and conditions of their part of the contract. This process

has to continue (without any limit defined on the number of attempts) until suitable and capable winners are

found.

We can maintain the above information in the version trees, by first making the following mappings:

Schema-version 1 = {S1,S2,S3,S4}

Schema-version 2 = {S1,S2,S3,S4,S5}

Mode-version 1 = Mode1

Mode-version2 = Mode2

Mode-version 3 = Mode3

Instance-version 1 = Instance1

Instance-version 2 = Instance2

Instance-version 3 = Instance3

Instance-version 4 = Instance4.

We can then store the following linkages among the version trees, thus:

Schema-version 1 à Mode-version 1 à {Instance-version 1, Instance-version 2}

Schema-version 1 à Mode-version 2 à Instance-version 3

Schema-version 2 à Mode-version 3 à Instance-version 4

7. Related Work

Our paper has explored two important research areas for B2B E-Commerce: integrating adaptive workflow

and agents, and adaptive agent conversations. As we have already stated in Section 1, we believe that our

work (i.e., [18] and this paper) is the first serious attempt to integrate adaptive workflow and agents.

7.1 Adaptive Agent Conversations

START S1 S3 S5 S1 END

Page 30 of 36

In the context of agent conversations, however, a lot of work has been done modeling conversations and

investigating conversation policies (see http://www.boeing.com/special/agents99/papers.html for a large

number of papers on conversation policies, too numerous to describe individually in detail here). However,

none of these papers tackles the problem of conversation adaptivity directly (although [21] does touch upon

it briefly). A 3-tier layered approach for modeling agent conversations and their related policies has also

been proposed in [19]. Our approach is similar to [19]; indeed our example in Section 6.5 is inspired by the

example provided in that paper. However, we provide a systematic way to manage adaptivity of multi-

agent conversations, which that paper lacks.

7.2 Adaptive Workflow

Adaptive workflow is an area of active research. In most adaptive workflow research, workflow adaptation

has been motivated by the need for exception handling when workflow failures are encountered [33]; in

particular, in [33], a knowledge-based approach to invoking the appropriate stored procedures for exception

handling is described. From our perspective, this is instance-level adaptation. Other research on adaptive

workflow, notably ADEPT [38], the work of Ellis and colleagues [35] and Aalst [37], have primarily

focused on the structural aspects of workflow graphs during adaptation. These are definitely invaluable

contributions to the area of adaptive workflow; indeed, we have leveraged from ADEPT in our workflow

adaptation algorithm in Section 3.2 where syntactic correctness is checked.

In our opinion, the most significant work on managing exceptions is to be found in [36]. This paper

describes how exceptions can be catalogued, stored and managed. Two main classes of exceptions are

identified – expected and unexpected. For unexpected exceptions, a language and template has been

developed for supporting dynamic modification of workflow schema. For expected exceptions, a rule-based

specification language has been developed; this language enables the definition of exceptional situations

and their handling. More details are available from

http://www.hpl.hp.com/personal/Fabio_Casati/docs/Fabtesi.zip.

Correctness issues for workflow management in general are discussed in [32]. In [31], the authors have

presented a novel architecture for ensuring safety and correctness properties during workflow adaptation. In

this architecture, the workflow change management function is modeled in a separate layer; in that layer a

Tracking Agent keeps track of all workflow changes and a Change Coordination Agent automates the

Page 31 of 36

workflow adaptation after ensuring that safety and correctness rules are satisfied. Our work differs in two

major respects from this. Firstly, we consider automated adaptation only for agent conversations; secondly,

for agent conversations our Workflow Definer (with the appropriate oversight from the Workflow

Administrator) plays the roles of both the Tracking and Change Coordination Agents.

8. Conclusions

In this paper we have presented an integrated approach for Adaptive Workflow and Agents, which is an

extension of [18]. Adaptive Workflow is implemented within each agent by means of a 3-tier workflow

architecture that we have previously developed [12]. This architecture is augmented with our later idea of

“flexible workflow support” [14], which provides user flexibility in defining, executing and adapting

workflow processes by classifying them into loose, medium and tight control levels. This augmented

architecture has been further enhanced by representing agent-oriented workflow as a combination of

“macro-workflow” (agent-enhanced workflow) and “micro-workflow” (conversations among the agents

representing individual workflow systems). We have also presented a similar (but different) conceptual

architecture for managing adaptivity of multi-agent conversations, where we have highlighted the different

way in which this has to be handled as opposed to adaptivity in “macro workflow”. Indeed, we believe that

this is the first serious attempt to rigorously categorize and model adaptivity in multi-agent conversations.

There are several opportunities for future work:

• Detailed Architecture Specification and Implementation – we have briefly described the main modules

of our 3-tier architecture, and the architecture itself needs to be implemented and experimentally

evaluated (especially with reference to how macro-workflow and conversation adaptation - including

version management and the actual adaptation protocols themselves - can be implemented in practice).

For this, we are investigating the use of the TupleSpaces approach [20, 34], since it is a very simple

and convenient method for implementing the asynchronous workflow and multi-agent coordination

that our architecture requires. Another important area of architectural research is to integrate our

AdaptAgent architecture with agent behavior models such as SmartAgent [39].

Schema adherence is another research topic that needs to be investigated; that is, how to automatically

determine if an instance "obeys" a schema? Research on workflow inheritance [29, 30] that attempts to

answer this question, needs to be leveraged to answer this question.

Page 32 of 36

More detailed research on Policies and Commitments (especially with respect to the tuples that are

used for maintaining conversation state information), and their relation to the Goals and Schema, is

also another important area for future research. We will be looking at this as our next research topic,

and we hope to leverage on the formal theory for agent conversations developed in [28].

Yet another important research issue is (semi-) automatic derivation of the appropriate adaptive

workflows and agent conversations to meet the goals specified in the Goal Specification Module. We

have made a minor beginning in [13], but much more work remains to be done in this area.

• Security and Trust Management – issues such as Security and Trust Management [8] become crucial in

multi-agent interactions, hence the Goal Specification Module functionality should be enhanced to

implement Security and Trust Management. Protocols for establishing trust among participating agents

also need to be developed and implemented, in a manner similar to that described in [40].

• Distributed Service Management – the Planning Tier should be augmented to implement distributed

Service Management of macro-workflows and multi-agent conversations, in a manner similar to that

described in [22].

• Agent Conversation Representation – in our paper we have not imposed any particular representation

(such as Petri Nets [19], FIPA-ACL [4], KQML [10] or Dooley Graphs [24]), preferring instead to

concentrate on the architectural aspects. Hence this is a fertile area for future research. Indeed, we plan

to integrate our work with the ongoing AgentCities work on agent conversation language description

[41].

9. Acknowledgments

The author wishes to thank Dr. Bernard Burg of Hewlett-Packard Laboratories for his useful feedback on

[18], on which this paper is based. The author also wishes to thank his manager, Srivatsa Krishnaswamy,

and the ESTC Center Manager, Padma Ravichander, for supporting his work.

10. References

[1] J.L. Austin, How to Do Things With Words, Oxford University Press: Oxford, England, 1962. J.O.

Urmson, editor.

[2] Q. Chen, P. Chundi, U. Dayal and M. Hsu, "Dynamic Agents," International Journal of Cooperative

Information Systems, 1999

Page 33 of 36

[3] C. Dellarocas, “Contractual Agent Societies: Negotiated shared context and social control in open

multi-agent systems,” Workshop on Norms and Institutions in Multi-Agent Systems, 4th International

Conference on Multi-Agent Systems (Agents-2000), Barcelona, Spain, June 2000; also available from

http://ccs.mit.edu/dell/aa2000/paper13.pdf

[4] FIPA 2000 Specifications, available from http://www.fipa.org/specifications/index.html

[5] M.L. Griss, ""My Agent Will Call Your Agent … But Will It Respond?," Software Development

Magazine, 2000

[6] M. Kradolfer and A. Geppert, “Dynamic Workflow Schema Evolution based on Workflow Type

Versioning and Workflow Migration,” November 1998; available from

http://www.ifi.unizh.ch/dbtg/Projects/TRAMs/trams.html

[7] K. Whittingham, "OpenWater - White Paper", IBM Research Division, Zurich Research Laboratory,

1999

[8] A. Herzberg, Y. Mass, J. Mihaeli, D. Naor and Y. Ravid, “Access Control Meets Public Key

Infrastructure, Or: Assigning Roles to Strangers,” available from http://www.hrl.il.ibm.com/index.asp

[9] G. Kappel, S. Rausch-Schott and W. Retschitzegger, Coordination in Workflow Management Systems -

A Rule-based Approach, Springer LNCS 1364, 1998

[10] T. Finin, Y. Labrou and J. Mayfield, "KQML as an Agent Communication Language," in Software

Agents, Jeffrey Bradshaw (editor), AAAI/MIT Press, 1997; also available from

http://www.csee.umbc.edu/~jklabrou/publications/mitpress96.pdf

[11] OMG's MASIF (Mobile Agent System Interoperability Facilities) specification; available from

ftp://ftp.omg.org/pub/docs/orbos/98-03-09.pdf

[12] N.C. Narendra, "Adaptive Workflow Management: An Integrated Approach and System

Architecture," ACM Symposium on Applied Computing 2000

[13] N.C. Narendra, “Goal-based and Risk-based Creation of Adaptive Workflow Processes,” American

Association for Artificial Intelligence (AAAI) Spring Symposium 2000

[14] N.C. Narendra, “Flexible Support and Management of Adaptive Workflow Processes,” submitted to

Information Systems Frontiers, 2001

Page 34 of 36

[15] N.C. Narendra, “Flexible Agent Societies: Flexible Workflow Support for Agent Societies,”

Proceedings of CIMCA 2001

[16] N.C. Narendra, “An Integrated Security Infrastructure for Adaptive Workflow,” submitted to Journal

of Research and Practice in Information Technology, 2001

[17] N.C. Narendra, “Integrating Flexible Workflow and Multi-Agent Conversations in Flexible Agent

Societies,” Journal of Association for Information Systems, to appear

[18] N.C. Narendra, “AdaptAgent: Integrated Architecture for Adaptive Workflow and Agents,”

Proceedings of International Conference on Artificial Intelligence, Special Session on Agent-Oriented

Workflow Architecture for B2B, 2001

[19] M. Nowostawski, M. Purvis and S. Cranefield, "A Layered Approach for Modelling Agent

Conversations," Autonomous Agents 2001

[20] M. Nowostawski, M. Purvis and S. Cranefield, “Agent-Oriented Modelling for Complex Systems,”

available from http://marni.otago.ac.nz/~mariusz/papers.html

[21] L.R. Phillips and H.E. Link, "The Role of Conversation Policy in Carrying Out Agent Conversations,"

Proceedings of Workshop on Specifying and Implementing Conversation Policies, Autonomous Agents

'99; also available from http://www.boeing.com/special/agents99/sandia2.pdf

[22] A. Sahai, J. Ouyang, V. Machiraju and K. Wurster, “End-to-End E-service Transaction and

Conversation Management through Distributed Correlation”, HP Labs Technical Report HPL-2000-145,

also available from http://lib.hpl.hp.com/techpubs/2000/HPL-2000-145.pdf

[23] J.R. Searl, Speech Acts: An Essay in the Philosophy of Language, Cambridge University Press,

Cambridge, England, 1969.

[24] M.P. Singh, “Synthesizing Coordination Requirements for Heterogeneous Autonomous Agents,”

Autonomous Agents and Multi-Agent Systems. volume 3, number 2, June 2000, pages 107-132; also

available from http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/aamas-synthesis.pdf

[25] M.P. Singh, "An Ontology for Commitments in Multiagent Systems: Toward a

Unification of Normative Concepts,” Artificial Intelligence and Law, volume 7, 1999, pages 97--113; also

available from http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/ai+law-final.pdf

Page 35 of 36

[26] M. Wooldridge and N. R. Jennings, "Intelligent Agents: Theory and Practice," In Knowledge

Engineering Review 10(2), 1995; also available from http://www.csc.liv.ac.uk/~mjw/pubs/ker95.ps.gz

[27] The Zeus Agent Building Toolkit Home Page, available from

http://www.labs.bt.com/projects/agents/zeus/index.htm

[28] R. A. Flores and R. C. Kremer, "A Formal Theory for Agent Conversations for Action", available

from http://www.cpsc.ucalgary.ca/~robertof/publications/ci-acl/ci-acl2001Flores&Kremer.pdf

[29] W.M.P. van der Aalst and T. Basten, "Inheritance of Workflows: An approach to tackling problems

related to change," Computing Science Reports 99/06, Eindhoven University of Technology, Eindhoven,

1999; also available from http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p85.pdf

[30] C. Bussler, "Workflow Class Inheritance and Dynamic Workflow Class Binding," Proceedings of the

Workshop on Software Architectures for Business Process Management at the 11th Conference on

Advanced Information Systems Engineering CAiSE*99, Heidelberg, Germany, June 1999; also available

from http://hometown.aol.com/chbussler/

[31] P. Bose and M. G. Matthews, “Dynamic Change in Workflow-Based Coordination of Distributed

Services,” Proceedings of the 2001 International Workshop on Self-Adaptive Software, Balatonfüred,

Hungary, 2001.

[32] M. Kamath and K. Ramamritham, "Correctness Issues in Workflow Management," available from

http://citeseer.nj.nec.com/kamath97correctness.html

[33] Mark Klein, "A Knowledge-Based Approach to Handling Exceptions in Workflow Systems," Journal

of Computer-Supported Collaborative Work, Special Issue on Adaptive Workflow Systems, Vol. 9, No 3/4,

August 2000; also available from http://ccs.mit.edu/klein/papers/cscw-99.pdf

[34] G. Cabri, L. Leonardi, F. Zambonelli, "Auction-based Agent Negotiation via Programmable Tuple

Spaces," Proceedings of the 4th International Workshop on Cooperative Information Agents (CIA) 2000,

LNCS n. 1860, Boston (USA), July 2000; also available from

http://sirio.dsi.unimo.it/MOON/papers/cia00.pdf

[35] C. Ellis, K. Keddara, and G. Rozenberg, "Dynamic change within workflow systems," In N. Comstock

and C. Ellis, editors, Conference on Organizational Computing Systems, pages 10 - 21, ACM SIGOIS,

ACM, Aug 1995. Milpitas, CA.

Page 36 of 36

[36] F. Casati, M. Fugini, and I. Mirbel, "An Environment for Designing Exceptions in Workflows,"

Information Systems 24(3), pp. 255-273, 1999.

[37] W.M.P. van der Aalst and S. Jablonski, "Dealing with Workflow Change: Identification of Issues and

Solutions," International Journal of Computer Systems, Science, and Engineering, 15(5):267-276, 2000;

also available from http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p112.pdf

[38] M. Reichert and P. Dadam, “ADEPTflex – Supporting Dynamic Changes of Workflows Without

Loosing Control,” Technical Report No. 97-07, University of Ulm, Germany, April 1997; available from

http://www.informatik.uni-ulm.de/dbis/f&l/forschung/workflow/ftext-adapt_e.html

[39] M.L. Griss, S. Fonseca, D. Cowan and R. Kessler, “SmartAgent: Extending the JADE Agent Behavior

Model,” available from http://www.hpl.hp.com/techreports/2002/HPL-2002-18.html

[40] L. Kagal, T. Finin and A. Joshi, "Developing Secure Agent Systems Using Delegation Based Trust

Management," Security of Mobile MultiAgent Systems (SEMAS 02) held at Autonomous Agents and

MultiAgent Systems (AAMAS 02); also available from http://www.csee.umbc.edu/~lkagal1/papers/lkagal-

developingsecure.pdf

[41] S. Ambroszkiewicz, L. Rozwadoswki, D. Mikulowski, T. Nowak, K. Miodek, M. Kisiel-Dorohinicki

and K. Centarowicz, "Requirements for Service Description and Composition in AgentCities," preliminary

draft, 2002.