Enhancing Commitment Machines

Michael Winikoff1, Wei Liu2, and James Harland1

1 RMIT University, Melbourne, AUSTRALIA{winikoff,jah }@cs.rmit.edu.au

2 University of Western Australia, Perth, AUSTRALIAwei@csse.uwa.edu.au

Abstract. Agent interaction protocols are usually specified in terms of permissi-ble sequences of messages. This representation is, unfortunately, brittle and doesnot allow for flexibility and robustness. Thecommitment machinesframeworkof Yolum and Singh aims to provide more flexibility and robustness by defininginteractions in terms of the commitments of agents. In this paper we identify anumber of areas where the commitment machines framework needs improvementand propose an improved version. In particular we improve the way in whichcommitments are discharged and the way in which pre-conditions are specified.

1 Introduction

Communications between software agents are typically regulated by interaction proto-cols. These include general communication protocols, such as the auction protocol andthe contract net protocol, as well as more specific protocols such as the NetBill pay-ment protocol [1, 2]. Traditional protocol representations such as Finite State Machines(FSM), Petri-Nets [3] and AUML sequence diagrams [4, 5] often specify protocols interms of legal message sequences. Under such protocol specifications, agent interac-tions are pre-defined and predictable. However, the inevitable rigidity resulting fromsuch protocols prevents agents from taking opportunities and handling exceptions in ahighly dynamic and uncertain multi-agent environment.

Yolum and Singh’s Commitment Machines [1] (CMs henceforth) define an interac-tion protocol in terms of actions that change the state of the system, which consists ofnot only the state of the world but also thecommitmentsthat agents have made to eachother. It is the commitment made to an interaction partner that motivates an agent toperform its next action. In other words, an agent acts because it wants to comply withthe protocol and provide the promised outcomes for another party. Actions in CMs notonly change the values of state variables, but also may initiate new commitments and/ordischarge existing commitments. In traditional protocol representations, agents are con-fined to perform some pre-defined sequence of actions, whereas in CMs, an agent is ableto reason about the next action to be taken in accordance with the dynamics of the en-vironment and the commitments. This fundamentally changes the process of protocolspecification from a procedural approach (i.e., prescribinghow an interaction is to beexecuted) to a declarative one (i.e., describingwhat interaction is to take place) [1].

Using commitments as the rationale for agent interactions allows protocols to bespecified at a higher level, which then generates more flexible and robust interactions

than pre-defined sequences. For example, in the NetBill protocol (discussed in Section2), a customer may wish to order goods without first receiving a quotation, or a merchantmay be happy to send goods to a known reliable customer with less rigorous checkingthan normal.

In this paper we identify a number of areas where the Commitment Machine frame-work can be improved. Specifically, we show how the identification of undesirablestates (such as omitting to provide a receipt, or receiving the goods before payment hasbeen confirmed) can be incorporated into the design process in order to achieve accept-able outcomes for a wider variety of circumstances than is done in [1, 2]. We also showhow certain anomalies in discharging commitments and in handling pre-conditions canbe remedied.

We demonstrate the operation of the improved framework on some examples. Thisis necessarily limited to a small number of illustrative cases, but these suffice to demon-strate the generality of the improvements.

The paper is organized as follows: in Section 2 we introduce the commitment ma-chine framework and a detailed example, both based on [1]. In Section 3 we identifya number of anomalies and issues with the commitment machines framework and inSection 4 we propose some improvements. In Section 5 we discuss further applicationsof the improved framework and in Section 6 we present our conclusions.

2 Background

We briefly introduce the commitment machines framework and the NetBill protocol.Both are based on the description in [1] and we refer the reader to [1, 2] for furtherdetails.

The key example used in [1] is the NetBill protocol [6]. In this protocol a customerbuys a product from a merchant. To buy a desired product, the protocol begins with acustomer (C) requesting a quote (message 1 in Figure 1) from the merchant (M), fol-lowed by the merchant sending the quote (message 2). If the customer accepts the quote(message 3), the merchant proceeds by sending the goods (message 4) and waits for thecustomer to pay by sending an electronic payment order (EPO). Note that it is assumedthat the goods cannot be used until the merchant has sent the relevant decryption key,such as software downloaded from the internet, or sent on a CD. Once the customerhas sent payment (via an EPO in message 5), the merchant will send the decryption keyalong with a receipt (message 6). This concludes the NetBill transaction.

As suggested by the name “commitment machine”, a crucial concept is that ofcom-mitment. A (social) commitment is an undertaking by one agent (thedebtor, x) to an-other agent (thecreditor, y) to bring about a certain propertyp, written C(x, y, p). Acommitment of the formC(x, y, p) is a base-levelcommitment. For example, in theNetBill protocol when the customer sends message 3 and then receives the goods, he orshe has a commitment to pay the merchant, i.e.,C(C,M, pay).

When a party is willing to commit only if certain conditions hold (such as anotherparty making a corresponding commitment), aconditional commitmentcan be used.A conditional commitment, denotedCC(x, y, p, q), indicates that agentx is committedto achievingq for agenty if p becomes true. A conditional commitment is latent – it

Customer Merchant

1: Request Quote

2: Present Quote

3: Accept Quote

4: Deliver Goods

5: Send EPO

6: Send Receipt

Fig. 1.Simplified Net Bill Protocol

doesn’t commitx to do anything untilp becomes true, at which point the conditionalcommitment is transformed to the base-level commitmentC(x, y, q). For example, inthe NetBill protocol the customer may insist on his or her commitment to pay beingconditional on the goods being sent, which would be represented asCC(customer,merchant, goods, pay). Where the identity of the debtor and the creditor are obviousfrom the context we shall sometimes writeC(p) in place ofC(x, y, p) andCC(p q)in place ofCC(x, y, p, q).

Interactions are specified in the CM framework by defining the roles of the par-ticipants, the domain-specific fluents (i.e., boolean state variables), the (conditional)commitments that may arise during the interaction, and the rules forinitiating andter-minatingcommitments. Together, they define the preconditions and effects of (com-municative) actions, and are used to regulate the choices of actions during protocolexecution. The execution of a protocol is driven by the commitments that are in place:the desire to fulfil these commitments generates an action or actions to achieve them,which in turn may create new commitments or discharge existing ones. The NetBillprotocol as a CM can be found in Figure 2.

A state in a CM is a triple〈F,CC, C〉, whereF is a set of fluents,CC is a setof conditional commitments andC is a set of base-level commitments. Afinal stateis a state that does not have undischarged base-level commitments. A final state maycontain conditional commitments, since they are latent commitments that have not beenactivated. Formally, a state in a CM is a final state ifC = ∅. Note that a final state in aCM is one where the interactionmayend. However, it is also possible for interaction tocontinue from a final state. Aprotocol runconsists of a sequence of actions that resultsin a final state.

A commitment machine places constraints on the sequence of agent actions thatconstitute the interaction. For example, if an agent has a commitment, then it must atsome point fulfil its commitment3. However, commitment machines do not dictate orrequire that agents perform particular actions.

3 Commitments can also be discharged in ways other than being fulfilled [1].

Roles:M (merchant),C (customer)Fluents:

– request (the customer has requested a quote),– goods (the goods have been delivered to the customer),– pay (the customer has paid),– receipt (the merchant has sent the receipt)

Commitments:

– accept = CC(C, M, goods, pay): a commitment by the customer (to the merchant) to payonce the goods have been delivered.

