TÆMS Agents: Enabling Dynamic DistributedSupply Chain Management

Tom Wagner Valerie Guralnik John Phelps

Honeywell Laboratories, 3660 Technology Drive, MN65-2600, Minneapolis, MN 55418Tom.Wagner@honeywell.com

Abstract

Some dynamic supply chain problems are instances of a class of distributed optimizationproblems that TAEMS and other intelligent agents were made to address. In this paperwe define a sanitized version of a discrete distributed dynamic supply chain managementproblem and specify how TAEMS agents, equipped with new coordination mechanisms,are being used to automate and manage the supply chain.

Key words: agent mediated electronic commerce, dynamic supply chain management,coordination, TÆMS agents.

1 Introduction

In general, the intelligent agent paradigm lends itself to distributed supply chainmanagement because members of a typical supply chain are loosely coupled inter-acting systems, i.e., raw material suppliers, shippers, manufacturers, can all be seenas agents. More strongly, agent technologies that perform resource and temporal co-ordination across heterogeneous agents, without assumptions of global knowledge,are directly applicable to certain classes of distributed supply chain managementproblems because such technologies can perform decision making, order and ma-terial flow, and production scheduling to meet deadlines / resource limitations. Ifsuch technologies operate online, in real-time, the agents can manage dynamic dis-tributed supply chain problems in which frequent and timely adjustments to the

�

Appears in the Journal on Electronic Commerce Research and Applications, 2003,Elsevier. Effort sponsored by Honeywell International under project number I10105BB4.Disclaimer: The views and conclusions contained herein are those of the authors and shouldnot be interpreted as necessarily representing the official policies or endorsements, eitherexpressed or implied, of Honeywell International.

Preprint submitted to Elsevier Science

flow of goods and production schedules are needed in order to leverage conditionsin the marketplace or to take advantage of opportunities as they arise. HoneywellLaboratories, part of Honeywell International, which is one of the five largest sup-ply chain management (SCM) providers

�

and is included in the Dow Jones Indus-trial Average, is examining this class of agent technologies for dynamic distributedsupply chain management. The business motivation for this work is discussed ingreater detail later.

In this paper we present the use of TÆMS [7,13] agent technologies, equippedwith new coordination mechanisms, on a sanitized version of a dynamic supplychain problem in the discrete manufacturing domain. In this application the agentswork to manage the production schedule and material flow of a small build-to-orderproduction line. The focus of this work is not on agent-based bidding schemesor price determination but is instead on reasoning about actual orders, productionschedules, and material flow as discrete orders. This research also does not makestrong assumptions about statistical characteristics of demand or product orders –the focus is not on setting up a steady state manufacturing schedule.

The example application used in this paper is that of manufacturing goods for theoutdoor recreational market sector – specifically backpacks and sleeping bags. Theactors in our example will include retailers and a fictitious manufacturer called“MountainMan.” Any resemblance to actual retailers or manufacturers in this sectoror other market sectors is purely coincidental. The example itself is based on areal world situation though the work presented here is simulated and the problemspecification should be viewed as an educated assessment of a real world situation.

It is important to emphasize that the focus of this work is on the distributed op-timization problem that occurs when agents have multiple interacting activitiesand the activities have individual deadlines and individual resource constraints –is not on negotiation protocols or market mechanisms. Even if we could build asingle centralized representation

�

of the task coordination space, the hybrid plan-ning/scheduling (with interacting time limits, interacting resource constraints, andutility interactions) problem is intractable for any but toy problems. In this setting,provably optimal solutions generally require exhaustive search. Now consider whathappens when the problem space is distributed and put into a dynamic setting. Itis this space in which we operate. Complete discussion is beyond the scope of thepaper – the point is to understand that a large class of supply chain managementproblems fall into this very difficult problem space that has more in common withdistributed scheduling than it does with market mechanisms or research whose fo-cus is on communication protocols. Note that such other technologies are relevant

�

Per an independent market survey.�

In the commercial setting centralized models are not encouraged because it would requirereleasing competitive data to a 3rd party for planning and optimization – where said 3rdparty is not a disinterested party.

2

in this space, e.g., to determine the prices for goods which may interplay with theissue of temporal negotiation or to structure the negotiation protocols themselves,but that our focus is on the distributed scheduling aspects.

In this paper we examine the production scheduling problem of a small volumemanufacturing line that produces build to order goods for private label customers.The line is managed by an agent that interacts with other agents that represent re-tailers. The retailer agents, raw material supplier agents, etc., all potentially need tosolve the same class of problem as the manufacturing agent – we focus primarily onthe small volume production line for simplicity and clarity. As shown in Figure 1the small volume production line is an off-shoot from the primary production lineof MountainMan. Generally with private label production a large order is producedvia the primary production line and subsequent smaller orders, which are causedby unanticipated demand or customized variants of the goods, are routed to thesmaller production line. The small volume production line supports small privatelabel jobs, such as orders generated by unanticipated sales, that would interrupt theflow of the primary production line if scheduled for that line. This is particularlytrue for custom variants or restocking orders in part because such orders are smallbut still require different fabric, fasteners, etc., but also because such orders gener-ally have short term deadlines. In other words, when a retailer requests a small vol-ume they generally want it in a few days rather than the period of weeks for whichprimary production line is geared. This type of production has different require-ments than the standard main stream production operations. While minimizing rawand finished goods inventories are important for all manufacturing processes, thisis particularly true for private label goods as the customer base is very limited (gen-erally just one) and often portions of the raw materials are specific to the privatelabel purchase. Additional requirements for the line include ending the day withthe “tables empty” (no work-in-progress), maintaining zero inventory on finishedgoods, and building products to order only.

In our implementation, agents are situated at each of the involved sites. For exam-ple, one agent is located at MountainMan and one agent is located at each retailer,shown in Figure 6. The MountainMan agent’s job is to interact with the retaileragents and to determine production schedules for the MountainMan small volumeproduction line accordingly. Note that the overall supply chain, shown in Figure 2,involves raw material flows, shippers, and distribution centers. In this paper wefocus on the problem of coordinating production to meet dynamic demand at theretailers. The general flow of events across the agents is that when inventory levelsfall below the specified threshold at a retailer, the retailer’s agent places orders withMountainMan for replacement goods. The MountainMan agent reasons about thenew order and how it relates to currently scheduled production in terms of tempo-ral constraints and overall value. It can then negotiate over delivery time with theretailer agent in order to optimize MountainMan’s mix of goods. The use of agentsfor this example is what enables the retailers and MountainMan to coordinate dy-

