Modeling and Production of Negotiation Protocols
On of the reasons that agent based interaction is so interesting is the ability of the interacting parties to
come to an agreement through negotiation. Negotiation types are dependent on the types of interactions of
the agents. For example, the negotiation type for the interaction of a buyer and a seller can be different
from the interaction of fifteen buyers and one seller, or from ten buyers and 15 sellers. With the great
diversity of possible types of interactions, a clear, succinct method to create new negotiation protocols is an
interesting and applicable problem.
One method to create such negotiation protocols is through modeling. Models that incorporate the
behavior and structure of the protocol may be interpreted with a generic algorithm, which produces source
code to be incorporated into the agent. The Graphical Modeling Environment (GME) provides a way to
create the structure and behavior of a protocol using a visual modeling language.
Parts
Certain primitives are basic to the creation of the modeling language. These primitives are Send, Receive,
Action, Default Action, Succeed, and Fail. More abstract than these primitives is the notion of an
Initiator and a Respondent. The initiator begins the interaction by contacting the respondent. However,
in many problems there may be more than one initiators and/or respondents. Regardless of the number of
participants, it is important to know that an agent falls into one of two categories: contactor, or contacted.
The semantics of the primitives are as follows.

Send – this primitive incorporates the transmission of information to the other type of party.
Using the Foundation for Intelligent Physical Agents (FIPA) specifications for message passing, a
Send primitive sends one of several types of messages,
o Accept-proposal – when the proposal is agreeable, the agreeing party sends this message
o Cfp – “call for proposal”, issued by an initiator to alert parties interested in negotiation
o Inform – used to pass information to the other party
o Not-understood – the last message was not according to the protocol
o Propose – sent to bargain with the other agent in response to a cfp
o Refuse – indicates refusal to perform a requested action

Receive – the companion to Send. This primitive indicates that the agent is awaiting a message
from another party. When the agent is notified that a message has arrived, it interprets the
contents of the message and then responds according to the individual model.

Action – this is a special part that is essential to this modeling idea. Although it is relatively
simple to piece together the order in which agents send to each other, what they do upon receiving
a message is the most interesting part. Therefore, the Action part contains specific execution
information, right now in the form of application specific source code. Currently, this is the only
implementation dependent detail of the modeling language. Depending on the return values of the
action, different paths are taken according to the individual protocol.

Default Action – this is a part that points to the first primitive in the modeling protocol. It is
similar to a default state transition in a state machine.

Succeed – this part indicates success in the negotiation process.

Fail – this part indicates failure in the negotiation process.
There are connections between each of the primitive parts. The connections are directional, and the model
interpreter uses them to determine the order in which the agent expects and sends messages.
Example
A good example of a negotiation protocol is the FIPA Contract Net. In this protocol, an initiator
approaches a respondent with a cfp. The respondent then either refuses the job, or issues a proposal
containing a bid with cost information (e.g. time, money, quantity). When the initiator receives the
proposal, it either accepts it, or issues a counterproposal (or another cfp). Proposals and counterproposals
are issued until the initiator either accepts the bid, or the respondent refuses the job. If a bid is acceptable,
then the initiator issues an accept-proposal message, and the exchange takes place. Next is a visual
representation of this behavior.
Note that the Responder agent contains two actions name “EvalCapabilities.” In the event that there are
two identically named actions, the interpreter warns the user, but no error is generated. The interpreter
writes only one of them to the file, it is assumed that the other is identical.
Algorithm
Once the model is complete, the interpretation from visual model to source code takes place. When
interpreting the model, a certain algorithm is used. The pseudocode is as follows.
Write basic file information, class name, etc.
Do(Get next Agent)
Determine initiator or respondent
Write the return values for actions
Locate the default-action
Follow the path from the default-action
(depending on next part in line, do something)
action:
create return value integer
set integer equal to ActionName( )
switch off of the integer return value
(depending on the next part in line, do something)
have a default value that returns FAIL
send:
get the type (cfp, propose, etc.)
build a string of information that becomes the send command, and write it out
(depending on the next part in line, do something)
return either WAIT, or OK
receive:
check the message type
write if-then statements that describe the paths emanating from the receive
(depending on the next part in line, do something)
succeed:
return OK
fail:
return FAIL
once all paths have been followed, write the contents of the actions as subroutines
that return integer values.
While (another agent)
This is the generic algorithm that creates source code. Different agent based packages may require certain
additions to certain parts and certain atoms, but the general case should incorporate the above pseudocode.