– promiseGoods = CC(M, C, accept, goods): a commitment by the merchant to send thegoods if the customer accepts. Sinceaccept is itself a commitment this is a nested commit-ment:promiseGoods = CC(M, C, CC(C, M, goods, pay), goods).

– promiseReceipt = CC(M, C, pay, receipt): a commitment by the merchant to send areceipt once the customer has paid.

– offer = promiseGoods∧ promiseReceipt: an offer is a commitment by the merchant (a)to send the goods if the customer accepts the offer, and (b) to send a receipt after paymenthas been made.

Action Effects: the following (communicative) actions are defined:

– sendRequest: this action by the customer makes the fluentrequest true.– sendQuote: this action by the merchant creates the two commitmentspromiseGoods and

promiseReceipt (i.e.,offer ) and terminates (makes false) the fluentrequest.– sendAccept: this action by the customer creates the commitmentaccept.– sendGoods: this action by the merchant makes the fluentgoods true and also creates the

commitmentpromiseReceipt.– sendEPO: this action by the customer makes the fluentpay true. This action is defined in

[1] as having the pre-condition that the goods have been sent.– sendReceipt: this action by the merchant makes the fluentreceipt true. This is defined in

[1] as having the pre-condition that payment has been made.

Fig. 2.The NetBill Protocol as a Commitment Machine [1]

Each commitment machine implicitly defines a corresponding Finite State Ma-chine4 (FSM) where the states of the FSM correspond to the states of the CM andthe transitions are defined by the effects of the actions. Figure 4 shows a (partial) viewof the states and transitions corresponding to the CM defined in Figure 2. Final states(those with no undischarged base-level commitments) are shaded and dotted lines de-pict actions that are intended to be prevented by pre-conditions (but see Section 3.4).This figure is an extension of the figure given in [1, 2]. The table in Figure 3 gives thefluents and commitments that hold in each state.

4 Actually, a variation of finite state machines, since there is no defined initial state.

No. State1 -2 request3 M: promiseReceipt ∧ promiseGoods4 M: promiseReceipt ∧ C(goods), C: accept5 goods, M: promiseReceipt, C: C(pay)6 goods, pay, M: C(receipt)7 goods, pay, receipt8 goods, M: promiseReceipt9 C:accept10 pay, M: C(receipt) ∧ promiseGoods11 pay, receipt, M: promiseGoods12 goods, receipt13 goods, M: promiseReceipt, C: accept

Fig. 3.States and associated commitments and fluents.

3 Properties of CMs

In this section we discuss various properties of CMs as presented in [1, 2] and identifya number of areas where we propose improvements to the CM framework.

3.1 Explicit labelling of undesirable states

The presentation in [1, 2] presents protocols as defining states (in terms of the commit-ments of the agents and the fluents that hold). A query is then given and the reasoningmodule finds possible sequences of actions that lead to the requested state. For exam-ple, in [2] given the commitment machine defined in Figure 2, the reasoning moduleis asked to find sequences of actions that lead to a final state where goods have beenreceived, payment has been made, and a receipt has been issued.

However, when designing interaction rules it is important to not only ensure that adesirable final state is possible, but also to ensure that undesirable states are not possible.

In this context when we talk about “desirable” and “undesirable” states we are talk-ing from the perspective of thedesignerof the interaction, not from the perspective ofan agent who will take part in the interaction. Roughly speaking, the designer shouldconsider a state to be desirable if at least one agent desires it and no agents find itundesirable. A state should be considered undesirable if any agent finds it undesirable.

If an undesirable final state is determined to be possible then this can be fixed byeither adding additional commitments so that the state is no longer final, or by addingpre-conditions so that the state can not be reached. It isnot possible to fix undesirablefinal states by merely having the agents be aware of the undesirable state - if a state isundesirable to one agent, another agent may still perform an action that results in thatstate.

For example, in the NetBill protocol the desirable final states are those in whichthe goods have been delivered and paid for and a receipt has been given. Undesirable

4

5

M:sendGoods

6

C:sendEPO

7

M:sendReceipt

10

M:sendGoods

11

M:sendReceipt

1

2

C:sendRequest

3

M:sendQuote

8

M:sendGoods

9

C:sendAccept

M:sendQuote

C:sendAccept

C:sendEPO

C:sendEPO

12

M:sendReceipt

13

C:sendAccept

M:sendGoods

M:sendGoods C:sendEPO

Fig. 4. Implied FSM for the NetBill CM (partial), final states are shaded and dotted lines depictactions that are intended to be prevented by pre-conditions.

final states are those where only one or two of these three conditions hold; it is clearlyundesirable to have the goods without payment, to have paid for the goods withoutgetting a receipt, to have a receipt without payment, or to have paid without the goodsbeing delivered. The final state where the goods have not been delivered, no paymenthas been made, and there is no receipt is acceptable, but not desirable (neutral). InFigure 4 state 7 is desirable, states 8,11,12 and 13 are undesirable, and states 1,2,3and 9 are neutral. Note that states 10, 11, 12 and 13 have been added to the machinediscussed in [1, 2]. Note also that states 4,5,6 and 10 have undischarged commitments,and hence are not final states.

To illustrate why we need to identify and avoid undesirable states we consider analternative protocol which seems quite reasonable. This protocol differs from the onepresented in [1, 2] in that we remove the axiom:

Initiates(sendGoods, promiseReceipt, t)

This axiom is not needed in the “normal” expected sequence of actions (depicted inFigure 1) and it is quite possible that a naıve protocol designer would leave it out of aninitial protocol specification.

Now suppose that the customer does not need a quote (perhaps the customer andmerchant have interacted in the past), and begins the interaction withsendAccept. Themerchant replies to thesendAccept with sendGoods. At this point in the interaction thecustomer’s acceptance commitmentCC(good pay) becomes a commitment to pay,C(pay), since the goods have been received. The customer then fulfils their obligationby paying. At this point we are in a final state — there are no remaining commitments —and goods have been received and payment made. However, this state is an undesirableone because the customer has not received a receipt.

The important point is that the omission of theInitiatesrule is detected by checkingwhether undesirable (final) states are reachable, rather than by only checking whetherdesirable ones can be reached. If we had simply taken the variant protocol and askedfor sequences which result in goods being delivered along with payment and a receiptthen the problem would not have been noticed. In other words, the undesirable statescan be used as a check on the interaction rules, which in this case results in the problembeing easily found.

3.2 Failure to discharge conditional commitments

There are anomalies in the rules that govern the discharge of conditional commitments.These anomalies can, in certain situations, result in conditional commitments not beingdischarged when, intuitively, they ought to be.

Consider the following sequence of steps:

1. The customer asks for a quote2. The merchant replies with a quote. At this point the merchant has promised to send

the goods if the customer accepts, and has promised to send a receipt if the customerpays.

3. The customer, misunderstanding the protocol perhaps, decides to accept but sendspayment instead of an acceptance.

At this point the merchant becomes committed to sending a receipt, which it does,resulting in the following final state:

– fluents:pay, receipt– commitments of merchant:CC(CC(goods pay) goods)

The crucial point here is that this is a final state and the merchant is not committedto sending the goods. The reason is that in order forCC(CC(goods pay) goods)to becomeC(goods) the commitmentCC(goods pay) must hold: it is not enoughaccording to the formal framework forpay to hold. This is counter-intuitive becausepay is stronger thanCC(goods pay) in that it discharges the commitment. Theformal framework does recognise this, but only at the top level – the reasoning processthat dischargesCC(goods pay) whenpay becomes true is not applied to nestedcommitments.