3

Cutting: Fabric Fill Webbing Padding

Sewing / Operators

Inspection & testing

Finished goods inventory

Tagging & bagging

Picking & shipping

Raw inventory

Fill batten creation

Stay bending

Fasteners

Embroidery

Zipper pre-sews

Production flow

Production flow

Production flow

Production flow

Sewing / Operators

Inspection & testing

Tagging & bagging

Shipping

Cutting & Fabric

Build to Order Line

Primary Lines

Fig. 1. Primary and the Build-to-Order Production Lines

namically and automatically to optimize their activities.�

Figure 3 shows a screen snapshot of the MountainMan production line and theJJBoom store front at which customers can purchase goods. The two task struc-tures shown are of (center screen) the global task structure (or portions of it) for allagents as seen by the simulation environment, and (to the right) the task structureof the MountainMan agent. Note the difference between the two. The busy centralrepresentation is the problem that is being solved and optimized by the individualagents, each of which can only see and reason with a small portion of the totalspace.

�

The issue of what criteria over which to optimize is deliberately unspecified. If we as-sume that MountainMan and the retailers have no direct relationship then MountainMan’sgoal is to optimize over its own local criteria. In general this is simply to maximize profit butother secondary items might be to keep the line fully utilized or to use particular machineson a regular basis. For this example the exact optimization criteria is unimportant becauseall of these aforementioned issues can be mapped into the TÆMS quality attribute overwhich the MountainMan agent optimizes. Subsequent sections contain more informationon TÆMS and TÆMS agents.

4

Raw Material Suppliers Shippers

Distribution Centers Sample Retailers

3M

Dupont

YKK

Albany Intl.

Mountain Man

Yellow Freight

UPS

FedEx

Airborne Express

FedEx Ground

Shippers

Yellow Freight

UPS

FedEx

Airborne Express

FedEx Ground

Bemis Mountain

Sports

JJBoom

JC Dime Bemis

Mountain Sports - 1

JJBoom

Mountain Goat Buck

Trading Post

Camplots

JC Dime

Sierra Trading

Post

Bemis Mountain Sports - n

Chain Stores

Individual Retailers

BEI

Shipments may bypass distribution centers.

Fig. 2. MountainMan’s Overall Supply Chain

In the next section we provide a high-level view of TÆMS agents and TÆMStechnologies. In the section after that we return to the details of the application andillustrate the use of TÆMS agents for managing MountainMan’s dynamic supplychain problem. We then discuss chains of interactions and identify selected relatedwork, discuss limitations, experimental plans, and future work.

2 TÆMS Agents for Dynamic Supply Chain Management

We use the expression TÆMS agents to describe our agent technology because thecornerstone of our approach is a modeling language called TÆMS (Task AnalysisEnvironment Modeling and Simulation) [8,13]. TÆMS is a way to represent theactivities of a problem solving agent – it is notable in that it explicitly representsalternative different ways to carry out tasks, it represents interactions between ac-tivities, it specifies resource use properties, and it quantifies all of these via discreteprobability distributions in terms of quality, cost, and duration. The end result isa language for representing activities that is expressive and has proven useful formany different domains including the BIG information gathering agent [14], theIntelligent Home project (IHome) [12], the DARPA ANTS real-time agent sensornetwork for vehicle tracking [20,10], distributed hospital patient scheduling [7],agent diagnosis [9], and others like distributed collaborative design, process con-trol, and agents for travel planning.

5

Fig. 3. Screen Image of The Production Line, Hypothetical Global Task Structure, Moun-tainMan’s Task Structure, and the JJBoom Retailer

Figure 4 shows a TÆMS task structure like that used by the MountainMan agentin this application. The structure is a hierarchical decomposition of a top levelgoal which is simply to Produce. The top level goal, or task, has two subtaskswhich are to Make Bags and Make Back Packs. Each of these tasks are de-composed into subtasks and finally into primitive actions. Note that most of theseare omitted from the figure for clarity. The details are shown for the Make BEIJasper pack task – it consists of four primitive actions that are picking zippersand fasteners, cutting the webbing, cutting the fabric, and sewing the pack. The interdependence of these tasks is modeled in TÆMS using an enables non-local-effect.The dotted edges (enablements) from tasks like cutting and picking to the sewingtasks indicate that these tasks must be performed first and be performed success-fully for the sewing task to be performed. Note that all of the primitive actions(leaf nodes) also have Q (quality), C (cost), and D (duration) discrete probabilitydistributions associated with them. For simplicity in this paper we do not use un-certainty and all values will have a density of 100%. Picking the zippers thus takes10 minutes (.16 hours) and generates a quality of one. Cutting the webbing has asimilar allocation while cutting the fabric takes longer (1/2 an hour) and producesa higher quality (four). Sewing the packs takes over an hour and also produces ahigher quality (four). The sum() function under the Make BEI Japser taskis called a quality-accumulation-function or qaf. It describes how quality (akin toutility) generated at the leaf nodes relates to the performance of the parent node. Inthis case we sum the resultant qualities of the subtasks – note that the cutting of thefabric and the sewing operations dominate how well the bags are made in this ap-plication. Quality is a deliberately abstract concept into which other attributes may

6

be mapped. In this paper we will assume that quality is a function of the amount ofprofit generated by the production of a given good.

In the sample task structure there is also an element of choice – this is a strongpart of the TÆMS construct and important for dynamic supply chains. The MakeBack Packs task, for example, has two subtasks joined under the sum() qaf.In this case the MountainMan agent may perform either subtask or it may performboth depending on what activities it has time for and their respective values. Theexplicit representation of choice – a choice that is quantified by those discrete prob-ability distributions attached to the leaf nodes – is how TÆMS agents make contextdependent decisions. In supply chain applications this is how the MountainManagent sees that it has a choice of which products to produce and when.

Produce

Make Bags Make Back Packs

Make JJBoom 3 Season

Make BEI Jasp e r

Q: (100% 4) D: (100% 1.18 h)

Make KMS Sequoia

Sum()

Sum() Sum()

Cut Fabric

Pick Zippers & Fasteners

Cut Webbing

Sew Pack

enables

enables

enables

Sum()

Q: (100% 4) D: (100% .5 h)

Q: (100% 1) D: (100% .16 h)

Q: (100% 1) D: (100% .16 h)

….. …..

Fig. 4. Sample TÆMS Task Structure for a Manufacturing Agent

