Multi-Agent Planning with Decommitment∗

Gerhard WicklerAIAI, University of Edinburgh

Edinburgh, Scotland

Antonin KomendaAgent Technology Center,

Czech Technical University in Prague

Michal PechoucekAgent Technology Center,

Czech Technical University in Prague

Austin TateAIAI, University of Edinburgh

Edinburgh, Scotland

Jiri VokrinekAgent Technology Center,

Czech Technical University in Prague

December 19, 2008

Abstract

One of the problems that must be solved dur-ing coalition operations is the planning problem:finding a course of actions for the operation.Knowledge-based planning is a technique that canbe used to address this problem. However, tra-ditional planning has focussed on the finding of aplan that achieves a given goal or accomplishes agiven task. During a coalition operation such a planmay need to be agreed between the different par-ties involved in the coalition. In this paper we shalldescribe an approach that can be used for findingan agreed plan. This plan will include a set of de-commitment rules allowing participants to specifyconditions under which they are allowed to deviatefrom the agreed course of action. The proposed al-gorithm can be used as the basis for an automatedplanner, but it should also be usable in a mixed-initiative setting.

∗Sponsored by the European Research Office of the USArmy under grant number W911NF-08-1-0041. The au-thors’ organizations and research sponsors are authorized toreproduce and distribute reprints and on-line copies for theirpurposes notwithstanding any copyright annotation hereon.The views and conclusions contained herein are those of theauthors and should not be interpreted as necessarily repre-senting the official policies or endorsements, either expressedor implied, of other parties.

1 Introduction

The classical planning problem [Ghallab et al.,2004, section 2.3] has been extended in a numberof ways. One of these extensions is the distributed(multi-agent) planning problem [Durfee, 1999]. Infact there is more than one problem that can bedescribed by this term. In this paper, we will addyet another aspect to the problem by requiring thata plan which is a solution to the planning problemmust be an agreed plan [Wickler, 2008].

The application that motivates this problem iscrisis response and management. The scenario hereis that a number of agencies want to provide reliefafter a disaster has struck. These agencies usuallyhave different (but overlapping) capabilities and noauthority over each other. Truthfulness and a col-laborative attitude are assumed in this scenario.

1.1 The Collaborative Multi-PeerPlanning Problem

The distributed planning problem here is dis-tributed in the sense that both, the agents creatingthe plan and the agents executing the plan are dis-tributed. More specifically, we consider a group ofagents that has a set of goals for which they mustfind a plan and which assigns actions in the planto agents for execution. The initial state and the

1

goals are assumed to be known and the same forall agents. It is assumed that all agents want tocollaborate to achieve the common goals.

Furthermore, agents may have different capabil-ities in which case the assignment of actions mustbe to agents that are capable of performing them.Capabilities may be overlapping, meaning actionscan be performed by more than one agent, therebymaking the assignment of actions to agents a non-trivial task.

Another important issue is authority. Whilethere may be agents that have authority over otheragents and thus can assign actions to those agents,we will not assume that there is a single agent thathas authority over all others. This means the plan-ning problem cannot be solved by having one agentplan for all others. Only those agents with author-ity over other agents will be allowed to plan forthem, and in that case the problem can be reducedto one in which only the sub-group of agents that(between them) have authority over all others needto be considered, where this sub-group is a groupof peers.

1.2 Agreed Plans

Note that it is not difficult to solve the above prob-lem as a classical planning problem. That is, it issimple enough to find a sequence of actions thattransforms the initial state into a goal state. How-ever, for the problem instances we envisage everysolution must involve more than one agent andsince no agent has authority over any other, noagent can come up with a plan that it can ensurewill be executed. Peers may refuse the activitiesassigned to them, or multiple agents may want toexecute the same activities that are required to getto a given goal state.

The heart of the distributed planning problem istherefore not the finding of a plan, but the findingof an agreed plan. Informally, by an agreed planwe mean a classical plan in which for every actionin the plan there is an agent to which this action isassigned. Furthermore, this agent must commit tothe actions assigned to it in the plan, that is, theagent intends to execute these actions and takes onan obligation to its peers to execute them. Achiev-ing this commitment is usually not considered partof the classical planning problem, but for the plan-ning problem with multiple peers it is vital.