3.3 Commitment discharge is not symmetrical

The axiom/postulate defining the conditions when a commitment (or conditional com-mitment) is discharged says that the commitment is discharged when it already existsand its condition is brought about by an event.

A problem with this is that it is possible to create a commitmentC(p) whenp alreadyholds. This commitment will not be discharged unless an event takes place subsequentlywhich re-initiatesp.

For example, consider the following sequence:

1. The customer sends an accept. The customer has now committed to paying if thegoods are received (CC(goods pay))

2. The merchant sends the goods. Since the goods have been sent, the customer nowis committed to paying (C(pay)).

However, lets consider what happens if the two steps occur in the reverse order:

1. The merchant sends the goods to the customer5

2. The customer sends an accept.

What is the resulting state? When sending the acceptance the customer initiates theconditional commitment to pay if the goods are received. This conditional commitment,however, doesnot become a commitment to pay even though the goods have alreadybeen sent. Consequently, the resulting state has no base-level commitments and so is an(undesirable) final state (state 13 in Figure 4).

3.4 Pre-condition mechanism does not prevent action

A standard view of actions that goes back to STRIPS is that an action definition containsa pre-condition and a post-condition. The formalization of actions in the CM frameworkuses these, but the way in which pre-conditions are handled has a slight problem.

Pre-conditions in a CM are defined by putting conditions on the action effect def-initions. For example, in [1] the effects of thesendEPO action are defined using theclause6

Initiates(sendEPO, pay, t)← HoldsAt(goods, t)

The intended reading in line with traditional pre-conditions is that “the goods musthave been delivered in order for payment to be possible”7 However, what this formal-ization actually does is limit theeffectsof sendEPO rather than the action itself. Inthe event calculus the causality betweensendEPO andpay is captured by the predi-cateIntiates(sendEPO, pay, t), notby the implication. The implication only places acondition on when thecausalityholds, not on when the action may be performed. Thus,this does not prevent the eventsendEPO from occurring ifgoods is false, it merely

5 As discussed in [2, example 2], this may be a sensible strategy if the goods are cheap to copy- e.g., software.

6 Notation has been slightly changed. The actual clause in [1] is:Initiates(sendEPO(i, m), pay(m), t)← HoldsAt(goods(i), t).

7 Note that this is the onlyInitiates clause concerningsendEPO.

means that if the eventsendEPO occurs withoutgoods being true then the fluentpaydoes not become true as a result ofsendEPO.

From the perspective of the reasoning mechanism, the formalisation of pre-conditionsintroduces an additional link from a state back to that state that corresponds to perform-ing an action whose pre-conditions are not satisfied (see Figure 5).

Action

(preconditions

satisfied)

Action

(preconditions

not satisfied)

Fig. 5.Additional action link created by incorrect formalisation of pre-conditions

This is a fairly subtle difference but it does have one significant implication: if weconsider agents that use an implementation of commitment machines to reason aboutwhat actions to perform, then, for example, a customer agent who has not received thegoods is not prevented from executing thesendEPO action. Although the reasoningmodule will, in this case, believe that the effects of payment have not taken place, if thesendEPO action is executed resulting in credit card details being sent, then in the realworld the action’s executionwill have resulted in the undesired effect of payment.

3.5 Communication mode assumptions not clear

The state space defined by the available events (actions) includes sequences of eventswhere an event representing an action by an agent (e.g., the merchant) is followed by anevent representing another action by the same agent. This may not be desirable, if theintention is to define interactions where a message fromM to C can only be followedby a response fromC to M .

The point here is that in the CM framework, there is no explicit specification ofhow the conversation should be carried out between the two parties, i.e., whether itshould follow a synchronous mode or an asynchronous mode. Were the synchronouscommunication mode clearly specified, the actionsendReceipt by the Merchant wouldhave been prevented in state 8 as the actors for the incoming and outgoing arc are thesame.

However, there are situations where consecutive actions from the same agentarede-sirable. A typical CM state that may result in multiple actions from the same agent (orsimultaneous actions from multiple agents) would have more than one base level com-mitment. See Section 4 for an example of a state with multiple base level commitments(state 10 in Figure 9).

A related issue is that the axioms allow an agent to perform actions that have noeffect. For example, in the state where a request has been sent, sending another requesthas no effect on the state. In the FSMs that we show these arcs from a stateS to itselfhave been elided.

We do not address these issues in this paper; we will return to them in subsequentwork.

4 Proposed extended CM model

In this section we propose an extended CM model which addresses some of the concernsdiscussed in the previous section.

4.1 Labelling undesirable states

This isn’t a change to the model so much as an extension and a change to how it isused (the methodology). As part of developing the commitment machine the designerindicates which states are undesirable (bad), which are desirable (good) and which areacceptable but not desirable (neutral). Indicating the desirability of states can be done byspecifying conditions. For example, one could specify that all final states which satisfypay ∧ ¬receipt are undesirable.

The indication of good/bad states is specific to a particular interaction and the pref-erences of the parties involved. For example, in [2, example 2] where the goods arecheap to copy, the merchant may not consider state 8 in Figure 4, which hasgoods butnotpay or receipt, to be a bad state.

The desirability of states, particularly of those states that are undesirable, is thenused to perform safety checking.

4.2 Issues with commitment discharge

We now present a revised axiomatisation that remedies both anomalies associated withcommitment discharge (Sections 3.2 and 3.3). We first consider the issue discussedin Section 3.2. Our proposed solution involves treating certain commitments as being“implied”. For example, ifpay is true, then any commitment of the formCC(X pay)that occurs as a condition can be treated as having implicitly held (and been discharged).

We introduce predicatesImplied andSubsumes which capture when a commit-ment (base or conditional) holds implicitly or is subsumed by a condition. These areused in the rules that govern commitment dynamics. When checking whether a condi-tion p holds, we also check whether it is implied or subsumed8.

In [2], fluentsare initiated directly by an action through theinitiates axioms(e.g.Initiates(sendGood, goods, t)). On the other hand,commitments, both base-level andconditional, are created through theCreateaxioms. TheCreateaxioms then initiate the

8 Implied(p, t) checks whetherp is implied at timet and is used to check whether a condition(implicitly) holds at the current time.Subsumes(p, p′) checks whetherp subsumesp′ and isused to check whether an event would cause a condition to (implicitly) hold.

Initiates(e, C(x, y, p), t)← Happens(e, t) ∧ Create(e, x, C(x, y, p))Initiates(e, CC(x, y, p, q), t)← Happens(e, t) ∧ Create(e, x, CC(x, y, p, q))

Terminates(e, C(x, y, p), t)← Happens(e, t) ∧Discharge(e, x, C(x, y, p))Discharge(e, x, C(x, y, p))← HoldsAt(C(x, y, p), t) ∧Happens(e, t) ∧ Initiates(e, p, t)

Initiates(e, C(x, y, p), t)← HoldsAt(CC(x, y, p, q), t)∧Happens(e, t)∧Initiates(e, p, t)Terminates(e, CC(x, y, p, q), t)← HoldsAt(CC(x, y, p, q), t) ∧Happens(e, t)∧

Initiates(e, p, t)Terminates(e, CC(x, y, p, q), t)← HoldsAt(CC(x, y, p, q), t) ∧Happens(e, t)∧

Initiates(e, q, t)

