AAMAS System Demonstration site

Catholijn Jonker (1), Lourens van der Meij(1), Valentin Robu(2), Jan Treur (1)

2. Center for Mathematics and Computer Science, Amsterdam

Demonstration of a Software System for Integrative Bilateral Negotiation Using Incomplete Preference Information

This system illustrates a bilateral multi-agent negotiation, where the values across multiple attributes are negotiated on simultaneously. More specifically, this is a negotiation between a Buyer and a Seller over the buying of a car. In the beginning of the simulation, each party can choose whether it wishes to be represented by an automated software agent, or it wishes to make the bids manually, through an interface. The precise model used by the agents in our system are described elsewhere (references [1] [2]), so in this page we only show the screen shoots from our software tool, in the form of a story board. However we find it useful to also provide a link to some of the papers which resulted from this research (in pdf format), if the reviewers (or other interested parties) would like to know more.

Related publications of interest

For details of the agent design and mathematics used to model the negotiation, the reader may find useful the following papers:

[1] Jonker, C., Treur, J. - An Agent Architecture for Multi-Attribute Negotiation, Proceedings of the IJCAI'01, pp. 1195-1201.

[2] Jonker, C., Robu V. - Automated Multi-Attribute Negotiation with Efficient Use of Incomplete Preference Information, under submission at AAMAS 2004 (paper ID 190).

[3] Robu, V. - Modelling cooperative negotiations in electronic environments with incomplete information, Master Thesis, Technical Report, Vrije Universiteit Amsterdam, 2003.

System requirements: The agent system itself is implemented on the DESIRE agent platform implemented at Vrije Universiteit, Amsterdam. This can be downloaded through the Internet and installed on site. The download size is about 5 MB, and the installation itself requires less than 25 MB. It is somewhat easier to install the platform on a Windows machine, but it should also be possible on a Linux-based system.

1) Buyer interface for specifying parameters for automated negotiation agent

Through the interface below the Buyer specifies his preference weights, as well as the value evaluations he assigns to each attribute. There are two types of attributes:

Discrete-valued attributes (which in this domain are: CD player, Extra speakers, Airco and Drawing hook). Each of these attributes can take a value from the set: good, fairly good, standard, meager and none. However the agent owner may choose, through the interface below, the evaluations he wishes to give to these values, as a number between 0 and 100 (which may differ between attributes). For example, in the interface illustrated below, the same values are chosen for all attributes (good=100, standard=70, etc.).
Continuous-valued attributes (which in this case is just one attribute: price). Through this interface, the Buyer specifies for price his initial starting price. In the current implementation, the value of price is linked to the utility through a linearly decreasing function (see [1]). We preferred to give the parameters of this function through a configuration file, so the interface is not crowded with too much detail.

The most important parameters here are however the attribute preference weights. These preference weights determine how much concessions will be made in each attribute. These are the raw weights, which are then scaled to add up to 1 (see [2]).

2) Interface for human Buyer to specify his/her own bids

The following interface can be used in case the human Buyer does not wish to allow a software agent to decide her bids. The negotiation software can be installed on different machines, and the parties may negotiate over the network (not face to face). This facilitates testing with human users in two important ways(similar to techniques widely used in experimental economics):

First the humans do not talk to each other and have to "signal" their intentions only through their bids or by sharing preference weights, which is realistic for the way software agents take these decisions.
Because the human behind the machine may not know who he/she is negotiating against (against another human or against the software), this greatly helps in testing how robust the software is (this part of the research is still ongoing and also under submission - also at AAMAS 2004).

3) Seller interface for specifying parameters to her automated negotiation agent

This interface is used by the Seller to give his automated software agent the parameters to be used in the negotiation. The interface and significance of the parameters are similar to the one from section 1, with the difference that this is for the Seller side.

4) The negotiation trace from the perspective of the two parties

In the following, the alternative bids of the two parties are shown, numbered sequentially. This is the trace resulting from a negotiation where only the weight of one attribute: Drawing Hook (or Tow Hedge) is shared, and the Seller uses the guessing heuristic (see [2] for details). In the current version of the tool, the exact parameters that can be shared, as well as the possibility to use guessing, are read into the tool through a configuration file (though, in future vesions of our software, it may be useful to add this option in the interface itself).

As can be seen from the above interface the negotiation trace, the outocme reached, for the above preference weights, in this case is (note: the Seller will automatically accept the last bid of the Buyer when the difference in preference between the own and other's bid becomes too small):

A) One attribute weight shared, Seller uses guessing:

<Drawing Hook = fairly good, Airco = standard, Extra speakers = none, CD player = none, Price = 18145>,
having the (final) utilities: <Utility Buyer = 0.902222, Utility Seller = 0.896383>

For exactly the same configuration of preference weights and attribute value evaluations, we can also demonstrate the outcome for a different case:

A) Closed negotiation, no guessing:

<Drawing Hook = meager, Airco = meager, Extra speakers = meager, CD player = meager, Price = 18439>
this bid having the corresponding utilities: <Utility Buyer = 0.786, Utility Seller = 0.768667>

(for reasons of space we do not show, again the picture of the interface here, since it is large and identical to the one above).

5) The outcomes plotted in the joint utility space

The following pictures show the joint utility space, where each of the bids made during the negotiations are plotted against the Nash curve. There are two pictures represent: the first one the negotiation in case "A" from above and the second one the negotiation from case B. From this we can clearly see that some information can be used efficiently and guessing indeed helps. The numbers in the left-sdie figure represent exactly the bids 1-5 from the interface at point 4.

6) Confirmation windows

These last windows were added in order to enable the Buyer/Seller agent owners to provide a confirmation of the reached deal. This may be important if the human Buyer/Seller does not agree with the deal his software agent has reached.

References:

[1] Jonker, C., Treur, J. - "An agent architecture for Multi-Attribute Negotiation", Proceedings of the IJCAI'01, pp. 1195-1201.

[2] Jonker, C., Robu V. - "Automated Multi-Attribute Negotiation with Efficient Use of Incomplete Preference Information", under submission at AAMAS 2004.

[3] Robu, V. - Modelling cooperative negotiations in electronic environments with incomplete information, Master Thesis, Technical Report, Vrije Universiteit Amsterdam, 2003.