Figure 1: The Scenario Island (Pacifica)

1.3 The Example Scenario

The approach presented in this paper is being ver-ified in a simulated environment with reasonablyrealistic features. Figure 1 shows a basic map ofthis environment, an island inspired by the Paci-fica suite of scenarios1. On the island, there arecities and a network of roads connecting them, butoff-road movement is also enabled. There are alsoseveral seaports and airports. The actors are ofseveral unit types (ground, armored, aerial or seaunits), and may be civilians or non-friendly units.The latter do not play a role in the kind of scenariowe envisage here, but have been used in other re-search that uses the same environment.

The general scenario is located on this islandwith a potentially non-friendly environment andlimited information visibility and sharing. Due tothis, the environment provides non-deterministicbehavior from the single agent point of view. Inthe specific scenario we are interested in here, thereare heterogenous independent self-interested agentsthat adopt the shared/joint goals. To fulfill the de-sired strategic goals in this environment, the agentsprovide complex capabilities on several levels ofplanning and control.

Strategic plan generation is provided by a setof commander agents that are responsible for eachtype of field unit (ground, aerial, sea and armored)over which they have authority. The number and

1http://www.aiai.ed.ac.uk/oplan/pacifica

2

specialization of commanders reflects the desiredscenario setting. The field units are dedicated to aparticular commander and receive their tasks fromthis commander. The hierarchical structure of tac-tical planners then creates tactical plans for eachfield unit (tactical planners are part of each unit’stactical layer). Tactical plans are confronted withthe multi-agent simulation developed for the envi-ronment and adapted to the actual feedback pro-vided by the simulator in real-time. Execution ofthe plan by the individual unit is simulated and in-tegrated with the environment feedback from thesimulation engine.

There are a number of heterogeneous agent typesoperating in the scenarios, e.g.:

• Commanders: abstract units (not geograph-ically situated) that represent Ground, Ar-mored, Aerial and Sea headquarters.

• Stationary units: such units include:

– Cities which provide assembly points forcivilians;

– Supply depots and Petrol pumps whichprovide resources of various types;

– Airfields which are landing and refuelingzones for aerial units; and

– Seaports which are docking and refuelingzones for sea units.

• Mobile units: agents with the ability to moveon the island, including:

– Transporters: ground units, which arecan provide transportation of otherunit(s), material or civilians;

– Construction units: can repair damagesor assemble/disassemble stationary units;

– Medical units: provides medical care forother units or some rescue operations;

– Armored units: for the protection ofother units or to secure an area or con-voy;

– Aerial units: UAVs with an extended vis-ibility range; and

– Sea units: for transportation over water.

2 <I-N-C-A> and Task-Centric BDI

In this section we will formally define the conceptsthat form the basis for our definition of the col-laborative multi-peer planning problem and, moreimportantly, what constitutes a solution to thisproblem. We will begin with activities that formthe basic ingredients of a plan. Based on thiswe will define activity networks as objects in the<I-N-C-A> ontology [Tate, 2003]. Activity refine-ments provide a way of breaking an activity downinto sub-tasks. This will provide a fairly stan-dard HTN planning framework [Sacerdoti, 1975;Tate, 1977]. To extend this to the collaborativemulti-peer planning problem and finding agreedplans we need to define mental states of agentsand we shall do so using a BDI approach [Rao andGeorgeff, 1991]. Specifically, we will define differenttypes of beliefs that agents have about the worldand each other. Finally, we will briefly discuss theconcept of capabilities as this is important for theplanning as well as the mental states of agents.

2.1 Activities

Activities can be defined in a number of ways de-pending on what needs to be expressed in the plan-ning domain. To ground our definition of the col-laborative multi-peer planning problem we shalladopt a simple, strips-like activity model. Othermore expressive representations may be used here,e.g. adl [Pednault, 1989]. What we mean by anactivity schema corresponds to a strips operator.

An activity schema consists of three components:

• s: the signature of the activity scheman(v1, . . . , vk) where

– n is the unique name of the activityschema and

– v1, . . . , vk are variables representing theparameters of the activity schema;