Fig. 6.Commitment Machine Axiom 2,3,8,9,10 from [2]

commitments when the action happens according to the first axiom in Figure 6. How-ever, this does not adequately distinguish commitments from other fluents. In particular,it makes no difference if we remove the first axiom in Figure 6 and replace all theCre-ateaxioms withInitiatesaxioms. In other words, according to the original commitmentaxioms and protocol specification, we can useinitiates axioms for not only the flu-ents, but also all commitments. Such specifications dictate the action effects regardlessof the current state of the world. However, an action should only initiate a base levelcommitment when the committed fluent is not already true, or when the premises butnot the conclusion of a conditional commitment are true. An action should only initi-ate a conditional commitment when neither its premises nor conclusion are true. Theaxioms in Figure 6 fail to address this, which results in the asymmetrical discharge ofcommitments (Section 3.3).

In order to make commitment discharge symmetrical (Section 3.3) we de-coupleintended causation from actual causation: instead of stating that an action initiates acommitment (e.g.,Initiates(sendGoods, promiseReceipt, t)), we state that the ac-tion is intendedto cause the initiation of the commitment (e.g.,Causes(sendGoods,promiseReceipt)). We then link the two notions by definingInitiates in terms ofCauses. Whenp is a fluent (not a commitment) then an eventInitiates the fluentpexactly when itCauses it. However, for a base level commitmentC(p) even thoughCauses(e,C(p)), the evente will not makeC(p) true if p already holds. Similarly, forCauses(e,CC(p q)), if p holds thene will createC(q), not CC(p q), and if qholds thene will have no effect. The rules in Figure 7 realise these cases and Figure 8illustrates the additional commitment discharge and creation rules. Note that the axiomsof figure 7 have been implemented and can be found in the appendix.

We then have the following action effect rules for the NetBill CM (the roles, fluentsand commitments remain unchanged):

Causes(sendRequest, request)Causes(sendQuote, offer)

Implied(p, t)← HoldsAt(p, t)Implied(C(x, y, p), t)← Implied(p, t)Implied(CC(x, y, p, q), t)← Implied(q, t)Implied(CC(x, y, p, q), t)← Implied(C(x, y, q), t)

Subsumes(p, p)Subsumes(p, C(x, y, p′))← Subsumes(p, p′)Subsumes(p, CC(x, y, q, p′))← Subsumes(p, p′)Subsumes(C(x, y, p), CC(x, y, q, p′))← Subsumes(p, p′)

Happens(e, t)← AgentTry(a, e, t) ∧ Precond(e, p) ∧HoldsAt(p, t)

Initiates(e, p, t)← Happens(e, t) ∧ Causes(e, p) ∧ isF luent(p)Initiates(e, C(x, y, p), t)← Causes(e, C(x, y, p)) ∧Happens(e, t) ∧ ¬Implied(p, t)Initiates(e, C(x, y, p), t)← Causes(e, CC(x, y, q, p)) ∧Happens(e, t) ∧ Implied(q, t)∧

¬Implied(p, t)Initiates(e, CC(x, y, p, q), t)← Causes(e, CC(x, y, p, q)) ∧Happens(e, t)∧

¬Implied(q, t) ∧ ¬Implied(p, t)Initiates(e, C(x, y, q), t)← HoldsAt(CC(x, y, p, q), t) ∧Happens(e, t)∧

Subsumes(p′, p) ∧ Initiates(e, p′, t)Terminates(e, C(x, y, p), t)← HoldsAt(C(x, y, p), t)∧Happens(e, t)∧Subsumes(p′, p)

∧Initiates(e, p′, t)Terminates(e, CC(x, y, p, q), t)← HoldsAt(CC(x, y, p, q), t) ∧Happens(e, t)∧

Subsumes(q′, q) ∧ Initiates(e, q′, t)Terminates(e, CC(x, y, p, q), t)← HoldsAt(CC(x, y, p, q), t) ∧Happens(e, t)∧

Subsumes(p′, p) ∧ Initiates(e, p′, t)

Fig. 7.Revised Commitment Machine Framework

Causes(sendAccept, accept)Causes(sendGoods, goods)Causes(sendGoods, promiseReceipt)Causes(sendEPO, pay)Causes(sendReceipt, receipt)Terminates(sendQuote, request, t)

We now explain how the revised axiomatisation and rules address the two commit-ment discharge anomalies. Let us begin with the first anomaly (Section 3.2). Considerthe following sequence of steps:

1. The customer asks for a quote2. The merchant replies with a quote. At this point the merchant has promised to send

the goods if the customer accepts, and has promised to send a receipt if the customerpays.

-

C(p) p

+C(p) +p

+p

+C(p)

-

C(p!q)

p,C(q)

p

+C(p!q)

+p

+p+C(p!q)

q

+q

p,q

+q

+q

+C(p!q)

old

new

Fig. 8.Additional Commitment Transition Rules for base level commitment (left) and conditionalcommitment (right)

3. The customer, misunderstanding the protocol perhaps, decides to accept but sendspayment instead of an acceptance.

Unlike previously, the payment causes the merchant to become committed to sendingthe goods (as well as a receipt). Through the postulate

Implied(CC(x, y, p, q), t)← Implied(q, t),the fact that thepay fluent holds indicates that the conditional commitmentCC(goods pay) implicitly holds9 at the same time. This implied conditional commitment dis-charges thepromiseGoods (CC(CC(goods pay) goods)) conditional com-mitment and creates the base level commitmentC(goods). Once the commitmentsC(goods) andC(receipt) are discharged we are in a desirable final state.

Consider now the second anomaly (non-symmetric commitment discharge, Section3.3). Using the new predicateCauses, a conditional commitment is resolved to a baselevel commitment if the premise is already true using the clause

Initiates(e, C(x, y, p), t)←Causes(e, CC(x, y, q, p)) ∧Happens(e, t) ∧ Implied(q, t) ∧ ¬Implied(p, t)

Consider the transition from state 8 to state 13, where the customer accepts af-ter the goods have been sent. The customer’ssendAccept is meant to causeaccept(CC(goods pay)), but becausegoods already holds, sending the acceptance actuallycreates the (base level) commitmentC(pay).

Figure 9 shows (part of) the state machine implicitly defined by the revised Net-Bill protocol and CM axiomatisation. The differences are in states 10, 11 and 13.Whereas previously state 10 hadpay, C(receipt) and promiseGoods, now it haspay, C(receipt) and C(goods). As a result state 11 now includes a commitment to

9 More precisely, it could be considered to hold: there is no actual commitment, because it hasbeen discharged, sincepay is true.

send the goods and is no longer a final state. State 13, which previously hadgoods,promiseReceipt andaccept now hasgoods, C(pay) andpromiseReceipt which isactually state 5, therefore state 13 no longer exists, and performingsendAccept in state8 leads to state 5. As before, final states are shaded. Also, dotted lines indicate actionsthat are affected by pre-conditions. Note that once pre-conditions are fixed (in the nextsub-section) states 10, 11 and 12 will no longer be reachable. Note also that the result-ing interaction space maintains the flexible interaction that is characteristic of the CMframework.

4.3 Issues with pre-conditions

As discussed in Section 3.4 trying to capture pre-conditions by adding conditions toInitiates clauses does not work.

Our proposed solution is to extend the agents with a proper notion of pre-conditionthat specifies when actions should not be performable (as opposed to preventing theeffects of the action from being caused). In the NetBill example we have the pre-conditionsPrecond(sendEPO, goods) andPrecond(sendReceipt, pay).