By establishing a domain independent language (TÆMS) for representing agent ac-tivity, we have been able to design and build a core set of agent construction compo-nents and reuse them on a variety of different applications (mentioned above, e.g.,[14,12,20,10,7]). TÆMS agents are created by bundling our reusable technologieswith a domain specific component, generally called a domain problem solver, thatis responsible for knowing and encapsulating the details of a particular applicationdomain. In the BIG information gathering agent, for instance, the domain problemsolver is a blackboard planner that knows how to model software products, buildmodels of products from raw text data, and compare/recommend products to pur-chase. In another application the domain problem solver may be a process plan ora legacy database application. In each of these cases we abstract away from the

7

details of the domain by creating a custom mapping function that translates theinternals of the domain problem solver into TÆMS task structures that are thenoperated on by the rest of the system.

For this paper it is sufficient to know that TÆMS agents have components forscheduling and coordination that enable them to 1) reason about what they shouldbe doing and when, 2) reason about the relative value of activities, 3) reason abouttemporal and resource constraints, and 4) reason about interactions between activ-ities being carried out by different agents. A high-level view of a TÆMS agent isshown in Figure 5; everything except for the domain problem solver is reusablecode. Note that each module is a research topic in its own right. The agent sched-uler is the Design-to-Criteria [16,21,23] scheduler and the coordination module isderived from GPGP [7]. Other modules, e.g., learning, can be added to this archi-tecture in a similar plug and play fashion.

In the supply chain application there are two types of domain problem solvers, thosethat manage the retailers’ inventories and the MountainMan agent that managesMountainMan’s production. The retailer problem solvers are of similar construc-tion. Their function is to monitor purchasing activities and check inventory levelswhen purchases are made. If a good falls below a specified threshold, they reorderand negotiate with the MountainManagent to determine delivery times/dates. TheMountainMandomain problem solver is different an instead reasons about Moun-tainMan’s production. It creates new candidate runs for new orders as they come inand remove jobs from the list of candidates if orders are canceled.

Domain Problem Solver

Design-to-Criteria Agent Scheduler

HL-GPGP Agent

Coordination Module

TAEMS Task

Structure Database

Interface to Real World

Views agent’s process via TAEMS models. Reasons about options, deadlines,

resource limits, etc.

Interacts with the coordination modules of other agents.

Creates constraints for the scheduler to coordinate

activity and directs the agent’s optimization process.

TAEMS Agent

Fig. 5. A Single TÆMS-based Agent Ready to Coordinate Its Activities With Other Agents

8

Retailer: BEI

Retailer: KMS

Retailer: JJBoom

Domain Problem Solver

Design-to- Criteria Agent

Scheduler

HL-GPGP Agent

Coordination Module

TAEMS Task

Structure Database Interface to

Real World

TAEMS Agent

Domain Problem Solver

Design-to- Criteria Agent

Scheduler

HL-GPGP Agent

Coordination Module

TAEMS Task

Structure Database

Interface to Real World

TAEMS Agent

Domain Problem Solver

Design-to- Criteria Agent

Scheduler

HL-GPGP Agent

Coordination Module

TAEMS Task

Structure Database Interface to

Real World

TAEMS Agent

Manufacturer: MountainMan

Domain Problem Solver

Design-to- Criteria Agent

Scheduler

HL-GPGP Agent

Coordination Module

TAEMS Task

Structure Database Interface to

Real World

TAEMS Agent

Agent to agent interaction.

Orders placed, negotiation,

commitments to produce & ship, etc.

Agent to agent

interaction. Orders placed,

negotiation, commitments to produce &

ship, etc.

Agent to agent interaction.

Orders placed, negotiation,

commitments to produce & ship, etc.

Fig. 6. Each Company Has Its Own Agent That Manages Its Local Interests

3 Dynamic Supply Chain Example

As mentioned in this example each retailer has a TÆMS agent that manages its lo-cal interests and orders products when appropriate. MountainMan also has an agentthat interacts with the retailer agents, responds to order requests, negotiates deliv-ery times, and manages MountainMan’s production.

�

In this paper we focus on asubset of the supply problem and do not address interacting directly with shippersor raw material suppliers. Work involving chains of interactions is discussed later.The agent network is shown in Figure 6. This example has specific properties, re-

�

The actual computation about which items to produce and when is performed by theDTC [16,21,23] TÆMS agent scheduler.

9

quirements, and assumptions that frame the problem. A subset of the more notableones are:

� Production is a single shift and scheduled from 8am to 4pm. However, the supplymanagement agents operate both day and night and adjust production schedulesas necessary.

� All goods are shipped over night via an express carrier.� Raw materials are always sufficient to support production.� Orders may arrive at any time day or night.� Retailers order goods in lots.� No WIP (work in progress) is left on the tables at the end of the day.� Orders are not interruptible once they have begun.� The TÆMS quality associated with production tasks is a function of the margins

produced by different products.� Production activities will be modeled as primitive actions in TÆMS at the grain-

size of Make Product X.�

� All customers are equally valuable. If this were not the case, it too could bemapped into TÆMS quality associated with the production tasks.

� When orders arrive they have a desired delivery date/deadline (that is specifiedby the retailer agents).

� Production specifics: sleeping bag lots require four production hours, backpacksrequire two hours per lot.

� All TÆMS distributions are 100% certain (single valued functions).

To illustrate, let the current simulated world time be 10am. MountainMan’s TÆMStask structure, which describes MountainMan’s current production options and re-quirements at 10am, is shown in Figure 7. MountainMan’s current schedule is alsoshown in the figure. In the task structure MountainMan has two orders – one forJJBoom 3 Season sleeping bags and one for BEI Jasper backpacks. (A dif-ferent TÆMS task is associated with each order.) The JJBoom lot has a higherexpected quality because the margins are better on the JJBoom product than theyare with the BEI Jasper. However, the JJBoom sleeping bags take longer toproduce than the BEI Jasper backpacks. If the MountainMan agent were opti-mizing over the quality/duration ratio rather than maximizing quality, and the twoorders were mutually exclusive, the agent would choose the BEI Jasper runover the JJBoom sleeping bag run. In this case as both the orders can be satis-fied and the agent is maximizing total quality both production runs are scheduledand both orders are set to be filled. MountainMan is currently two hours into theJJBoom sleeping bag production run and is planning to produce BEI Jasperbackpacks after the sleeping bag run (at 2pm).

�

This is sufficient for scheduling and selection in this example. The focus is on the in-teraction across agents – the more detailed MountainMan job shop scheduling problem isaddressable with the TÆMS technology and other well defined techniques.