• C: the set of preconditions of the activityschema which can be literals in first-order logicor state variable assignments;

• E: the set of effects of the activity schemawhich can be literals in first-order logic or statevariable assignments.

3

By an activity we mean a partially instantiatedactivity schema. That is, some of the variables rep-resenting parameters may be replaced by symbolsreferring to objects in the domain and there may bemore than one instance of the same activity schemain a plan. We can use the signature plus a uniquelabel to refer to activities.

By an action we mean an activity that is fullyinstantiated, i.e. all the parameters are ground.

If o is an activity schema then we use o.s to referto the signature of the schema, o.C to refer to thepreconditions of the schema, and o.E to refer to theeffects of the schema. This notation disambiguatesthe meaning of overloaded symbols. In general, wewill use lower case letters for components that areobjects of some kind whereas upper case letters areused for components that are sets of things.

For example, in the scenario described above, asimple activity schema could represent the trans-porting of some item from one location to anotheras follows:

(:activity-schema:signature (transport ?item ?loc1 ?loc2):preconditions (at ?item ?loc1):effects (at ?item ?loc2) ¬(at ?item ?loc1))

An action (e.g. in a plan) would then fullyspecify the parameters, e.g. (transport food12city34 depot56). Preconditions and effects areinherited from the activity schema with the givenaction name.

2.2 Activity Networks: <I-N-C-A>

Activities are organized in networks to form plans.We consider such a network to consist of 4 compo-nents described by an <I-N-C-A> object:

• I: the set of issues in the activity network, e.g.flaws or opportunities;

• N : the set of activities in the network (at alllevels of refinement);

• C: the set of constraints associated with thenetwork, e.g. ordering, time or resources;

• A: a set of annotations, e.g. rationale.

If p is an <I-N-C-A> activity network we use p.I,p.N , p.C, and p.A to refer to the issues, activities,

constraints, and annotations of this plan respec-tively. A more detailed and formal description ofthe <I-N-C-A> framework can be found in [Wickleret al., 2006].

2.3 Activity Refinements

Refinements are used to break down high-level ac-tivities that are part of an <I-N-C-A> activity net-work into (primitive) actions in HTN planning. Anactivity refinement consists of the following compo-nents:

• n: the unique name of the refinement;

• a: the signature of the activity to be refined(also called the task);

• A: the set of sub-activities that constitute therefinement;

• C: some constraints on activities in A.

If there is no refinement available for a given ac-tivity then we assume that this activity is primi-tive and there should be an agent that can executethis activity. If there is a refinement available for agiven activity we consider this activity abstract andit needs to be refined before it becomes executable.

For example, in the scenario described above, thefollowing simple refinement could be used to specifyhow to accomplish the task of moving an item fromone location to another:

(:refinement move-by-truck:signature (transport ?item ?loc1 ?loc2):activities (

1 (load ?item ?truck)2 (drive ?truck ?loc1 ?loc2)3 (unload ?item ?truck))

:constraints(at ?truck ?loc1)(ordering 1 2 3))

2.4 Beliefs Desires and Intentions

Activities, activity networks, and activity refine-ments together form an HTN-style planning frame-work that does not treat agents in any special way.For the collaborative multi-peer planning problemwe need to define the internal structure of an agentin more detail (see also [Wickler et al., 2007]) and

4

we shall assume a BDI-like framework here. Thatis, the mental state of an agent can be described bya set of beliefs (B), desires (D), and intentions (I).

Both, desires and intentions, are representedas <I-N-C-A>-objects, which are plans in our ap-proach. This is simply to fit in with our HTN plan-ning framework. Desires include all those activitiesthat an agent would like to perform at some pointin the future. These activities can be abstract orprimitive, and they may or may not executable.

Intentions include activities that an agent hasscheduled for execution. Non-primitive activitiesmust be refined by the planner until all intentionsare primitive activities and the agent believes themto be executable (when they are due to be exe-cuted). Intentions need not be immediate, that is,they are usually scheduled for an execution time inthe future.

An agent may also be committed to performingsome of its intentions which are activities in ourtask-centric view. Thus, in addition to the usualmental attitudes defined in BDI, an agent has a setof commitments C where each commitment consistsof the following components:

• a ∈ I.N : the activity the agent has pledged toperform;

• p: the precondition under which the agent haspledged to undertake a;

• A: the set of agents to which the pledge wasmade; and

• Λ: a set of decommitment rules, where eachλ ∈ Λ consists of:

– ρ the precondition under which the agentis allowed to drop the intention a;

– ψ the alternative plan that the agent willadopt instead of a.

The commitment precondition p reflects the pre-conditions a.C for the applicability of a as an ac-tivity (as defined above). Should an agent believein a decommitment precondition ρ of one of the de-commitment rules, it can drop the activity a fromits current set of intentions and adopt the postcon-dition ψ of the selected decommitment rule.

2.5 Belief Types

To define the collaborative multi-peer planningproblem, the beliefs of an agent must include var-ious types of beliefs about the activities that canbe performed by the different agents defined in theplanning problem. Thus, we shall divide the beliefsinto the following components:

• S: the usual knowledge about the world state,which will mostly be used to verify the precon-ditions for activities and refinements are satis-fied;

• C: the set of capability descriptions known tothe agent, i.e. a set of pairs (a, o) where ais the agent that has advertised the capabilityand o is the signature of an activity schemathat describes the advertised capability;

• R: the set of activity refinements known to theagent;

• P : the set of primitive activities that thisagent can execute (and knows that it can).

For example, the commander in charge of seaunits could advertise the capability to transportitems from one location to another. Additional con-straints may be given with a capability advertise-ments, such as the fact that the two locations inquestion must both be sea ports.

The refinements R would be a set of refinementsas described above. The set of primitive activitiesare different for the agents in our example as eachagent only needs to know the activities it itself canexecute.

For example, a truck agent knows that it candrive from one location to another if there exists aroad that connects the two locations. It may stillrequire some form of planning to work out moredetail, but the agent must know that it can alwaysexecute this action if the preconditions are satisfied.

2.6 Capabilities

The notion of capabilities described so far is ac-tually too simplistic for practical applications. Itis assumed that capabilities are described usinga shared ontology of activity descriptions. Sincean agent associates only the signature of an activ-ity with another agent in a capability description,

5

there needs to be a description associated with thatsignature that all agents agree on. A hierarchicalontology of activities would be more useful for thispurpose than the simple model described above.

Also, it is not realistic to assume that an agentwill advertise as part of its capability descriptionall the constraints that it considers preconditionsfor the application of this capability. For example,one precondition that applies to every capabilitydescription is that the agent is not already oth-erwise committed. That is, agents that can onlyperform one action at a time may in principle becapable of performing an advertised capability, butthey may not be able to perform it at any requestedtime. As intentions and commitments are expectedto change relatively frequently but advertised ca-pabilities are expected to remain constant, suchscheduling constraints should not be part of a ca-pability advertisement.

Another practical concern is that agents usuallyonly perform their advertised capabilities as partof a larger protocol which in itself can be seen asa plan. For example, an agent might expect to bepaid for performing its capability and there maybe actions that correspond to that process that thecapability requester needs to perform.

3 Formalizing the Collabora-tive Multi-Peer PlanningProblem

We can now formalize the collaborative multi-peerplanning problem. In addition to the traditionalcomponents of a planning problem (operators, ini-tial state, and goal) this requires a set of agentswith their mental (BDI) states as described above.The next step must then be a definition of whatconstitutes a solution to such a problem. This willdefine the semantics of the problem.

3.1 The Problem Specification

A collaborative multi-peer planning problem isgiven by a pair (A,N) where A describes a set ofagents and N is an initial activity network.

The first component, A = {a1, . . . , an}, consistsof a set of agent descriptions where each agent ai

is defined by its beliefs ai.B, its desires ai.D, its in-

tentions ai.I and its commitments ai.C as describedabove. Note that the beliefs include beliefs aboutthe world state, the capabilities of the agent itselfas well as other agents, available refinements forbreaking down tasks, and primitive activities theagent can execute. Having refinements as part ofthe agents’ knowledge means they do not need tobe listed explicitly as part of the planning problem.