We then need to de-couple an agent wanting to perform an action from the actionactually occurring. This can be done by using a new predicateAgentTry(a, e, t) toindicate that an agenta wants to perform an actione at timet. If the pre-conditions ofthe actione hold10 at timet then this will imply that the evente happens.

Happens(e, t)← AgentTry(a, e, t) ∧ Precond(e, p) ∧HoldsAt(p, t)

Note that the definition of the interaction cannot prevent an agent from performingan action (any more than it can force an agent to honour its commitments). However, itcan specify when an action should not be performed, and detect violations, in the sameway that violations of commitments are detected.

5 Applications

Having proposed an improvement to the commitment machine framework, let us seehow it works on another example of mutual commitment. This simple (and unrealistic)example is intended to show how the improved framework sharpens the interactionsbetween the agents.

The example involves two roles, called “me” and “you”. The two roles are friendswho would like to negotiate with the outcome that both of them get an outrageoushaircut for the last day of classes. It is highly undesirable that only one person havethe haircut. There are two fluents (yourscutand minecut) representing who has hadthe haircut. We define two commitments:Dare which is the conditional commitmentCC(you, me, Ok, yourscut), i.e., the commitment from you to me that if I agree(Ok) then you will get your hair cut;11 andOk, which is the conditional commitment

10 This assumes thatp does not involve commitments. If it does then replaceHoldsAt(p, t) withImplied(p, t).

11 This is the agent equivalent of “I will if you will”.

4

5

M:sendGoods

6

C:sendEPO

7

M:sendReceipt

10

M:sendGoods

11

M:sendReceipt

M:sendGoods

1

2

C:sendRequest

3

M:sendQuote

8

M:sendGoods9

C:sendAccept

M:sendQuote

C:sendAccept

C:sendEPO

C:sendAccept

C:sendEPO

12

M:sendReceipt

M:sendGoods

C:sendEPO

Fig. 9. Revised Transitions in example (partial), final states are shaded and dotted lines depictactions that are affected by pre-conditions.

CC(me, you, yourscut,minecut), i.e., the commitment from me to you that if you geta haircut then I will get a haircut. There are four actions:cutme(which makes the fluentminecuttrue),cutyou(which makes the fluentyourscuttrue),Offer (which you can useto makeDare true), andAccept(which I can use to makeOk true). The actions of mecutting my hair (cutme) and you cutting your hair (cutyou) have the precondition thatI (respectively you) have a commitment to do so (C(me, you, minecut), respectivelyC(you, me, yourscut)).

Figure 10 shows the complete finite state machine corresponding to this CM, de-rived using the old axioms, whereas Figure 11 shows the complete finite state machinederived using the new axioms. It should be immediately clear that the new axioms yielda much simpler behaviour that correctly reflects the intentions of this very simple ex-ample.

Note also the symmetry of Figure 11, reflecting that the order in which theOfferandAcceptmessages are sent is immaterial. Hence changingDare to CC(me, you, Ok,minecut) and Ok to CC(you, me, minecut, yourscut) will result in the same ma-chine, except for the relabelling of me to you and vice-versa throughout.

On the other hand, using the old axioms (Figure 10), even this very simple examplehas anomalies. For example, consider the following sequence:

– acceptfrom state 1 to state 25:CC(me, you, yourscut,minecut)

– offer to state 26:CC(me, you, yourscut,minecut),CC(you, me, CC(me, you, yourscut,minecut), yourscut)

– accept(again) to state 3:CC(me, you, yourscut,minecut), C(you, me, yourscut)

– cutyouto state 4:yourscut, C(me, you, minecut)

– accept(again) to state 22:yourscut, C(me, you, minecut), CC(me, you, yourscut,minecut)

– offer(again) to state 23:yourscut, C(me, you, minecut), CC(me, you, yourscut,minecut), CC(you, me, CC(me, you, yourscut,minecut), yourscut)

– accept(again) to state 20:yourscut, C(me, you, minecut),CC(me, you, yourscut,minecut),C(you, me, yourscut)

– cutmeto state 11:yourscut, C(you, me, yourscut),minecut

– cutyou(again) to state 5, which is a final state.

Because of anomalies with commitment creation and discharge, the action of accept-ing can be performed four times along this path, leading each time to a distinct state.Further, in order to fulfil the commitments, you have to cut you hair twice, which iscounter-intuitive.

Note also the lack of symmetry in Figure 10. This reflects the fact that the orderin which the commitments are expressed is not immaterial (i.e. thatDare is defined interms ofOkmeans that theOfferandAcceptactions are not entirely symmetric).

3

4

cutyou 24

offer

19

offer 22

accept

5

cutme

7

8

cutyou16

offer

9

offer14

accept

cutme

10

accept

6

cutme

cutyou

11

cutme

13

offer

accept

12

offer

cutyou

accept

cutyou

cutyou

accept

cutme

15

offer

cutme

accept

cutme

accept

cutyou

20

accept

cutme

cutyou

cutme

21

offer

cutyou

cutme

accept

23

offer

cutme

accept

cutme

accept

cutyou

1

2

offer

25

accept

accept

offer

17

accept

accept

18

offer

accept

26

offer

accept

Fig. 10.Complete Finite State Machine for Haircut Example (old axioms)

3 4cutyou

5cutme

1

2

offer

6

accept

accept

offer

1 -2 Dare = CC(you, me, CC(me, you, yourscut, minecut), yourscut)3 C(you, me, yourscut), Ok = CC(me, you, yourscut, minecut)4 yourscut, C(me, you, minecut)5 yourscut, minecut6 Ok = CC(me, you, yourscut, minecut)

Fig. 11.Complete Finite State Machine for Haircut Example (new axioms)

Let us now turn to the Net Bill example. Figure 12 shows the complete state ma-chine for the interaction using the old axioms. This figure is not meant to be readable,but illustrates the size of the space and its complexity. By contrast, Figure 13 showsthe same interaction, but using the new axioms12. The old axioms generate many morestates (166 compared with 16) because of the discharge anomalies. For example, con-sider the following sequence of actions and resulting states:

1. sendQuote: results in the state with the two commitmentspromiseGoodsandpromis-eReceipt.

CC(accept goods),CC(pay receipt)2. sendAccept: creates the commitmentaccept, which results inpromiseGoodsbeing

transformed into the commitment to send the goods.

CC(goods pay),C(goods),CC(pay receipt)3. sendQuote: creates the two commitmentspromiseGoodsandpromiseReceipts. The

latter makes no difference (since it already holds), but the former is re-introduced,even though it is redundant.

CC(goods pay),C(goods),CC(pay receipt),CC(accept goods)

12 Note that the numbering of states has changed, since this figure was automatically generated.

5

6

sendQuote

8

sendGoods

7

sendRequest

145

sendGoods

150

sendAccept

sendAccept

sendQuote

sendGoods

9

sendQuote

139

sendEPO

147

sendAccept

10

sendRequest

142

sendEPO

144

sendAccept

sendGoods

sendGoods

sendQuote

11

sendAccept

124

sendEPO

sendGoods

12

sendQuote

133

sendEPO

13

sendRequest

143

sendEPO

sendAccept

sendGoods

sendGoods

sendAccept

sendQuote

14

sendEPO

15

sendQuote

109

sendReceipt

127

sendGoods

134

sendAccept

16