10

At 12pm, when MountainMan is two hours into the JJBoom sleeping bag pro-duction run, a new order arrives. It is for the very high profit KMS Sequoiabackpacks. The arrival of the new order causes the domain problem solver forthe MountainMan agent to produce a new candidate production task, Make KMSSequoia, associated with the order as shown in Figure 8. The new order has adesired delivery date for the subsequent day. Because the production schedule fortoday is full, the MountainMan agent must either negotiate with the KMS retailerthat placed the order or find some other way to produce the desired goods. Note thatat this time (12pm) the BEI Jasper packs are scheduled for production at 2pm.Thus the MountainMan agent actually has four possible choices: 1) it can reject theKMS Sequoia order because production is full for the current day, 2) it can rejectthe existing BEI Jasper order and do the KMS Sequoia run instead, 3) it cannegotiate with the KMS retailer agent to obtain a delivery deadline that it can meetmore easily, 4) it can negotiate with the BEI retailer agent to obtain a later deliverydate for that order.

In this case we assume that KMS orders are generally non-negotiable and theMountainMan agent considers rescheduling accordingly. Upon consideration theagent itself detects that the KMS Sequoia order can be filled and that it shouldbump the BEI Jasper because the KMS Sequoia production run is more prof-itable. (This analysis is performed by the TÆMS Design-to-Criteria agent sched-uler.) In making this determination the agent could reason about the cost of decom-mitment for the existing order and compare said cost to the higher value associatedwith the new order. In this example decommitment cost is not used. Given thehigher value of the new order, the agent reschedules as shown in Figure 9. Whenthe agent reschedules it sends the BEI retailer agent a decommitment message thatindicates the BEI order will not be filled as expected. Note that the JJBoom run thatis currently in production proceeds uninterrupted. If runs were interruptible (theyare not – see the assumptions above) the agent would consider aborting the currentrun and could even evaluate taking the run off the line at some cost (overhead) andputting it back on during a future time when the line was idle or constraints morerelaxed.

In response to the notice that MountainMan will not fulfill its order the BEI retaileragent examines its own local TÆMS task structure (not shown) and because thereare no other orders that are competing for financial resources (shelf space could beconsidered here also) it re-issues its order with a later delivery date. The Mountain-Man agent reschedules again, as shown in Figure 10, and decides to 1) completethe JJBoom run (as it should given the requirements above), 2) then do the KMSSequoia production run, 3) and then tomorrow (at 8am) to do the BEI Jasperrun.

This small example illustrates an important class of capabilities for dynamicallymanaging a supply chain. First it shows autonomously making a quantified choicebetween candidate activities as the situation changes. On a given day there could be

11

Produce

Make Bags Make Back Packs

Make JJBoom 3 Season

Make BEI Jasp e r

Q: (100% 12) D: (100% 4 h)

Q: (100% 10) D: (100% 2 h)

Make JJBoom 3 Season Make BEI

Jasper

10 am 2 pm 4 pm

Sum()

Sum() Sum()

Fig. 7. MountainMan’s TÆMS Task Structure and Associated Schedule at 10AM

Produce

Make Bags Make Back Packs

Make JJBoom 3 Season

Make BEI Jasp e r

Q: (100% 12) D: (100% 4 h)

Q: (100% 10) D: (100% 2 h)

Make KMS Sequoia

Q: (100% 24) D: (100% 2 h)

Sum()

Sum() Sum()

Fig. 8. MountainMan’s Modified TÆMS Task Structure Reflects the New Order

Make JJBoom 3 Season Make KMS

Sequoia

10 am 2 pm 4 pm 12 pm

Fig. 9. MountainMan’s Production Schedule Modified to Leverage the New Order

many such events and many such exchanges. Automating some or all of this pro-cess enables the aggregate system to optimize continuously to improve efficiency,lower costs, maximize profit, or whatever the objective criteria is appropriate. Thisexample also illustrates how intelligent agent technology that incorporates tempo-ral reasoning maps to supply chain problems where deadlines (delivery times) andother related constraints are present. The example also identifies many areas whereapplication specific sophistication can be added. For instance the agents could en-

12

Make JJBoom 3 Season Make KMS

Sequoia

10 am 2 pm 4 pm 12 pm

Make BEI Jasper

8 am 10 am

Fig. 10. MountainMan’s Production Schedule is Revised Again to Support the KMS Orderand the Revised BEI Order

gage in a complex negotiation process to determine appropriate delivery times orcould predetermine a price for decommitment (failing to fulfill an order after aguarantee has been given) that would be considered by the MountainMan agentbefore a decommitment action was taken.

Note that the key properties of the supply chain problem space represented here isthat control is distributed and the situation is dynamic as the orders are driven by ac-tual consumer demand and not by estimates that are computed a priori. Other sup-ply chain problems that map directly to this space include automatically changingproduction schedules to take advantage of spot market materials where the suppli-ers are represented by agents or shifting activities at both the manufacturer and theretailer to adapt to changes in shipping times or even a shipper going on strike. An-other mapping is automatically modifying production to take advantage of changesin the marketplace as communicated by other agents, e.g., new customers, a changein product mix, a change in the product design itself, etc. In general by adding dy-namic control to the problem space the entire supply chain becomes more flexibleand potentially more efficient. Note also that the use of agents at all of the involvedparties is what produces the increase in flexibility – because the agents automati-cally negotiate over time, and potentially quality and costs, and because they com-municate and convey information as it happens, they converge on an optimizationacross the network of interested parties. With respect to control of actual businessprocesses, particularly when large dollar figures are involved, the agents can fill asupport/advisory role and still leave the ultimate decision making capabilities witha trusted human.

4 Chains of Enablement

In the previous example we discussed a coordination episode between retailer agentsand a manufacturing agent. Consider if the same problem is expanded to includeraw and intermediate material suppliers who ship to the manufacturer in responseto the order placed by the retailer. In a conventional setting, most if not all of thesuppliers will maintain an inventory of raw materials and will simply ship as neededfrom the inventory (scheduling production to generate more inventory as needed).However, in our problem space the raw material suppliers are running with a set ofrequirements akin to those of MountainMan in the previous example – everythingis build to order (or the inventory levels are so small as to have the same effect).

13

Produce

Make Products Class X

Make Other

Make Product X

Quality: (100% ..) Duration: (100% ..) Cost: (100% ..) Deadline: D - X

Sum()

Sum()

Sum()

Restock

Restock Goods Class X

Restock Other...

Sum()

Sum()