The second component N is an <I-N-C-A> ac-tivity network consisting of issues N.I, activities(nodes) N.N , constraints N.C, and annotationsN.A. In this HTN-style specification of a planningproblem it is not necessary to list the initial stateand the goal separately as they can be defined inthe initial network with two dummy activities initand goal as is usual in HTN planning.

We shall assume that there are no inconsisten-cies in the planning problem and that all agentshave complete knowledge of each other’s capabili-ties. The former implies that the initial state im-plicit in N and the agents’ beliefs about the cur-rent world state ai.B.S are equivalent. The latterimplies that for all agents ai, aj their beliefs aboutcapabilities are the same, i.e. ai.B.C = aj .B.C.

3.2 Solutions

The above definition of a collaborative multi-peerplanning problem is not significantly different fromclassical HTN planning, except that the agents thatexecute actions are made explicit. Note that thisalready creates a different solution space if one as-sumes that agents can only execute one action at atime.

The solutions we are looking for must includean important additional condition: they must beagreed by all the agents in the problem. This canbe formalized by requiring that every action that ispart of the plan and is assigned to an agent mustbe an element of that agent’s intentions, i.e. everyagent is committed to executing its share of theplan as a result of the planning process.

An agreed solution to a collaborative multi-peerplanning problem (A,N) is a pair (N ′, s) where:

• N ′ is a ground, primitive activity network and

• s is an assignment of activities in N ′ to agentsin A

such that:

6

• there exists a decomposition tree ∆ from N toN ′

• every action is assigned to an agent, i.e.∀a ∈ leafs(∆) : s(a) ∈ A

• assignments are to agents capable of perform-ing the activities, i.e.∀a ∈ leafs(∆) : a ∈ s(a).B.C

• agents are committed to performing activitiesassigned to them, i.e.∀a ∈ leafs(∆) : a ∈ s(a).I∧∃c ∈ s(a).C : c.a = a ∧ c.p = a.C ∧ c.A = A

In order to make possible the execution of a col-lection of distributed plans that constitute the so-lution to a multi-peer planning problem we need tomake the participating agents not only agree withexecution of the respective plans but to commit totheir execution. Unlike agreement, a mere expres-sion of conformity with the proposed plans, thecommitment is a richer knowledge structure rep-resenting agents attitude to the agreed piece of ex-ecution. While the intention to perform an actionis somewhat equivalent to agents agreement to per-form an action, the commitment also specifies un-der which circumstances the agent can get decom-mitted from its commitment, thereby opening up agenuinely larger solution space for the collaborativemulti-peer planning problem.

4 An Approach

We will now discuss a solution approach to thecollaborative multi-peer planning problem whichdraws some parallels to the idea behind auctionsas a method for solving the problem of finding anagreed price.

4.1 Auctions and Agreement

One way of viewing an auction is as a process foragreeing on something. A group of agents want tobuy an item one of them has to sell, and they needto agree who will buy the item and at what price.To do so, they hold an auction. That is, they firstagree on a process they will follow and that willresult in the agreed price and buyer. Then they

execute that process and have the desired agree-ment at which point the buyer and seller are com-mitted. Thus, instead of directly seeking the agree-ment they are after, they first agree on a processthat leads to the agreement, and then following thisprocess leads to commitments.

4.2 Finding Agreed Plans

The question then is what such a process could looklike in the case of the collaborative multi-peer plan-ning problem. One possible procedure is based onthe idea of each agent solving the overall problemas if it had authority over the other agents, then ne-gotiating additional constraints that may not havebeen part of the capability descriptions, and finallyvoting for the agreed plan if necessary:

repeatevery agent:

solve HTN planning problemsuggest plan that self would agree to

for every plan:every agent:

add constraints on own activitiesadd decommitment rules on own activities

every agent:modify suggested plan with new constraints

until no agents add further constraintsvote for solution planevery agent:

commit to the agreed plan

The agents start by solving the planning problemas a classical planning problem, treating all capa-bilities as available primitive activities. This mayseem like a waste of computational resources butit is unlikely that agents will accept other agents’plans without thinking about the way in which thecommon goal can be achieved themselves. Fur-thermore, HTN problems tend to be solvable with-out too much effort for most practical domains forwhich there is a known set of standard operatingprocedures. It is assumed here that agents all wantto accomplish the common goal, but every agentmay have different criteria for what they considerthe best solution, which is why they may come upwith different plans at this stage.