sendRequest

111

sendReceipt

131

sendAccept

136

sendGoods

sendEPO

sendEPO

sendQuote

17

sendAccept

sendReceipt

sendGoods

18

sendQuote

20

sendGoods

59

sendReceipt

sendEPO

19

sendRequest

112

sendReceipt

119

sendGoods

sendAccept

sendEPO

sendEPO

sendAccept

sendQuote

sendGoods

58

sendReceipt

21

sendQuote

108

sendReceipt

121

sendAccept

sendEPO

22

sendRequest

117

sendReceipt

118

sendAccept

sendGoods

sendEPO

sendGoods

sendQuote

23

sendAccept

116

sendReceipt

sendEPO

sendGoods

24

sendQuote

74

sendReceipt

sendEPO 25

sendRequest

115

sendReceipt

sendAccept

sendGoods

sendEPO

sendEPO

sendGoods

sendAccept

sendQuote

26

sendReceipt

27

sendQuote

30

sendGoods

sendAccept

sendEPO

28

sendRequest

68

sendGoods

75

sendAccept

110

sendEPO sendReceipt

sendReceipt

sendQuote

29

sendAccept

sendGoods

45

sendEPO

sendQuote

sendGoods

sendReceipt

77

sendEPO

31

sendQuote

70

sendAccept

92

sendEPO

sendReceipt

32

sendRequest

sendGoods

sendAccept

102

sendEPO

sendReceipt

sendAccept

sendGoods

sendQuote

33

sendEPO

sendReceipt

34

sendQuote

48

sendGoods

78

sendAccept

66

sendReceipt

35

sendRequest

100

sendGoods

sendEPO

114

sendAccept

103

sendReceipt

sendEPO

sendQuote

36

sendAccept

sendGoods

sendReceipt

37

sendQuote

39

sendGoods

sendReceipt

sendEPO

38

sendRequest

80

sendGoodssendEPO

sendReceipt

sendAccept

sendAccept

sendQuote

sendGoods

sendEPO

sendReceipt

40

sendQuote

82

sendAccept

sendEPO

sendReceipt

41

sendRequest

sendGoods

85

sendAccept

sendEPO

sendReceipt

sendEPO

sendGoods

sendQuote

42

sendAccept sendReceipt

sendGoods

43

sendQuote

sendReceipt

sendEPO

44

sendRequest sendGoods

sendAccept

sendEPO sendReceipt

sendReceipt

sendGoods

sendAccept

sendQuote

sendEPO

46

sendQuote

sendGoods

sendAccept

sendReceipt

47

sendRequest

sendGoods

sendEPO

sendReceipt

sendAccept

sendAccept

sendEPO

sendQuote

sendGoods

sendReceipt

sendQuote

49

sendAccept

sendEPO

95

sendReceipt

sendGoods

50

sendQuote

sendEPO

94

sendReceipt

51

sendRequest

sendGoods

sendEPO

sendAccept

113

sendReceipt

sendEPO

sendAccept

sendGoods

sendQuote

52

sendReceipt

55

sendGoods

56

sendQuote

sendReceipt

sendEPO

57

sendRequest

67

sendAccept

sendGoods

sendEPO

sendReceipt

sendGoods

sendEPO

sendAccept

sendQuote

sendReceipt

sendGoods

sendQuote

sendAccept

sendEPO

sendGoods

sendQuote

60

sendEPO sendAccept

61

sendQuote

63

sendGoods

62

sendRequest

sendAccept

sendEPO

sendReceipt

89

sendGoods

sendEPO

sendAccept

sendQuote

sendReceipt

sendGoods

sendRequest

sendQuote

sendGoods

76

sendEPO

88

sendReceipt

sendRequest

sendQuote

69

sendAccept

96

sendEPO

107

sendReceipt

sendGoods

sendRequest

71

sendQuote

sendEPO

106

sendReceipt

sendGoods

sendQuote

sendEPO

105

sendReceipt

sendGoods

72

sendRequestsendAcceptsendEPO

104

sendReceipt

sendAccept

sendGoods

sendEPO

sendQuote

73

sendReceipt

sendGoods

sendQuote

sendAccept

sendEPO

sendQuote

sendGoods

sendEPO

sendQuote

sendRequest

sendGoods

sendEPO

86

sendReceipt

sendQuote

sendRequest

79

sendAccept

87

sendReceipt

sendGoods

sendQuote

sendGoods

sendReceipt

sendAccept

sendQuote

sendGoods

sendReceipt

sendEPO

sendQuote

sendEPO

sendRequest

sendGoods

sendReceipt

sendRequest

sendQuote

81

sendAccept

sendEPO

sendReceiptsendGoods

sendRequest

83

sendQuote

sendEPO

sendReceipt

sendGoods

sendQuote

sendEPO

sendReceipt

sendGoods

84

sendRequestsendAccept

sendEPO sendReceipt

sendEPO

sendGoods

sendAccept

sendReceipt

sendQuote

sendRequest

sendQuote

sendEPO

sendGoods

sendReceipt

sendQuote

sendGoods

sendRequest

sendEPO

sendRequest

sendQuote

sendAccept

sendGoods

sendQuote

sendRequest

sendGoods

sendEPO

sendQuote

sendGoods

93

sendAccept

sendReceipt

sendGoods

sendQuote

sendEPO

sendReceipt

sendQuote

sendRequest

97

sendAcceptsendGoods

99

sendReceipt

sendQuote

sendGoods

sendRequest

sendEPO

98

sendReceipt

sendQuote

sendRequest

sendEPO

101

sendAccept

sendReceipt

sendRequest

sendQuote

sendGoods

sendEPO

sendReceipt

sendRequest

sendQuote

sendAccept

sendGoods

sendReceipt

sendGoods

sendQuote

sendRequestsendAcceptsendEPO

sendGoods

sendQuote

sendEPO

sendGoods

sendQuote

sendRequest

sendEPO

sendQuote

sendGoods

sendAccept

sendRequestsendEPO

sendGoods

sendQuote

sendAccept

sendEPO

sendAccept

sendQuote

sendGoods

sendRequest

sendQuote

sendAccept

sendGoods

sendReceipt

sendQuote

sendAccept

sendRequest

sendGoods

sendQuote

sendRequest

sendGoods

sendAccept

sendEPO

sendRequest

sendQuote

sendEPO

sendGoods

sendReceipt

sendRequest

sendQuote

sendGoods

sendAccept

sendEPO

sendGoods

sendQuote

sendAccept

sendEPO

sendQuote

sendGoods

sendAccept

sendRequest

sendEPO

sendRequest

sendQuote

sendReceipt

sendGoods

132

sendEPO sendRequest

sendQuote

sendReceipt

120

sendAccept

138

sendEPO

sendReceipt

sendGoods

sendRequest

122

sendQuote

sendEPO

sendGoods

sendReceipt

sendQuotesendEPO

sendReceipt

sendAccept

sendGoods

123

sendRequest

sendEPO

sendGoods

sendAccept

sendReceipt

sendQuote

sendEPO

125

sendQuote

sendGoods

sendAccept

sendReceipt

126

sendRequest

sendAccept

sendGoods

sendEPO

sendReceipt

sendAccept

sendEPO

sendQuote

sendGoods

sendReceipt

sendQuote

128

sendAccept

sendEPO

sendReceipt

sendGoods

129

sendQuote

sendEPO

sendReceipt

sendGoods

130