Sum()

Restock Product X

Enables()

Manufacturer Retailer

Quality: (100% ..) Duration: (100% ..) Cost: (100% ..) Deadline: D

Produce

Make Products Class X

Make Other

Make Component X[0]

Quality: (100% ..) Duration: (100% ..) Cost: (100% ..) Deadline: D - X - Y

Sum()

Sum()

Sum()

Enables()

Manufacturer Produce

Make Products Class X

Make Other

Make Component X[1]

Quality: (100% ..) Duration: (100% ..) Cost: (100% ..) Deadline: D - X - Y

Sum()

Sum()

Sum()

Manufacturer

Enables()

Fig. 11. Chains of Interactions Where Tasks Only Have Value if Chain is Completed

The implications of this are not obvious. If everything that is produced along an en-tire chain is custom (for only one possible customer) and no inventories are main-tained, it means that if the retailer cancels the order while it is in the process ofbeing filled, those who have produced goods for said order lose money. Figure 11sketches the situation. Each production activity only has value if the retailer com-pletes its purchase of the finished good.

For coordination the implications are pronounced. GPGP coordination is, in gen-eral, a peer-to-peer coordination technology that operates through pairwise dialogs.(The rationale for this is beyond the scope of the paper.) If a pairwise process is usedto coordinate over any chain (not just those that have the very unusual property justdescribed) it may take many iterations back and forth across the chain to resolveall of the temporal interactions and converge on a solution that works throughoutthe chain. If one adds the characteristic that each activity only has value if the en-tire chain is performed from start to finish, the agent must conceptually wait untilthe entire chain has solidified (or converged) before beginning production. This“global” commitment is very different than a conventional GPGP style commit-ment – it has more in common with a commitment to a particular course of actionregardless of the actual temporal bindings as described in [4].

To address the chains of interactions, where tasks along the supply chain only havevalue if the retailer purchases the product, we have created a new distributed coor-dination algorithm that uses commitment value and decommitment cost to achieveglobal coherence across the chain. The pseudo-code details of part of the algorithmare presented later (Figure 16), however, the conceptual framework is straightfor-ward. Consider the task structure shown in Figure 12. Agent A’s task A1 enablesagent B’s task B1, which enables agent C’s task C1, which enables agent D’s taskD1. Think of agent D as being a manufacturer who sells to end users and of agentsA-C as being a chain of raw material suppliers. In order for agent D to perform D1,

14

Fig. 12. Generic TÆMS Chain of Interdependent Tasks

agent A must perform A1 and all the other intermediate tasks must also be executedby their respective agents.

What is unique to the dynamic supply chain problem, particularly if zero invento-ries are maintained and the goods in question are private label or custom, is that ifthe sub-chain from A1 to C1 is performed but agent D decides not to perform D1,the goods produced along the sub-chain do not have any value to agent C and thus Cwill incur a loss. By the same token, if agent A decides not to perform A1, agents Band C will be unable to produce the goods desired by agent D and they may incur adecommitment penalty (D will also be unable to meet production plans/schedules).Recall that the focus of this work is on the temporal distributed coordination classof issues. Technologies like auctions or market mechanisms for determining pricecan provide the quantitative values used during coordination.

To enable the agents to commit to a course of action without being at undo risk forloss due to another agent not adhering to the course of action, coordination mustconceptually commit all the agents to a given course of action at one moment intime. Along with this commitment must come some specified value for decommit-ting or breaking the pledge and some specified value for satisfying the commitmentand producing goods as promised. Because the agents are distributed, obtaining therequired commitment and agreement must be performed in a distributed fashion.The general approach is for each agent to reserve a spot in production for the de-sired good while the chain is being negotiated. For example, agent D would reservea future spot for D1 in its production schedule but not begin work on D1 until thecoordination session is complete (a brief period in terms of wall clock time). Thisstep of the process is shown in Figure 13. The reservation process is part of theactivity carried out in the triangular box labeled DP D1 – this is the first decisionpoint for agent D. During this period, agent D decides when it needs to produce D1to fill its needs and then reserves that slot in its production schedule. Associatedwith the reservation spot is a model of the value or utility that it will obtain forperforming D1. This value is necessary – it enables agent D to reason about otheropportunities that may arise while it is negotiating the formation of the chain ofcommitments with the other agents. After reserving the slot for D1, agent D thendetermines when it needs goods from agent C and communicates this need/order toagent C.

15

Fig. 13. Coordination Over the Chain – Step 1

In Figure 14 the process continues. Agent C receives D’s request and determineswhen it can perform C1. If it cannot perform C1 to meet D’s needs, agent C informsagent D of this and the two may then renegotiate or agent D can unreserve the slotallocated to D1 (this part of the protocol / reasoning process is not shown in thefigure). Assuming agent C can schedule C1 to meet the needs of agent D, i.e.,produce the desired good by the desired time, agent C will reserve a slot for C1but not begin C1. It will then determine when it needs the inputs to C1, includingthe output of B1, and communicate these needs to agent B as an order with anassociated deadline. Agent B then performs a similar process, communicates anorder to agent A, and then the algorithm enters a new phase.

At this point in time, the agents all have reserved times for their respective tasksand associated values with them. During the next phase, shown in Figure 15, theagents send back commitment messages. For example, agent A informs B that itis committed to performing A1 and informs B of when the desired goods will beavailable for use in B1. When the commitment message chain reaches agent D, itthen back propagates a confirmation message and moves D1 from reserved status to

Fig. 14. Coordination Over the Chain – Step 2

16

Fig. 15. Coordination Over the Chain – All Steps

performable status. The other agents follow suit upon receipt of their confirmationmessages.

This process is depicted algorithmically in Figure 16. The algorithm is presentedfrom the perspective of agent B and the top-level function, CommitmentRe-questReceived(), is performed when agent B receives a commitment requestfrom agent C to perform B1 (so that C can perform C1). Support functions appeartoward the lower half of the figure.

�

The code contains partial variable bindings,e.g., fromAgent C, to simplify disambiguation. The general flow is that whenagent B receives a commitment request from C, it first checks to see if B1 is en-abled by another non-local activity, A1 (denoting that B1 needs raw material fromanother agent in order to be performed). If so, agent B first attempts to schedule B1to see if its constraints are feasible given B’s current schedule. Assuming that B1 is

�

The code presented implies a straight-line execution model. In practice, the agent doesnot block pending communications and the response handlers are called when appropriatemessages arrive. This enables the agents to perform multiple negotiation sessions and to beresponsive to change in the environment.