In the next step agents can suggest the solutionsthey would like to see implemented to the other

7

agents. This can be done by using a shared data-structure such as a blackboard, or by means ofagents requesting each other to provide solutionspeer-to-peer. There is no requirement for everyagent to suggest a plan; they may just rely on oth-ers, e.g. if there is a peer they fully trust. In theworst case there could be no suggested plans andthis simply reflects the fact that there might not beany solution plans to the classical problem, just likethere might not be an agreeable price for an auc-tion. Assuming that there are n peers involved inthe planning, there may now exist (up to) n initialcandidate plans representing alternative solutionsat this point in the algorithm.

4.3 Adding Constraints

Once the plans have been suggested, agents canconstructively critique each others candidate plans.This can be done by adding further constraints tothe activities in the plan. For example, an agentmay be assigned an activity that conforms with itsadvertised capabilities as part of some other agent’splan, but it may not be able to perform the capa-bility at that time or in the specific circumstances.Adding such a constraint at this stage will invali-date the plan and the agent who suggested the planmay then modify its candidate solution to take intoaccount any additional constraints that have beenadded. The agent may wait with the modificationuntil all peers that are assigned actions in the planhave had an opportunity to add constraints. Themodification of the candidate solution may be a mi-nor fix or a completely different plan, but it has tobe a valid solution to the planning problem includ-ing all the new constraints.

4.4 Adding Decommitment

Instead of constraints that invalidate a plan, anagent may add decommitment rules to activities as-signed to it in another agent’s candidate solution.These rules do not invalidate the plan but specifyhow it might be changed at execution time, givencertain conditions. Just like the activities in theplan, these decommitment rules need to be agreedby all peers.

There is a number of different decommitmentrule types suggested for adoption:

• Full decommitment: The basic decommit-ment strategy is dropping the commitmentwithout any further task to be accomplished.Under defined circumstances the agent is com-pletely released from the commitment.

• Delegation: By using this type of the decom-mitment rule the agent shall be able to findsome other agent who will be able to completeits commitment on the original agent’s behalf.It is possible that such a commitment will con-tain unbound variables representing the needto search for an agent suitable for delegation.The basic idea is to find an agent that isable to undertake the commitment under cir-cumstances when the decommitment condition(which is true in case of the original agent) be-came false, so the new agent is able to fulfillthe commitment. The delegated commitmentcan contain a new set of decommitment rules.

• Relaxation: Relaxation is a special decom-mitment, where the original commitment is re-placed with a new commitment with relaxedproperties of the task. Such decommitmentrule is often used when the agent needs to spec-ulate about its potential inability to provide re-quest quality of service, delivery time or costs.It has been shown that planning with relax-ation decommitments rules can contribute toan increased efficiency of coordinated actionsin dynamic environments [?].

Since decommitment rules do not invalidate thesuggested plan, there is no need for the suggestingagent to modify its candidate in response to a de-commitment rule being added. However, the sug-gester may still decide to do so if it believes anotherplan to be now preferable.

4.5 Voting

This process is continued until no agent adds fur-ther constraints or decommitment rules to any ofthe plans, in which case the set of candidate plansis hopefully not empty. Note that each of theseplans represents a valid classical solution. Now theagents need to choose one of these solutions andthis can be achieved by voting, provided that eachagent is able to construct a preference ordering ofthe plans. This preference ordering would be linked

8

with utility functions representing cost and/or ben-efits that each plan represents for the respectiveagent. Note that at this stage all the plans avail-able for voting are plans the participating agentsare happy to adopt and thus the voting is simply ameans for selecting one of the plans. Various votingprotocols (e.g. plurality protocol, binary protocol,Borda protocol) can be adopted here.

If the voting process terminates successfully, theselected plan is an abstract solution to the multi-agent planning problem. As the voting processselects the plan from the constrained candidateplans, each annotated with particular decommit-ment rules, all involved agents commit to the se-lected plan.

5 Conclusions