sendRequestsendAccept sendEPO

sendReceipt

sendAccept

sendGoods

sendEPO

sendQuote

sendReceipt

sendRequest

sendQuote

sendReceipt

sendGoods

sendEPO

sendQuote

sendReceipt

sendRequest

135

sendAccept

sendGoods

sendQuote

sendReceipt

sendGoods

sendAccept

sendQuote

sendGoods

sendReceipt

sendEPO

sendQuote

sendReceipt

sendGoods

sendEPO

sendRequest

sendQuote

sendRequest

137

sendAccept

sendEPO

sendReceipt

sendGoods

sendRequest

sendQuote

sendEPO

sendReceipt

sendQuote

sendGoods

sendRequest

141

sendAccept

sendReceipt

sendQuote

sendGoods

140

sendAccept sendReceipt

sendGoods

sendQuote

sendEPO

sendReceipt

sendGoods

sendQuote

sendEPO

sendRequest

sendReceipt

sendRequest

sendQuote

sendAccept

sendGoods

sendReceipt

sendRequest

sendQuote

sendReceipt

sendAccept

sendGoods

sendRequest

sendQuote

sendEPO

sendGoods

sendRequest

sendQuote

sendEPO

146

sendAccept

sendEPO

sendGoods

sendRequest

148

sendQuote

sendGoods

sendEPO

sendQuote

sendEPO

sendAccept

sendGoods

149

sendRequest

sendGoods

sendAccept

sendEPO

sendQuote

sendRequest

sendQuote

sendGoods

154

sendGoods

sendEPO

155

sendQuote

sendEPO

sendGoods

156

sendRequest

157

sendAccept

sendGoods

sendEPO

sendAccept

sendQuote

sendEPO

sendGoods

sendRequest

sendQuote

1

2

sendRequest

3

sendQuote

158

sendGoods

166

sendAccept

sendQuote

151

sendGoods

163

sendAccept

sendAccept

4

sendRequest sendGoods

sendAccept

sendQuote

sendGoods

sendGoods

sendAccept

53

sendQuote

sendEPO

sendAccept

sendGoods

sendEPO

54

sendRequest sendReceipt

sendGoods

sendEPO

sendAccept

sendReceipt

sendQuote

sendEPO

64

sendQuote

91

sendAccept

sendReceipt

sendAccept

sendEPO

65

sendRequest

sendGoods

sendReceipt

sendEPO

sendAccept

sendGoods

sendQuote

sendReceipt

sendAccept

sendGoods

sendQuote

sendEPO

sendRequest

sendQuote

90

sendAccept

sendReceipt

sendGoods

sendEPO

sendQuote

sendRequest

sendReceipt

sendGoods

sendEPO

sendQuote

sendReceipt

sendGoods

sendQuote

sendEPO

sendGoods

sendQuote

sendAccept

sendGoods

sendQuote

sendRequest

sendEPO

sendQuote

sendGoods

sendRequest

sendAccept

sendAccept

sendQuote

sendRequest

sendGoods

sendGoods

sendAccept

sendRequest

sendQuote

sendEPO

sendEPO

152

sendQuote

160

sendAccept

sendEPO

sendAccept

153

sendRequest sendGoods

sendEPO

sendAccept

sendGoods

sendQuote

sendEPO

sendRequest

sendQuote

159

sendAccept

sendEPO

sendGoods

sendRequest

161

sendQuote

sendGoods

sendEPO

sendQuote

sendEPO

sendGoods

sendAccept

162

sendRequest

sendGoods

sendEPO

sendAccept

sendQuote

sendGoods

164

sendQuote

sendGoods

sendAccept

165

sendRequest

sendAccept

sendGoods

sendQuote

sendGoods

sendRequest

sendQuote

Fig. 12.Complete Finite State Machine for Net Bill using Old Axioms. This figure is not intendedto be readable, but to illustrate the size and complexity of the interaction space.

5

6

sendQuote

8

sendGoods

sendRequest

7

sendGoods

sendRequest

10

sendEPO

sendQuote

9

sendEPO

sendQuote

12

sendReceipt

sendRequest

11

sendReceipt

1

2

sendRequest

3

sendQuote

14

sendGoods

16

sendAccept sendQuote

13

sendGoods

15

sendAccept

sendAccept

4

sendRequest sendGoods

sendAccept

sendQuote

sendGoods

sendRequest sendQuote

sendAccept

sendEPO

sendQuote

sendAccept

sendEPO

sendRequest

sendQuote

sendGoods

sendQuote

sendGoods

sendRequest

Fig. 13.Complete Finite State Machine for Net Bill using New Axioms, final states are shaded.

6 Conclusion

We analyzed the reasoning process of commitment machines and identified severalanomalies in the current reasoning mechanism. We then indicated how these anomaliescould be remedied, giving detailed rules for fixing the anomalies involving commitmentdischarge and pre-conditions.

The aim of this work is to make agent interactions more flexible and robust. Thereis a range of other work that has similar aims.

The work of Fornara and Colombetti [7] also uses commitments, but they use themto define the meanings of speech acts, rather than defining protocols in terms of theireffects on commitments.

Kumar et. al. [8] model interaction in terms oflandmarksthat need to be reached.They use the framework of joint intention theory to formalise both landmarks andspeech acts. Given the complexity of the multi-modal logics used, implementationwould seem to be a challenge, and no details of an implementation appear to be avail-able. Baldoni et. al. [9] also use a multi-modal logic to formalise interaction, in theircase within the DCaseLP environment using the DyLOG language.

Hutchison and Winikoff [10] use belief-desire-intention agents and realise inter-action using goal-triggered plans, where a given goal may have many plans that canachieve it. This work is more implementation-oriented, but is not particularly well de-veloped. It provides a set of guidelines for a human to follow when designing and im-plementing agent interaction, rather than a formally specified interaction mechanism.

Kungas and Matskin [11] use linear logic to formalise negotiation. Their approachhas been implemented, but it is not clear whether it generalises to types of interactionother than negotiation.

Chopra et. al. [12] formalise the commitment machine framework using theπ cal-culus. However, their formalisation is based on the axioms of [13] and suffers from theshortcomings discussed in this paper.

There are a number of papers in these proceedings that are concerned with verifyingagent interactions in various ways [14, 15].

There are a number of areas for future work including extending the CM frameworkto deal with protocols involving open numbers of participants (1−N ) such as auctionprotocols.

One area where we believe that commitment machines could be simplified concernspre-conditions. In a sense pre-conditions and commitments are dual: the former statethat a certain action must not be performed (under the prescribed conditions) whereasthe latter state that a certain state must be brought about. It may be that the commit-ment machines framework could be simplified by merging the two concepts into amore generalised form of commitment. Specifically, pre-conditions could be replacedby commitments toavoidcertain actions. These avoidance commitments, might be bet-ter termedprohibitions. A prohibition of the formP(x, a) would state that agentx isprohibited from performing actiona. A conditionalprohibition of the formCP(x, a, p)would state that agentx is prohibitedfrom performing actiona if p holds. For example,a merchant could have a conditional prohibition against sending a receipt if paymenthas not been made:CP(M, sendReceipt,¬pay). Prohibitions are more flexible thanpre-conditions in that they can vary over time.