17

Fig. 16. Partial Sketch of Algorithm Performed by Agent B When a Request is Sent FromAgent C to Agent B to Obtain a Commitment for Task B1

18

feasible, agent B will then attempt to obtain a commitment from agent A to obtainthe necessary raw material. If/when it does so, it sends a corresponding commit-ment to agent C for the performance of B1. If agent B is unable to obtain a com-mitment from agent A, it must remove its temporary “what-if” scheduling of B1and send a message to agent C indicating that a commitment will not be forthcom-ing. The algorithm illustrates the interplay of commitment offering and schedulingfeasibility at a granularity finer than that of the preceding text. The algorithm doesnot, however, contain code pertaining to the negotiation between agents over tem-poral constraints (e.g., delivery deadlines) or task values. The former is generallyhandled by having the constrained agent send the requester a no-commitment mes-sage with a suggestion of a time frame that would be acceptable. The requester thenhas to evaluate locally whether or not the new time frame is acceptable. If so, thealgorithm presented in Figure 16 can be restarted with different temporal bindings.Value-based negotiation is not currently implemented in our framework though itcould follow a conventional propose-evaluate-counter model.

For clarity, the algorithm abstracts another important detail. The statement sched-uleTaems(B.whatIfTAEMS) encapsulates the process of 1) determining ifB1’s temporal constraints are feasible for agent B, and 2) determining if it is worth-while to perform B1 at all. This latter point comes into play if agent B has anothergood whose temporal constraints conflict with B1, i.e., if both it and B1 cannot beproduced. The point also comes into play if we consider opportunity cost in ourcomputation. To better illustrate the role of opportunity cost and decommitmentcost, consider what happens if, in the previous example, agent C receives a newopportunity and considers decommitting. Assume that the new opportunity is taskC2 and that C2 is mutually exclusive with C1 due to temporal constraints. Assumethat this opportunity arrives after C has committed to agent D to perform C1. Inthis situation, agent C must compare the value of performing C2 to the value ofperforming C1. Since agent C has committed to the chain including C1, it mustconsider several factors when assessing the value of C1, namely: 1) its quality orutility, which is tied to economic value, 2) its cost, and 3) the penalty for decommit-ting or decommitment cost. When assessing the value of C2 (before a commitmentis offered), agent C can simply consider its quality and cost. In our application, thecost for decommitment is a function of the qualities and costs of the methods thatcome before C1 in the supply chain – in this case a function of methods A1 andB1. This is because agent C’s decommitment results in agents A and B producinggoods that do not have market value outside of the context of C1. There is also arole for decommitment cost or a penalty being paid to agent D for D1’s opportu-nity cost – in this case it could be a function of D1’s quality minus its cost, i.e.,some percentage of a model of agent D’s profit for D1. We are currently evaluatingfair but more simple models of decommitment cost for this application. Tying allvalues to economics and using market mechanisms to set prices, or assuming thatprices reflected the market place, would simplify the computation. The focus of thiswork is more on supporting decommitment cost in the control reasoning and localscheduling of the agents.

19

While this example abstracts the process of determining decommitment cost it illus-trates the concept. Hereto unmentioned is the opportunity cost of reserving a timeslot for a candidate task while the coordination chain is being negotiated. Currently,this is not considered by the agents – at issue is whether agent D should reserve aslot for some task, e.g., D9, if D9 is not very profitable given D’s task history orgeneral margins. Reserving a slot for D9 means that while D is negotiating overthe chain it cannot reason appropriately about new tasks that arrive (which may beof higher value) if said tasks have temporal constraints that interact with D9. Thisproblem only occurs while a chain is being propagated. Once it is confirmed, Dcan reason about decommitting from D9 and respond to new opportunities. Thishas not been addressed because the coordination episode is generally regarded astaking on the order of seconds. However, if the coordination process involved hu-man operators so that the time window could expand to days, the framework wouldhave to incorporate the value of that reserved time slot and trade that off againstnew opportunities.

5 Abstract Formalization

Supply chain problems have many forms. In this paper, discuss a specialized ver-sion appropriate for discrete supply chains that have particular characteristics, e.g.,zero inventory, build to order, and those combined with production scheduling.From an abstract view, one formalization of the problem is as a 6-tuple

���������������� ������,

where

��

is a set of agents.��

is a set of tasks.��

is a mapping from tasks in�

to utility values.�

is a mapping from tasks in�

to deadlines.�

is a mapping from tasks in�

to agents that may perform those tasks in�

.��

is a partial ordering on�

.

The problem is to attempt to choose and assign each task, ����� �, to an agent,��� � �

, such that the partial ordering specified in�

, the task deadlines, ���� ,

and the assignment mapping, ��������� � � �!� � � are satisfied and the utility, "#�$� �

associated with the associated tasks is maximized. This is an optimization prob-lem (not a satisfaction problem) thus different tasks have different values and it isentirely possible to have unsatisfiable temporal constraints in a given problem in-stance. Note also the role of utility – agents in this supply chain choose betweencandidate orders based on utility while considering temporal constraints. Hidden bythis abstraction is the concept that utilities are dependent on the partial orderings�

. In the previous section we discussed chains of enablement and the characteristicthat in a build to order supply chain the involved parties need the transaction tohappen start-to-finish in order to avoid loss in the middle of the chain.

20

6 Related Work

Huhns et al [11] implemented several methods to automate the construction ofagent-based supply chains by translating UML diagrams and Business Object Doc-uments (BODs) into state machines that model the conversations necessary for sup-ply chain management and that can be then wrapped in agents. (Figure 7 in theirpaper shows their process well.) Their work differs in that they are not solving theproblem of how agents decide which requests to fulfill in a collaborative settingbeyond the protocol level. In our work there is a strong element of quantified andtemporal decision making or choice that is lacking from theirs. Note, however, thatsome of their ideas could be used to frame the communication process of our work.

The MASCOT [17] architecture for dynamic supply chain coordination uses black-board agents to create and manage supply chains. MASCOT differs from the workhere in its support of mixed-initiative functionalities that enable different humanusers at different levels in a supply problem to manipulate planning/schedulingactivities. MASCOT also differs in that it generates planning/scheduling optionsthrough a bid mechanism, i.e., considering different suppliers. In our work, con-straints are resolved by (aka “options are generated through”) coordination, schedul-ing, and negotiation. While our work focuses on temporal interactions between ac-tivities that span agents, that aspect of MASCOT is unclear, though the blackboardagents include a sophisticated scheduling module.

