A Negotiation Enabling Agent Based Infrastructure: Composition and Behavior Nick Szirbik
[email protected] tel.: +31-40-247-4370, fax: +31-40-243-2612 Eindhoven University of Technology, Postbus 513, 5600 MB, The Netherlands
Abstract Software agent-based negotiation is a major method to automate the interactions in electronic marketplaces and Internet enabled communities. The traditional approach is to let the agents to interact directly. In this paper it has been investigated how a mediator agent can improve the chances to reach the agreement via bargaining. Although the ideal mathematical model was proposed in the seventies, this was never implemented as a working mechanism, due to the fact that the mediator needed information that was difficult to gather and the usual environment was not repetitive enough to consolidate this information for a fair mediation. The agent-based infrastructure proposed collects continuously data about the negotiating parties and the mediator agents use this data to reduce the exaggeration of the parties. The paper includes a mediation example and the major conclusion is that negotiation is improved by a mediator which has historical data about the negotiating parties. Key words: Multi-agent systems, Agent Provider, Mediated Negotiation, Virtual Enterprise
-1-
1 Introduction Software agents can change the way a user uses software packages [1]. An interesting and novel example is the use of specialized software agents in the Internet enabled auctions [2]. Usually, these business processes take place between individuals. Our imperatives are to study how this kind of “agent-oriented” intelligent interaction between individuals can be applied to automate the linkage of collaborating enterprises. Since majority of the collaborating enterprises will have some form of ERP (Enterprise Resource Planning) system to manage their internal resources, the relevant issues are the integration of respective ERP systems of collaborating enterprises, at various levels of hierarchy by means of intelligent agents. The goal of this paper is to present the conceptual architecture (at the composition level) and the behavioural patterns we used for the experimental agent-based PROVE system (Prototype system for automated Reasoning about Operations in a Virtual Enterprise). The “classical” approaches presented in the literature [3] use the agent as a wrapper of functionality of legacy systems, in order to achieve uniformity. Our approach is entirely different: the agents are in charge with tasks that are parts of processes crossing the boundaries between enterprises (i.e. inter-organizational processes). In order to remain de-coupled from the legacy systems, agents interact with these via a specialised infrastructure, the mobile agent dock. Such agents need not be owned by either party. Indeed, most probably they will be developed, managed and maintained by a third trusted party, which we term as the Software Agents Common Provider (SACP). These agents are mobile code which can be deployed by the SACP at the local docks. The paper is structured in the following way: section 2 gives a short description of our view about the definition of the virtual enterprise, section 3 presents aspects about agent-based systems dedicated to this kind of enterprises, section 4 presents the composition and some behavioural aspects of the system we envisage and experiment, section 5 presents the basic mechanisms of the mediated negotiation, section 6 shows an ideal case of mediation, section 7
-2-
presents in detail our approach to approach the goal presented in section 6 (fair mediation), section 8 presents an illustration of this approach, section 9 shows how and why mobility of agents is an useful asset in the system, and section 10 concludes the paper.
2 The Virtual Enterprise In a Virtual Enterprise (VE), short term goals impose a cooperative behaviour within a relatively closed society of self-interested actors (i.e. autonomous enterprises). These enterprises focus activities on their core competency, and tend to outsource the rest. There are a multitude of interpretations about what a Virtual Enterprise is. A good definition is: “A VE is a group of enterprises, which has the capability of realising in a collaborative manner, items or services from a limited portfolio of products.“ (see also [4] for arguments for this definition). A basic assumption is that there is a great level of pooling of materials, resources, and capacities. Such a set of enterprises can have a vague boundary. In order to clearly define the roles, we consider only those enterprises that are linked together by a specific communication framework running on an agreed infrastructure, which is often the Internet. Some authors (see [5] and [6] term such a collaborative group an e-Network or an Enterprise Web (E-Web/eWeb). When an eWeb has to execute a specific order or design a new product, only a subset of parties might participate in the process. We term this sub-group the eWeb Cluster. The way the parties will coalesce into eWeb Cluster will be opportunistic and based on the current context given by the distribution of available materials and capacities. When selecting partners, parties will also look at the previous performance indicators (trust, performance, etc.) of the potential partners. The resources used in a Cluster must be free at the time when needed. Kornelius [4] observes several concepts of free resources: - idle inventory - overcapacity policies, very popular now, because they increase flexibility and agility
-3-
- delayed or cancelled orders - order, process, and operation scheduling. The last is the most frequent source of free time-slots. Even the most skilled schedulers or advanced scheduling systems cannot completely fill the available time of the resources, due to batching, sequencing and especially dependency constraints. In terms of material resources, there is always a chance that in a huge eWeb, one can find slack, which can be equivalent to a free resource. There are three views in the formation of eWeb cluster (see figure 1): the hardware infrastructure view, the language view and the organisational view. Today, the hardware infrastructure view is dominated by the Internet and mobile communication means. From the language point of view, we have now EDI (Electronic Data Interchange) and more recently XML (Extended Markup Language, with various dialects, such as ebXML for e-business). The organisational view of the existing frameworks shows metaphors known as B2B (business to business), B2C (business to customer), e-markets, e-hubs, inter-enterprise APS (advanced planning system), and inter-organisational workflows, to mention only a few.
hardware view
languages and meta-languages
communication framework
organisational view (role, relations)
Figure 1. The views related to the communication framework
Recent trend is that the collaborating parties engage a third trusted party which is acting as an ICT service provider. For example, such providers are MyAircraft.com and Aeroxchange.com, enacted by common initiative of partners from the aerospace industry
-4-
and the airline sector respectively. This tendency, from an organisational view, is to change the “ad-hoc-archy” of the party interaction in cluster formation to a “hyperarchy”, where the ICT support infrastructure not only covers the communication and coordination aspects, but also keeps track of the repetitive interactions, monitors the performance, measures and stores values reflecting the level of trust. More than that, such an infrastructure imposes over the participating actors a kind of implicit regulatory mechanism, by adhering to mutually accepted norms. As a first step, to align the communication and coordination at the semantic level, common shared ontologies are needed, reflecting the specific culture of each eWeb.
3 Agent based systems for eWebs A powerful paradigm used especially in conceptual modelling and system analysis, but also in the design and implementation of IT infrastructures for eWebs is the agent paradigm with three principal research arenas: - languages, meta-languages (e.g FIPA, XML and derivative mark-up languages) - ontological engineering (e-catalogues, XML based ontologies) - structural design (agent-oriented design methods, frameworks and tools) These arenas partially cover the communication framework (Figure 1) especially the communication language aspect. Focus of this paper is on the organizational view, especially from a operational and process perspective. If a group of enterprises decides to adopt an agent-based solution for the ICT integration, without enacting a third party for this activity, they must agree in a very precise manner about the common specifications for the communication language to be used, and the common behavioural model of the agents. Each enterprise has to implement locally its wrapper software, according to the specifications. Additionally, the overall agent system must be tested, validated and updated when necessary. This scenario for the development of an agent-based
-5-
system illustrates clearly that such a process is an extremely difficult undertaking [7]. This is due to: - for a large group of enterprises, it is difficult to reach in a short time a common agreement about the specifications - it is hard to believe that all the enterprises have the necessary skilled people to implement the wrapping, or they are willing to pay for specialised help - testing such a huge system, without a centralised view, is almost impossible - each update will repeatedly require the common agreement of all the involved parties. These reasons explain for the lack of uptake in the fielded agent-based systems. The agent field of research enjoys today a lot of progress and energy, but there are still only a few real world everyday applications (see [8] and [9]), and none of these are for eWebs. This lack of applications is more surprising given the fact that the idea of using the agents in eWebs is not new (see [5]), the and research done in this field generated a lot of novel ideas (for surveys, see [10] and [11]). However, typical characteristics of these ideas is the “wrapper” agent paradigm. The agents are static and localized. Our view about how to develop an agent based system for IT integration in eWebs is different. We believe that the solution is to use mobile agents [12]. These are basically the same in their internal structure with the static agents, but they have a special feature: they can migrate from one computer to another and execute their code at different locations, by their own “will”. Because this implies a high degree of portability, mobile agents are usually coded in Java. The simplest example of a Java mobile “agent” can be the Java applet, a piece of software which is downloaded to the invoking computer and executed there. But a fully-fledged mobile agent must be able to autonomously migrate as opposed to being specifically invoked. If for running an applet one needs a Java enabled Internet browser, for allowing the mobile agents, one needs
-6-
a specialised software often called as a “mobile agent server”, “mobile agent dock” or “mobile agent platform”. Hence, an alternate scenario for the development for a eWeb agent-based integrator, opposed to the “wrapper-agent” philosophy, is to install docks at all the involved enterprises. The decision makers of the enterprises have to reach only the agreement about the type of the dock which will be adopted. To develop and manage agents and to provide security and maintenance for the whole system, the best approach is to rely on a third party, which is specialised in this kind of software development. We call this party the Software Agent Common Provider (SACP). The agents can be migrated (deployed) to the enterprises’ computers when they are needed, by providing an easy installation process. The testing and validation of the system is made by a single party (the SACP), which is in charge of the collection of the specifications and the execution of all upgrades. All member enterprises have to have mobile agent docks installed inside their IT support systems. We call such a group of enterprises a Mobile Agent web (MA-web). From the product ordering point of view, an MAweb of enterprises is able to deliver a specific portfolio of products. In this approach, the emphasis is not on the local functionality. When a customer order is issued, a subset of the MA-web commits to execute the order (a “target”), and we called this group a Target Cluster. It is assumed that more enterprises than necessary can participate to execute a specific order at a specific moment, due to the assumed redundancy, and a selection process is needed to establish the Target Cluster.
4 The composition of the eWeb mobile agent system The mobile-agent based architecture for a eWeb can be viewed as a network of docks (or sites). Each dock is related to a certain enterprise in the MA-Web. There is only one site which is different from the rest, namely the SACP. The particularity of this site is given by the
-7-
fact that only here agents can be created and deployed to other docks. When an agent is deployed at an enterprise site, it has to represent that enterprise fairly, and at the same time obey the rules of agent behavior. The overall role of a group of deployed agents is to support interorganizational business processes, which are taking place within the eWeb. In order to improve the performance of the system, several supplementary functions need to be added to the SACP site functionality: - to collect data about resources availability - to globally schedule some of the activities of the agents - detect exception events and support problem management. A discussion on these details can be found in [13] and [14]. In this approach, problem management is solved via agent-to-agent negotiations which follow a specific scheme that is presented later in the paper. The resource availability is recorded as a central database, which we called repository. The repository can be viewed as a Gantt chart (see figure 2), where all the foreseeable available time-slots for resources are stored. This repository is appropriate for manufacturing capacity, but can be used for materials. This Gantt chart is used for a ‘global scheduling’ (GS) activity. When a customer (they can be included as sites in the MA-Web) issues an order, the enterprise which is taking the order (we call it a eWeb “gate”) asks the SACP to create an agent. This agent will be dedicated for the complete execution of this order. The final product to be delivered is a Target, and it is linked to this agent, that has a Goal to realise the Target. The product is to be assembled using components from suppliers, who have to manufacture the parts or deliver from existing stocks. Each component is expressed as a resource type. Also, the assembly (and installation) process is viewed as a resource type. The agent at the gate knows the structure of the resource types needed, and invokes the Global Scheduler from the SACP site, sending a
-8-
message there, containing all the needed resource types and the dependency constraints between them.
horizon resources
.....
type 1
...... ..... type 2 ....... .....
type 3
.... and other types current moment
future
time
figure 2: The central repository data model
The Global Scheduler, using the data from the resource availability repository, generates a schedule to purchase, manufacture, assemble and delivery of the product. For each component and process, a free resource is assigned. Knowing the resource, establishes the enterprise that is offering it. This information is relayed back to the agent. The agent at the gate asks for the creation of a mobile agent for each resource present in the schedule, and these agents are sent to related enterprises. When an agent arrive there, it asks if necessary resources can be committed for its target, and the associated costs. If the response is positive, agent sends confirmatory message to its creator agent, and if creator agent at the gate agrees with the decision, central repository is informed and assignment confirmed and corresponding resources dedicated (blocked) for this target. Finally, a contract is signed with the customer, and a delivery date (generated by the GS) is established. As stated before, we consider in this scenario time to be more important than price, and no optimization takes place in terms of cost. It is possible to
-9-
keep in the central repository price information about the resources, and a more advanced scheduler can also generate a GS according to the financial criteria. This scenario has only one level of product decomposition. The usual case is multi-level. If so, each supplier becomes a new gate, and the process is repeated. The main problem here is that the delivery date for components can exceed the delivery date initially stated in the first GS. In this case, a re-schedule of the previous levels is needed and this could lead to many invocations of the global scheduler, process which can cascade out of control. Also, the contract cannot not to be signed before the decomposition has reached all lowest levels, and all enterprises in the Target Cluster. In this global schedule based scenario, it makes sense to analyse only the case of dispatching the mobile agents to the lowest level, in a single move, based on a single GS, which takes into account from the start, all components in a product, to the last detail. This implies that the gate site has to know the configuration of the product (the augmented BOM - bill of material, together with the processes linked to it). An alternative is to keep BOMs centrally, but this poses the problem of data consistency, because the SACP must be able to keep track of all the possible modification in the local BOMs. Further complications are raised by the necessity of customer parametrisation, as presented in [15]. A second scenario is to enact the Cluster via site-to-site negotiation. The conceptual difference between these two scenarios is that in the first case one is optimising the time-frame of the order execution schedule, and in the second case, order execution process in terms of cost is optimised. Of course, these two scenarios can be used simultaneously, by making first a tentative Global Schedule and try to reduce costs via negotiation, giving preference to the enterprises which can deliver at a date close to the best date given by the GS. Once all the agents are dispatched to the Target Cluster, and all the enterprises are committed to execute that order, the work-effort can begin, following the overall plan of the GS. In the product execution phase, the role of the agents is to monitor the processes, by invoking
-10-
monitoring functionality in the local information system of the enterprise. The agents must be able to detect any problems which can occur at a local site, with respect to the normal execution of the target. When a component is finished at a supplier’s site, the agent reports it, and after the component leaves the enterprise to the buyer’s site, the agent also migrates to the buyer’s site, tracking the component. Its creator agent, located currently at the buyer’s site, takes the component’s agent data which is relevant for further use, and deletes the agent. This process is a reversal of the dispatching process in the selection process; finally, a single agent remains at the initial gate, and when it reports that the target is finished, the product can be delivered to the customer. In order to be able to monitor the execution of the local component, the agent must have access to various data in the local databases, such as daily schedules and confirmatory reports, or access to the GUIs of various human users. It should be possible to directly ask human users, in a proactive manner, about the status of any component execution. Our research emphasis is not on the dispatching and target execution monitoring, (which are relatively straightforward) but on using the agents to support processes that are taking place when problems appear during the target execution. Analysing different cases of undesired events, we discovered that the worst case is when an enterprise is not able to fulfil its commitments and decides to leave the Target Cluster. Usually, this happens before the workeffort has to start at that site, and one of the key roles of the monitoring agent is to identify early this problem. We call this the RENDER case. If an enterprise has to render, another enterprise has to be found from the eWeb. Because the repository of the resource availability gets continually updated, the configuration of the resources at the rendering moment will be different from the one when the initial GS was established. Some resources may have been committed, and other new ones been reported by the roaming agents. The ideal case is when one can find a new resource, replacing the lost one,
-11-
that fits in the same time slot. The agent located at the rendering enterprise has the task to invoke the central repository to find such a resource. If the resource is found, the agent migrates to the enterprise that is offering this resource, ask for its commitment, and if successful, informs the agents upstream and downstream about the necessary re-routing in transportation. This scenario is an eloquent description of our perception about the long-term relations and interaction policy what must exist between the members of eWeb. In such an organisation, opting-out does not lead to legal actions and deteriorating the relations among the members, but a mutual understanding together with a common willingness to resolve the problems as they occur. Because, the parties are expected to be cooperative and willing and thus release true information to agents updating the central repository. There is a reward in this cooperative behaviour: in case of undesired events the flexibility of the manufacturing process permits easy adaptation to the new situations. Thus, an enterprise that joins the MA-web, by installing a dock at its site, is also taking a commitment, that is to treat its partners in a cooperative manner. If there is no similar resource available in time to replace the rendered one, the agent invokes a new GS, which does not take into account the committed resources that are already committed in the work-effort for that target. There is a possibility that the final due date to the customer cannot be met. Someone has to decide what course of action is to be taken, because it implies that the new resources in the new GS has to be committed. That means that some of the previously committed resources have to be de-committed. In an extreme case, it is possible that all the enterprises which have been committed, but yet not started to work for the target may have to de-commit. If the delivery to the customer cannot make the due date, the product will have a lower price, and the difference is to be paid as a penalty by the enterprise which rendered the resource. If this enterprise is seen as a supplier, the buyer linked to it can resolve the situation in a more efficient manner, resulting in a win-win-win (supplier, buyer, final customer) situation. The
-12-
agent at the buyer’s site can look into the repository for a resource which has the same type, but a slightly later time-slot, and send an agent there, to check its commitments. Between the buyer and the new supplier, a negotiation to fix a new due date can then be arranged. The buyer is trying to make its time-slot smaller, by moving its work effort start to a later date as the new supplier tries to deliver earlier, to a date that is prior to the buyer’s starting date. Of course, this means that the work-effort has to be more intensional (by hiring temporary staff and machines, working more hours, etc.) and the rendering enterprise has to pay to the buyer and the new supplier for the supplementary effort. It is possible that this sum is less than the penalty to be paid to the customer, and additionally, the initial GS can be followed, without de-committing enterprises which are not “guilty” and the customer delivery date is kept. In addition to render, we can identify other possible scenarios: - the EARLIER case, when the time-slot is moved earlier - the POSTPONE case, when an agent detects that a resource’s time-slot has moved later in an enterprise which has not started yet the work effort for the target, - the DELAY case, which is similar to the POSTPONE case, but the enterprise has started the work effort - the CRASH case, when an enterprise which already started, has to de-commit. Each of these cases can have many possible scenarios and ways to solve a problem, which in essence is a delay management process. In each situation, the primary common goal of the agents is to find a solution that leads to the delivery of the product to the customer as close as possible to the required due date. Secondary goal is to minimise the perturbation among the target cluster at large. The agents will act as mediators of the negotiation process (see figure 3). And this process will be executed according with the rules coded in the agents. All the enterprises must be willing to obey these rules, which enact some sort of generic code of conduct during the negotiations within the eWeb.
-13-
party-to-party level of interaction
mediated level of interaction
dock
enterprise X
dock agent
agent
physical level of interaction
enterprise Y
figure 3: The agent-mediated model of interaction
5 Agent mediated negotiation By trying to identify common patterns for solutions in the presented cases of undesired events, we noted that the solving process can often be reduced to a set of negotiations between pairs of enterprises, where the issue of the negotiation is price. It is evident that the same logic holds true for the cost-based cluster formation. In any negotiation, we have a seller (supplier) and a buyer. The seller is trying to sell at the highest possible price and the buyer is trying to buy at the lowest price. Before the negotiation starts, each party has a reservation price (the “walkaway” price) and the buyer will not pay more and that (we refer to this price as b) and the seller will not accept less that his (a value referred as s). The basic negotiation scenario using mediator agents is as follows: 1. Both parties are sending their reservation price to the locally docked agent 2. The agents compare the prices, and if b>s, then a zone of agreement exists and a fair price can be the simple average of b and s (see figure 4). Negotiation ends.
-14-
3. If bs : zone of agreement
price
11/12 chance
200 100
150
200
300
range for b
s>b
150
no zone of agreement chance1/12
s 100
150
200
figure 6: The case of uniform distribution of reservation prices
Also, the agents can have previous knowledge about the price zones from previous negotiations between the same parties (or other pairs) and try to keep the current values within “normal” boundaries, by not letting a party to exaggerate the price zone too much. Another possibility is to ask neutral parties in a similar context about the prices they would be willing to pay and compare to the current situation. The final price can be influenced by this supplementary knowledge, because it may not always be fair to apply the average formula: ( 1/2*(b+s) )
-16-
especially if only one party exaggerates. This is named asymmetric mediated price negotiation [16] and empowers the mediators with more power than in the normal situation. It is up to the mediator to consider which of the parties is exaggerating and which is not. As an illustration, we show the following case: a party S1 with the due date T1 is rendering, and in the worst case scenario, implying a totally new re-schedule, it has to pay a big penalty p to the customer. The agent at S1 is messaging to the agent at the buyer B. This agent is looking for a replacement resource at S2, but the due date T2 is slightly later than T1. The buyer is compressing its time slot for its work effort to start later at T3, but this is still earlier that T2. The cost of the compressing is b. The buyer asks S2 to compress its time to be able to deliver before T3 (see figure 7). The cost of the compressing at S2 must be less than p-b, which is the reservation price for B. The agent at S2 can seek for similar resources (in terms of type and duration), and ask about the price of compression. From this data, it is possible to construct a probability distribution and compute the probability for the agreement . parties
S2
S1 B1 S2
B
B S1 (renders)
time T1
T3
T2
figure 7: The compression of time-slots made by the buyer and the supplier S2
The agents are viewed in these negotiations as third trusted parties, and they do not disclose the reservation prices of either party. They only announce if the agreement can be
-17-
reached, and in the “yes” case, together with the final price, which is always above the reservation price (see the “surplus” in figure 4).
6 The ideal solution Using mediator agents is somewhat equivalent to the well known method for price bargaining named “simultaneous-revelation resolution procedure” [18]. This method is the fastest known, but it is inefficient because encourages exaggerations. In [16] it is stated that “partners consider that it is culturally acceptable to exaggerate a little bit in your favour”. The problem is that if both parties exaggerate a lot, then the chances for an agreement are very slim. A laboratory experiment involving humans (made by Samuelson, presented in [16]) compared the true reservation prices (TRP - established by the experimenter) and the announced reservation prices (ARP) in simulated price negotiations. The experiment revealed that in many cases, especially when the TRPs values were close, the negotiation failed, because the ARPs gave no zone of agreement. The simultaneous-revelation resolution can be altered in such a way as to engender truthfulness [19]. Suppose there is a supplier S, a buyer B, and a mediator AG (in our case, a pair of agents). Imagine that A can induce B to make honest revelations: his declared price, ARP_B, is the same as his real price TRP_B. How can AG get S to be equally honest? If S real price is TRP_S and if it announces ARP_S, while B announces a new ARP_B = TRP_B, the payoff for the supplier will be [(ARP_B+ARP_B)/2]-TRP_S. Of course, if a zone of agreement exists (ARP_B>ARP_S). In order to have truthfulness, an adjustment to this payoff is made. A supplementary amount is added (paid by the buyer), depending on the value of ARP_S (see figure 8).
-18-
. adjustment function
supplier’s exaggeration the amount the buyer pays the seller as a reward for a honest disclosure of his price
price TRP_S
ARP_S
Figure 8: The extra payoff the supplier receives as a function of ARP_S (proposed by Chaterjee).
Notice the higher the supplier’s ARP_S the lower the adjusted payment he will receive from the buyer. The difficult part of implementing this scheme is to construct the adjustment in such a way so that if the buyer tells the truth (ARP_B = TRP_B), then the supplier’s overall response is also to tell the truth (ARP_S = TRP_B). The problem is that this function depends on the value of TRP_S and the interval between this value and TRP_B, because it is important that S has to announce ARP_S = TRP_S for all possible values or TRP_B and TRP_S. If we assume that the supplier is announcing the correct value, how we can determine the adjustment that B will have to pay him? AG will induce B to pay this adjustment by reversing the roles and making the supplier pay to S an adjustment value that depends solely on ARP_B. AG will construct the adjustment function for B so as to make it more profitable for him. The final expectation is that the side adjustments will sum to zero. With suitable adjustments functions, honest revelations can be in equilibrium, where each party tells the truth if the other does. Can all this be achieved? The experts: see [16], [18] [19] state that the buyer and the supplier have to agree to it before the negotiation begins. If they are using the software agents as mediators, this fact is implicit. The mediator has to calculate appropriate adjustment
-19-
functions, and he needs to know before hand the probability distributions. In this case, it is necessary for the agent system to keep a history of the previous negotiations, in order to select the appropriate adjustment function. Following section proposes such a model.
7 A Solution: the trust-based negotiation model As presented previously the simplest way to enact a mediated negotiation is the “truthful simultaneous disclosure of reservation prices” technique where the buyer and the seller announce exactly what are their reservation prices. But we have to accept in any realistic model the parties might not be willing to disclose their walkaway prices even to a neutral mediator. The first announced prices are usually exaggerated, but this tendency is considered acceptable in any business culture. A possible solution is to measure this tendency over time in order to build a trust/distrust historical value for the enterprises in the eWeb. The keeper of this data should be the SACP. As in any human-driven negotiation, when the parties know that the other one is exaggerating, a “negotiating dance” [16] takes place. Step-by-step, each party gives in a little bit, until the announced prices meet somewhere between the reservation prices. A mediator can lead and balance this “dance” in a neutral way, if it knows how much the parties are exaggerating. A measurable value for trust/distrust is the tendency for exaggeration in negotiations. We propose that the third trusted party maintain and update a value for this tendency for each party. Each mediated interaction will yield a result for the exaggeration tendency and this current value will update the centrally maintained value, which is accessible only to the mediator agent, that is measured as a normalised value in the interval [0,1]. This value is somewhat similar to the weight assigned to a party in [20], in the way that it will affect future negotiation, exaggerating agents being “punished”. This tendency can be measured in two
-20-
ways: after each mediated negotiation (considering that it was successful), the mediator can compute the difference between the first announced price of the party and the finally agreed price (eq. 1). The difference is considered exaggeration and it is recorded using the overall average formula (eq. 2). The sliding average can also be used, where recent interactions carry higher weighs than the past ones.
firstprice – finalprice tend ( p ) n + 1 = -----------------------------------------------------------firstprice
n ⋅ tend ( p ) n + tend ( p ) n + 1 tend ( p ) n + 1 = ---------------------------------------------------------------n+1
(1)
(2)
The second way to measure the exaggeration tendency is before the negotiation, through the estimation of the mediator. This estimation needs a fixed point of reference, and this can be only a neutrally estimated price. How this can be obtained? Consider that many of the parties who can a deliver a product type cannot deliver it at the date asked in a specific purchase order of a buyer, this being in accordance with the availability assumption made in section 2. For this particular purchase order execution, these parties can be considered neutral. The mediator agent can ask these parties for an opinion about a “honest price”. Also, the mediator, without disclosing the identity of the buyer and seller can ask only the neutral seller who has the best value (i.e. the lowest) for the exaggeration tendency in the “trust-database”. On the other hand, if the mediator has more values, he can infer by simply averaging or by “maximum density distribution selection” a honest price.
-21-
honest
seller’s announced price
price
buyer’s announced price bp
price
hp sp
Figure 9. The starting situation for the mediator
Consider the following situation: the buyer announced to the mediator the price bp, the seller the price sp, and the mediator “discovered” the price honest price hp (as in figure 9 - there are other possibilities, where hp is to the left of bp or hp is to right of sp, but we are not investigating these). For simplicity, the mediator will consider that only one of the parties is exaggerating. For example if (sp -hp)(hp - bp), then the negotiator will consider that the seller is exaggerating. Following the same demonstration as for (3), the seller estimated exaggeration tendency will be:
sp – 2hp + bp tend ( seller ) = ---------------------------------2 ⋅ hp – bp
(4)
In this case, the tendency of the buyer will be considered 0. In principle, the negotiation can be completed by the mediator agent, after one step by announcing a final price. The simplest resolution is to select hp as the final price. In reality, the mediator must consider that both parties are exaggerating, and the honest price given by somebody else is not necessarily the absolute fair reference. In order to compute the final price, the mediator can consider that exaggeration he measured is only half (the rest is considered to be done by the other party). The following formula (eq. 5) will give the result, as an offer of the mediator. Interestingly, in both cases (seller exaggerates, or buyers exaggerates) the demonstration yields the same formula:
bp + sp + 2 ⋅ hp mp = -------------------------------------4
(5)
The formula above considers that the honest price is not the best price, but only an indication for where this price should approximately be. If this meditated price is within the
-23-
boundaries of the reservation prices for both parties, an agreement is reached. If not, the negotiation fails. The failure is given by the starting conditions (the reservation prices) and not by the negotiating technique. The mediator agent can take into account also the previously measured tendencies of the parties, tend(s)n and tend(b)n, and a corrected mediated price is fairer (eq. 6).
( 1 + tend ( b ) n ) ⋅ bp + ( 1 – tend ( s )n ) ⋅ sp + 2 ⋅ hp mp = ---------------------------------------------------------------------------------------------------------------------4 – tend ( s ) n + tend ( b )n
(6)
Even if the prices are within the boundaries of the initial reservation prices, there is a risk that the agents will not agree with the decision taken by the negotiator for the mp value. In automated negotiation (and in human negotiations as well), it is hard to asses by the parties that mp is a “good” price. Rational agents expect a “win” over the walkaway price. Internally, they set an “expected price”. In game theory, this price is called “local maximum utility solution” for that particular agent. Moreover, bargaining means to give in step-by-step, not to accept a singlestep decision. We are applying three methods to increase the chance for agreement: i. There are more sellers in the process, implement a “sealed auction” process [2]. ii. The negotiation process is made in more steps, resulting in a “multi-step sealed auction” process iii. The number of steps is limited to a certain value, established or computed by the negotiator and known by the negotiating parties.
In a multi-step approach, the negotiating agents will have more insight about the behaviour of the opposite party and they can change dynamically the parameters for their
-24-
internal computation of the announced prices. Moreover, the buyer agent has a perspective over all the involved sellers, and it can compare their behaviour. Consider that the maximum number of steps is t. Each step i is started when the buyer and the seller announce prices (bpi and spi). The mediator, who previously “discovered” the “honest price” is computing the tendencies for exaggeration using (eqns. 3 and 4). Also, he is computing his internal target price for the next step, mpi, using (eq. 6), but this value will not be disclosed to the parties. i
i
( 1 + tend ( b )n ) ⋅ bp + ( 1 – tend ( s ) n ) ⋅ sp + 2 ⋅ hp i mp = ------------------------------------------------------------------------------------------------------------------------4 – tend ( s ) n + tend ( b ) n
(7)
Although this price can be shown only as a “proposal” of the mediator, our observation is that during the steps, this target price remains relatively fixed, giving the impression to the parties that the other party (actually the mediator) is not “giving in”. Worse, the target price is “wobbling” around a fixed value (the first offer), showing a very strange behaviour to the buyer and the seller. From a logical point of view, it could be better to show to the buyer that the price offered by the negotiator is decreasing step by step, and the price offered to the seller is increasing with each step. This way, the mediator offers different but converging prices to the seller and the buyer. This can be achieved by using the “margin” concept. The margin value, Mi, is computed each step, using: i
i
i sp – bp M = --------------------f( i)
-25-
(8)
where the simplest form for f could be a linear function of i. f
(9)
s t i
The price offered to the seller will be: i
i
i
i
i
i
i
i
msp = mp – M ( 1 + tend ( s ) + tend ( s ) n )
(10)
and to the buyer: mbp = mp + M ( 1 + tend ( b ) + tend ( b ) n )
(11)
The slope of the function f must be chosen in a way which prevents the situation that bpi>mspi and spi