This paper defines a new kind of distributed, multi-agent planning problem, the collaborative multi-peer planning problem. In this problem a groupof peers (agents without authority over each other)have to agree on a plan that achieves a commongoal. Agents are defined with BDI-style mentalstates, and a plan is considered agreed if the actionsin the plan are assigned to agents that are commit-ted to executing these actions. This commitmentis an important aspect that needs to be part of theoutcome of the planning process. The proposedapproach introduces a level of indirection into theplanning process—instead of agreeing the plan di-rectly the peers agree on the procedure for findingthe plan and then execute this procedure. The re-sulting plan may include decommitment rules forcertain activities in the plan, giving agents thatparticipate in the execution a certain degree of flex-ibility.

This approach is particularly relevant for coali-tion operations in which participants in the coali-tion are peers and the lack of authority over eachother adds a new source of problems to the plan-ning process.

The proposed planning algorithm is very effi-cient, but it is not aimed at fining an optimal so-lution plan. Agents get committed to pre-selectedplan that is presumably optimal (to some degree)according to the suggesting agent’s criteria, butmore importantly, it should at least acceptable toall agents involved. There may be potential for an

improvement of e.g. stability of the plan or longerterm use of resources should the agents have theopportunity to choose between quality of the pro-vided solution and various offered decommitmentstrategies.

References

[Allen et al., 1990] James Allen, James Hendler,and Austin Tate, editors. Readings in Planning.Morgan Kaufman, 1990.

[Durfee, 1999] Edmund H. Durfee. Distributedproblem solving and planning. In Gerhard Weiss,editor, Multiagent Systems: A Modern Approachto Distributed Artificial Intelligence, chapter 3,pages 121–164. The MIT Press, 1999.

[Ghallab et al., 2004] Malik Ghallab, Dana Nau,and Paolo Traverso. Automated Planning. Mor-gan Kaufmann, 2004.

[Pednault, 1989] Edwin Pednault. ADL: Exploringthe middle ground between STRIPS and the sit-uation calculus. In Proc. 1st International Con-ference on Knowledge Representation and Rea-soning (KR), pages 324–332. Morgan Kaufmann,1989.

[Rao and Georgeff, 1991] Anand Rao and MichaelGeorgeff. Modeling rational agents within a BDI-architecture. In Proc. 2nd International Con-ference on Knowledge Representation and Rea-soning (KR), pages 473–484. Morgan Kaufmann,1991.

[Sacerdoti, 1975] Earl D. Sacerdoti. The nonlin-ear nature of plans. In Proc. 4th InternationalJoint Conference on Artificial Intelligence (IJ-CAI), pages 206–214. Morgan Kaufmann, 1975.Reprinted in [Allen et al., 1990, pages 162–170].

[Tate, 1977] Austin Tate. Generating project net-works. In Proc. 5th International Joint Con-ference on Artificial Intelligence (IJCAI), pages888–893. Morgan Kaufmann, 1977. Reprinted in[Allen et al., 1990, pages 291–296].

[Tate, 2003] Austin Tate. <I-N-C-A>: A sharedmodel for mixed-initiative synthesis tasks. InGheorghe Tecuci, editor, Proc. IJCAI Workshop

9

on Mixed-Initiative Intelligent Systems, pages125–130, 2003.

[Wickler et al., 2006] Gerhard Wickler, StephenPotter, and Austin Tate. Recording rationalein <I-N-C-A> for plan analysis. In Lee Mc-Cluskey, Karen Myers, and Biplav Srivastava,editors, Proc. ICAPS Workshop on Plan Anal-ysis and Management, pages 5–11, 2006.

[Wickler et al., 2007] Gerhard Wickler, StephenPotter, Austin Tate, Michal Pechoucek, and Ed-uard Semsch. Planning and choosing: Augment-ing HTN-based agents with mental attitudes.In Proc. International Conference on IntelligentAgent Technology, 2007.

[Wickler, 2008] Gerhard Wickler. Finding agreedplans. In Ruth Aylett and Yvan Petillot, editors,Proc. 27th Workshop of the UK Planning andScheduling Special Interest Group (PLANSIG),pages 137–142, 2008.

10