Leveled Commitment Contracting [18] is a means for handling backtracking searchin multi-agent systems. More specifically, it is a commitment instrument for capi-talizing on the possibilities provided by probabilistically known future events. In-stead of conditioning a contract on the occurrence of future events, as is the casewith contingency contracting, a decommitment penalty is built into the contractthat allows unilateral decommitting. We implement a form of leveled commitmentcontracting, albeit implicitly. In our casting of the supply chain problem, we tooprovide for decommitment cost, but it is precisely the quality gain on a commit-ment request, ex ante, and the quality posted on a satisfied commitment, ex post.The decommitment cost will always outweigh the quality gain from a commitmentif it is disadvantageous to the multi-agent system. This follows from the fact thatthe agents in the supply chain are fully cooperative and the quality for one com-mitment satisfaction is contingent upon all other commitments in an order chainbeing satisfied, i.e., quality gain for commitment satisfaction is monotonically in-creasing. This does not mean, however, that the ordering system is exempt fromthrashing without a synchronization procedure, but the sequential nature of an or-dering chain makes the implementation of such a procedure relatively easy. Whatis then required is end-to-end decision time guarantees.

Shen et al. [19] detail a general, domain independent, collaborative agent systemarchitecture which incorporates standard agent services such as ontology, yellow

21

pages, and centralized local coordination managers as well as the the notion of adynamic cooperation domain abstraction for groups of cooperating agents. Whilethis work identifies the importance of cooperation, it does not describe or imple-ment quantified choice / coordination technologies.

Zeng and Sycara [24] define a model that can be evaluated to identify efficientcombinations of supply-chain activities. The model consists of and/or task decom-position trees. Parts of a supply chain are represented by these nodes. These modelsare translated into problems for which decisions can be made following inventorytheory models. Said models do not appear to consider commit/decommit problems,or the explicit modeling of one tasks’ properties versus another. It is thus unclearhow flexible the system is – certainly it does not leverage quantified choice or se-lection.

Barbuceanu [1] gives a representation for tasks and constraints on the execution oftasks (behaviors) called a goal network. Obligations and interdictions in his frame-work roughly correspond to commitments (part of the TÆMS coordination pro-cess) or the facilitates/hinders interactions in TÆMS (not shown in Section 2 butrelated to TÆMS enablement). One agent’s authority over another is required to setan obligation. The author also describes a way reasoning about the representation,which is branch and bound, to find the right commitment for goals which optimizesthe utility of the task network.

Collins et al. [5] describe a MultiAgent NEgotion Testbed (MAGNET) which im-plements collaboration via an auction model. Agents which require services re-quest them via a task network that includes task descriptions and time constraints.Provider agents then send back bids with the tasks that they are willing to under-take, when they can do them, and at what price. A bid manager fills in a requestingagent’s task structure with an appropriate schedule from the bids by using eitheran integer programming or a simulated annealing evaluator. Their framework is notas rich as TAEMS, and they are not dealing with commit/decommit issues thoughthey are considering temporal constraints and a choice mechanism – features weconsider important.

Davidsson and Wernstedt [6] model just-in-time distribution networks and evalu-ate cooperative MAS for management of the networks. In this work the focus ison high-level formal modeling of the problem space and the implementation ofthe models in a simulation environment. The work does not focus on the discrete,temporally situated, and detailed dynamic supply chain and production schedulingproblem presented in this paper.

In general our work differs in the combination of factors it addresses. These tie backto TÆMS’ rich feature set, for instance: complex process representation, explicitquantified modeling of task and process interactions, explicit quantified existenceof alternative ways to perform tasks and quantified choice functions, combined with

22

various hard and soft temporal and resource constraints. Coupled with this is theexplicit effort of all of the TÆMS technologies to support dynamic adaptation tosituations as they evolve. Thus both the agent scheduling and coordination tech-nologies are designed not to rely on a priori or off-line computations and designedspecifically to always evaluate options from a qualified perspective.

7 Limitations, Experimental Plans, and Future Work

This paper describes TÆMS agent technology and shows its use on an imple-mented supply chain management problem. The technology used here currentlyhas a few limitations – some of which are being addressed and some of which arelarger issues. One limitation is that we do not coordinate over resources. The chainsof interactions described above and easily envisioned by raw-to-manufacturer-to-retailer chains are not actually chains from task-to-task but are chains from task-to-resource-to-task. In other words, MountainMan produces a good that is consumedby the retailer. If we modeled and coordinated over that good, rather than using taskinteractions, the system would automatically handle situations in which Mountain-Man had a requested good in inventory or lacked a raw material needed for pro-duction. Currently this functionality is partly implemented in the domain problemsolvers of the retailer agents and the MountainMan domain problem solver couldbe extended to provide this functionality as well, e.g., if goods in inven-tory, ship and charge (do not make new production task).Resource coordination of a different nature has been done before in TÆMS [12,10]and the explicit representation of the resources potentially introduces an additionallevel of flexibility and simplifies the construction of the domain problem solvers.

The larger issue that may not be obvious is that when control is decentralized in thisfashion, and the problem decomposition itself is not structured but instead evolves,this type of distributed optimization is not always guaranteed to be optimal. Whencan it fail? When the problem spaces get large it is occasionally difficult for theDesign-to-Criteria agent scheduler to produce an optimal solution. (The generalcase of the problem it solves is not computable – it uses approximation techniquesto make the space tractable and operate on-line in soft real time.) Another case inwhich it may not be optimal is when the constraints fall in a particular way – thepartial and distributed views held by the agents may not always contain enoughinformation for them to fully optimize. The generalization of this coordinated deci-sion problem has been shown to be exponential ( ����������� ������� ��� ) [15,2] whichis why in practice implementations that operate in real-time do not guarantee op-timality. With this potential for sub-optimality mentioned, it is also important torecognize that most human-centered business processes today are far from optimal.In this work we are seeking to improve efficiency and reduce costs – making gainsover the approaches currently used.

23

In most research there is always room for more rigorous empirical verification andthis work is no exception. Depending on level and thrust of corporate interest, wemay develop an optimal, exhaustive, centralized controller and compare the newprotocol for chains of enablement against the centralized oracle. Note that the pur-pose of this comparison is not to motivate a distributed approach – the need fordistribution is inherent in the privacy and autonomy issues – but to present a yard-stick against which the approximate TÆMS agent solution can be compared. Onan unrelated DARPA team coordination project, GPGP-derived coordination tech-nologies have compared favorably to an optimal centralized oracle [22] though theresults depend on the general character of the problem sets and the tightness of theconstraints.