An additional issue in the CM framework concerns the termination of interactions.If an interaction reaches a state where there are no base-level commitments, but thereare conditional commitments, then an agent,A, might decide that it wants to considerthe interaction finished, and delete any record of it from its memory. However, afterAdrops the interaction, agentB might act in a way that changes a conditional commitmentto a base-level commitment. The underlying issue is that a final state is only final in thesense that the interactioncouldend in that state, a final state does not require that theinteractionmustend there. As a result, an agent cannot consider the interaction to becompleted if it could be continued.

Another area for future work would be applying our changes to the presentation ofcommitment machines in [13, 16]. Whereas the presentation of commitment machinesin [1, 2] uses the event calculus to formalise commitment machines, the presentation of[13, 16] defines a process for compiling a commitment machine to a finite state machine.

Finally, the reasoning that each agent performs when deciding which action to doneeds to be specified in more detail. The reasoning could resemble a form of gameplaying where an agent wants to ensure that states that it considers undesirable cannot bereached by other agents’ actions while trying to achieve states that it considers desirable.

Acknowledgements

We would like to acknowledge the support of Agent Oriented Software and of theAustralian Research Council under grant LP0218928. We would also like to thank theanonymous reviewers and Min Xu for their comments.

References

1. Yolum, P., Singh, M.P.: Flexible protocol specification and execution: Applying event cal-culus planning using commitments. In: Proceedings of the 1st Joint Conference on Au-tonomous Agents and MultiAgent Systems (AAMAS). (2002) 527–534

2. Yolum, P., Singh, M.P.: Reasoning about commitments in the event calculus: An approachfor specifying and executing protocols. Annals of Mathematics and Artificial Intelligence(AMAI), Special Issue on Computational Logic in Multi-Agent Systems42 (2004) 227–253

3. Reisig, W.: Petri Nets: An Introduction. EATCS Monographs on Theoretical ComputerScience. Springer-Verlag (1985) ISBN 0-387-13723-8.

4. Huget, M.P., Odell, J., Haugen, Ø., Nodine, M.M., Cranefield, S., Levy, R., Padgham., L.:Fipa modeling: Interaction diagrams. Onhttp://www.auml.org under “Working Docu-ments” (2003) FIPA Working Draft (version 2003-07-02).

5. Odell, J., Parunak, H., Bauer, B.: Extending UML for agents. In: Proceedings of the Agent-Oriented Information Systems Workshop at the 17th National conference on Artificial Intel-ligence. (2000)

6. Sirbu, M.A.: Credits and debits on the internet. In Huhns, M.N., Singh, M.P., eds.: Readingsin Agents. Morgan Kaufman (1998) 299–305 (Reprinted fromIEEE Spectrum, 1997).

7. Fornara, N., Colombetti, M.: Operational specification of a commitment-based agent com-munication language. In: Proceeding of the First International Joint Conference on Au-tonomous Agents and Multi-Agent Systems, Bologna, Italy, ACM Press (2002) 535 – 542

8. Kumar, S., Huber, M.J., Cohen, P.R.: Representing and executing protocols as joint ac-tions. In: Proceedings of the First International Joint Conference on Autonomous Agentsand Multi-Agent Systems, Bologna, Italy, ACM Press (2002) 543 – 550

9. Baldoni, M., Baroglio, C., Gungui, I., Martelli, A., Martelli, M., Mascardi, V., Patti, V.,Schifanella, C.: Reasoning about agents’ interaction protocols inside DCaseLP. In Leite,J., Omicini, A., Torroni, P., Yolum, P., eds.: Declarative Agent Languages and Technologies.(2004) 250–265

10. Hutchison, J., Winikoff, M.: Flexibility and robustness in agent interaction protocols. In:Workshop on Challenges in Open Agent Systems at the First International Joint Conferenceon Autonomous Agents and Multi-Agents Systems, Bologna, Italy, ACM Press (2002)

11. Kungas, P., Matskin, M.: Partial deduction for linear logic — the symbolic negotiation per-spective. In Leite, J., Omicini, A., Torroni, P., Yolum, P., eds.: Declarative Agent Languagesand Technologies. (2004) 220–235

12. Chopra, A.K., Mallya, A.U., Desai, N.V., Singh, M.P.: Modeling flexible business processes.In Leite, J., Omicini, A., Torroni, P., Yolum, P., eds.: Declarative Agent Languages and Tech-nologies. (2004) 93–108

13. Yolum, P., Singh, M.: Commitment machines. In Meyer, J.J.C., Tambe, M., eds.: AgentTheories, Architectures, and Languages (ATAL). Volume 2333 of Lecture Notes in ComputerScience., Springer (2002) 235–247

14. Vasconcelos, W.W.: Norm verification and analysis of electronic institutions. In Leite, J.,Omicini, A., Torroni, P., Yolum, P., eds.: Declarative Agent Languages and Technologies.(2004) 141–155

15. Walton, C.D.: Model checking agent dialogues. In Leite, J., Omicini, A., Torroni, P., Yolum,P., eds.: Declarative Agent Languages and Technologies. (2004) 156–171

16. Yolum, P., Singh, M.: Synthesizing finite state machines for communication protocols.Technical Report TR-2001-06, North Carolina State University (2001) Available fromhttp://www.csc.ncsu.edu/research/tech-reports/README.html.

A Source Code for the Implemented Axioms

The complete source code is available fromhttp://www.cs.rmit.edu.au/∼winikoff/CM

New Axioms

implied(P,T) :- holdsAt(P,T).implied(c(_,_,P),T) :- implied(P,T).implied(cc(_,_,_,Q),T) :- implied(Q,T).implied(cc(X,Y,_P,Q),T) :- implied(c(X,Y,Q),T).

subsumes(P,P).subsumes(P,c(_,_,PP)) :- subsumes(P,PP).subsumes(P,cc(_,_,_,PP)) :- subsumes(P,PP).subsumes(c(X,Y,P),cc(X,Y,_Q,PP)) :- subsumes(P,PP).

happens(E,T) :- isAction(E), precond(E,P), holdsAt(P,T).

initiates(E,P,T) :- happens(E,T), isFluent(P), causes(E,P).initiates(E,c(X,Y,P),T) :- causes(E,c(X,Y,P)), happens(E,T), \+(implied(P,T)).initiates(E,c(X,Y,P),T) :- causes(E,cc(X,Y,Q,P)), happens(E,T), implied(Q,T),

\+(implied(P,T)).initiates(E,cc(X,Y,P,Q),T) :- causes(E,cc(X,Y,P,Q)), happens(E,T),

\+(implied(Q,T)), \+(implied(P,T)).initiates(E,c(X,Y,Q),T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T), subsumes(PP,P),

initiates(E,PP,T).

terminates(E,c(X,Y,P),T) :- holdsAt(c(X,Y,P),T), happens(E,T), subsumes(PP,P),initiates(E,PP,T).

terminates(E,cc(X,Y,P,Q), T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T),subsumes(QP,Q), initiates(E,QP,T).

terminates(E,cc(X,Y,P,Q), T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T),subsumes(PP,P), initiates(E,PP,T).

Old Axioms

initiates(E,P,T) :- happens(E,T), causes(E,P).initiates(E,c(X,Y,Q),T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T),

initiates(E,P,T).

terminates(E,c(X,Y,P),T) :- holdsAt(c(X,Y,P),T), happens(E,T), initiates(E,P,T).terminates(E,cc(X,Y,P,Q), T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T),

initiates(E,Q,T).terminates(E,cc(X,Y,P,Q), T) :- holdsAt(cc(X,Y,P,Q),T), happens(E,T),

initiates(E,P,T).