8 Acknowledgments

We would like to acknowledge Professor Victor Lesser of the University of Mas-sachusetts for his collaboration in bringing portions of existing TÆMS technologiesto Honeywell Laboratories. While some of the key technologies used in this workare new, we started with a strong foundation. We would also like to acknowledgeMr. Bryan Horling, of the University of Massachusetts, for his technical assistancein porting aspects of the TÆMS technologies to Honeywell and for his support intheir use. TÆMS and TÆMS agents have a long history and we would like to ac-knowledge those many other researchers who have contributed to their growth andevolution – some of the individuals are Victor Lesser, Keith Decker, Alan Garvey,Tom Wagner, Bryan Horling, Regis Vincent, Ping Xuan, Shelley XQ. Zhang, AnitaRaja, Roger Mailler, and Norman Carver. We would also like to acknowledge thesupport of Mr. John Beane of Honeywell on this project.

References

[1] Mihai Barbucceanu. A negotiation shell. In Proceedings of the 3rd InternationalConference on Autonomous Agents, pages 348–349, 1999.

[2] D.S. Bernstein, S. Zilberstein, and N. Immerman. The complexity of decentralizedcontrol of MDPs. In The Sixteenth Conference on Uncertainty in Artificial Intelligence(UAI), pages 32–37, 2000.

[3] Craig Boutilier. Sequential optimality and coordination in multiagent systems. InIJCAI, pages 478–485, 1999.

[4] Cristiano Castelfranchi. Commitments: From individual intentions to groups andorganizations. In Proceedings of the First International Conference on Multi-AgentSystems (ICMAS95), pages 41–48, 1995.

24

[5] John Collins and Maria Gini. Exploring decision processes in multi-agent automatedcontracting. In Proceedings of the 5th International Conference on AutonomousAgents, pages 81–82, 2001.

[6] Paul Davidsson and Fredrik Wernstedt. Characterization and evaluation of just-in-timeproduction and distribution. In Working Notes of the AAMAS 2002 workshop on MASApplications and Problem Spaces, 2001. To appear in an edited collection in 2003.

[7] Keith Decker and Jinjiang Li. Coordinated hospital patient scheduling. In Proceedingsof the Third International Conference on Multi-Agent Systems (ICMAS98), pages 104–111, 1998.

[8] Keith S. Decker. Environment Centered Analysis and Design of CoordinationMechanisms. PhD thesis, University of Massachusetts, 1995.

[9] Bryan Horling, Brett Benyo, and Victor Lesser. Using self-diagnosis to adaptorganizational structures. In Proceedings of the Fifth International Conference onAutonomous Agents (Agents2001), 2001.

[10] Bryan Horling, Regis Vincent, Roger Mailler, Jiaying Shen, Raphen Becker, KyleRawlins, and Victor Lesser. Distributed sensor network for real-time tracking. InProceedings of Autonomous Agent 2001, 2001.

[11] Michael N. Huhns, Larry M. Stephens, and Nenad Ivezic. Automating supply chainmanagement. In To Appear in the Proceedings of the 6th International Conference onAutonomous Agents, 2002.

[12] Victor Lesser, Michael Atighetchi, Bryan Horling, Brett Benyo, Anita Raja, RegisVincent, Thomas Wagner, Ping Xuan, and Shelley XQ. Zhang. A Multi-AgentSystem for Intelligent Environment Control. In Proceedings of the Third InternationalConference on Autonomous Agents (Agents99), 1999.

[13] Victor Lesser, Bryan Horling, and et al. The TÆMS whitepaper / evolvingspecification. http://mas.cs.umass.edu/research/taems/white.

[14] Victor Lesser, Bryan Horling, Frank Klassner, Anita Raja, Thomas Wagner, andShelley XQ. Zhang. BIG: An agent for resource-bounded information gatheringand decision making. Artificial Intelligence, 118(1-2):197–244, May 2000. ElsevierScience Publishing.

[15] David Pynadath and Milind Tambe. Multiagent teamwork: Analyzing the optimalityand complexity of key theories and models. In 1st International Conference ofAutonomous Agents and Multi-Agent Systems, pages 873–880, 2002.

[16] Anita Raja, Victor Lesser, and Thomas Wagner. Toward Robust Agent Control in OpenEnvironments. In Proceedings of the Fourth International Conference on AutonomousAgents (Agents2000), 2000.

[17] Norman M. Sadeh, David W. Hildum, Dag Kjenstad, and Allen Tseng. MASCOT: AnAgent Based Architecture for Dynamic Supply Chain Creation and Coordination inthe Internet Economy. Production Planning and Control, 12(3), 2001.

25

[18] Tuomas Sandholm and Victor Lesser. Leveled commitment contracting: Abacktracking instrument for multiagent systems. In AI Magazine, pages 89–100.AAAI Press, 2002.

[19] W. Shen, M. Ulieru, D.H. Norrie, and R. Kremer. Implementing the internet enabledsupply chain through a collaborative agent system. In Proceedings of the 1999Autonomous Agents Workshop on Agent Based Decision Support for Managing theInternet Enabled Supply Chain, 1999.

[20] R. Vincent, B. Horling, V. Lesser, and T. Wagner. Implementing Soft Real-Time AgentControl. In Proceedings of Autonomous Agents (Agents-2001), 2001.

[21] Thomas Wagner, Alan Garvey, and Victor Lesser. Criteria-Directed Heuristic TaskScheduling. International Journal of Approximate Reasoning, Special Issue onScheduling, 19(1-2):91–118, 1998. A version also available as UMASS CS TR-97-59.

[22] Thomas Wagner, Valerie Guralnik, and John Phelps. A key-based coordinationalgorithm for dynamic readiness and repair service coordination. In Under Review,2002.

[23] Thomas Wagner and Victor Lesser. Design-to-Criteria Scheduling: Real-Time AgentControl. In Wagner/Rana, editor, Infrastructure for Agents, Multi-Agent Systems, andScalable Multi-Agent Systems, LNCS. Springer-Verlag, 2001. Also appears in the2000 AAAI Spring Symposium on Real-Time Systems and a version is available asUniversity of Massachusetts Computer Science Technical Report TR-99-58.

[24] D.D. Zeng and K. Sycara. Agent facilitated real-time flexible supply chain structuring.In Proceedings of the 1999 Autonomous Agents Workshop on Agent Based DecisionSupport for Managing the Internet Enabled Supply Chain, pages 21–28, 1999.

26