AFAPL
From Agent Factory
Contents
|
Introduction
The Agent Factory Agent Programming Language (AFAPL) is the original programming language that was developed for Agent Factory. Underpinning this language is the idea that agents adopt commitments to one or more courses of action, which they then attempt to realise. This model of commitment management has been formalised as a first-order branching time multi-modal logic. For details on the logic, please see Rem Collier's Ph.D. thesis, which can be found on the Publications page. For your convenience, the sections below include the analysis of commitment, the choice of mental state architecture, and a discussion of the resultant constructs that were developed for AFAPL.
Editorial History
20/03/2008: Version 1 - Cut and Paste from thesis to provide initial discussion.
History
The initial implementation of this language, developed in Smalltalk-80, was completed in the mid-1990's. In 2000, a lightweight version of Agent Factory (i.e. the interpreter minus all tools and infrastructure components) was developed in Java to facilitate the deployment of Agent Factory agents on Personal Digital Assistants. The Smalltalk version of Agent Factory was discontinued in 2002 as the Java implementation as sufficient tool support was developed).
An Analysis of Commitment
Here we explore the concept of a commitment and how it can be used to drive the activities of an agent.
What is a Commitment?
Broadly speaking, a commitment can be is viewed as an agreement that is made by an agent to do something. In other words, a commitment is the mental equivalent of a contract. As such, it specifies the course of action that the agent has agreed to, to whom this agreement has been made, when it must be fulfilled, and under what conditions the agreed course of action becomes invalid (i.e. under what conditions the contract can be breached). Finally, the agreed course of action can take one of two forms: (1) a directly executable action, or (2) a plan of action.
Directly executable actions can be modelled through a unique identifier that is associated with each of the agent’s actions. This identifier is termed an action identifier.
Plans of action can be modelled in two ways: either through the direct encoding of the plan, or through the association of a unique identifier with each plan the agent knows.
In this thesis, both approaches are considered. The second element of a commitment – the agent to whom the agreement has been made – can be modelled through the use of agent identifiers. An agent identifier is a unique identifier that is associated with each agent. In the context of a commitment, this identifier may identify the agent itself, or another agent. The commitments that an agent makes to itself are known as personal commitments. Conversely, the commitments of an agent that are to other agents are known as social commitments.
The time element is used to represent when the agent should fulfil the commitment. This is known as the start time of the commitment. In an ideal world, the agent would perform the associated action at the allotted time. However, in reality, this is not always possible since the environment may not be in a state whereby the pre-conditions of the action are satisfied. This could lead to the action being performed unsuccessfully.
In some cases, not realising the commitment at the allotted time results in the failure of the commitment. For example, lifting a heavy box on the count of three. Such commitments are time-critical, in that, not realising the commitment at exactly the allotted time results in its failure. However, there are many cases where commitment is not time-critical. For example, an agent may adopt a commitment to meet a friend for coffee at five o’clock. If the agent is not at the coffee shop by five o’clock, but arrives at two minutes after five, the agent has still successfully realised their commitment to meet the friend for coffee.
The point being made here is that the failure of the commitment to lift the box is due to the commitment being time-critical. That is, the commitment could only be maintained so long as the allotted time for its realisation had not passed (i.e. if the agent lifted the box before or after the allotted time, then the commitment would fail). As a result, in AFAPL, we adopt the view that time criticality not a core feature of commitment, but rather the maintenance of commitments.
Based upon this analysis, we choose to deal with the temporal aspect of commitment by requiring that an agent fulfil its commitments at or as soon as possible after the allotted time. Thus the time element is taken to denote the time at which the commitment should be considered for fulfilment and not the time at which the commitment should be fulfilled. The time criticality of a commitment is dealt with from the perspective of commitment maintenance.
The final element relates to the maintenance of commitments. A naïve view of commitment maintenance considers a commitment to be maintained until it is fulfilled. This type of commitment maintenance is commonly termed blind commitment (Rao and Georgeff, 1991). For practical purposes, such a view of commitment is impractical. For example, consider an agent that maintains a commitment to buy a computer through an auction even though the price of the computer has gone above the amount of money that its owner can afford. Consequently, it is common to place restrictions upon a commitment that define under what conditions a commitment should be maintained. These restrictions are commonly known as maintenance conditions.
In AFAPL a maintenance condition is viewed as any partial situation definition that must be true at each time point until the commitment is fulfilled. (Rao and Georgeff, 1991) identifies two types of maintenance condition: single-minded commitment considers a commitment to be maintained so long as the agent believes it can be achieved, and open-minded commitment considers a commitment to be maintained so long as the agent believes that it is one of its’ goals.
Rao and Georgeff employ these types of maintenance condition as a property of the underlying reasoning process of an agent. That is, the maintenance condition is a meta- condition that is common to all decisions made by an agent. In this thesis, a more practical perspective is taken. Here, the maintenance condition is viewed as a specific property of each commitment. That is, each commitment has a unique maintenance condition.
This perspective on the maintenance condition is in line with our metaphor of commitment as a contract. A contract is commonly accepted subject to various terms and conditions. For example, an employment contract commonly contains a condition stating that any information pertaining to the company should remain private to the company (i.e. company secrets should remain secrets). Should an employee make any of this information public without the prior consent of the company then the client will be in breach of contract. Thus, the acceptor of the contract remains an employee of the company (i.e. the contract remains valid) so long as they abide by all the terms and conditions of that contract.
In summary, a commitment is formed through a combination of the following attributes:
- the name of the agent to whom the commitment was made,
- the start time of the commitment,
- the maintenance condition of the commitment, and
- the course of action the agent is committed to.
Commitment Lifecycle
Broadly speaking, a commitment will be adopted at one time point, and then retracted at some later time point. In the interim between these time points, the commitment might also be fulfilled. This is illustrated in figure 1.
Agents adopt commitments within one of two contexts. They are adopted either as a result of a decision by the agent to do something or as a refinement of an existing commitment of an agent.
Commitments adopted in the former context are known as primary commitments since they guide the overall behaviour of the agent. They occur due to a result of personal decisions (i.e. it needs to do something to satisfy its internal desires), or as a result of social interaction (i.e. it does something to help another agent).
Fulfilling a commitment requires that the agent “make good” its commitment to a particular course of action. This requires the agent to either action, to locate a relevant plan, or to refine its commitments based upon the given plan body. Refinement leads to the adoption of additional commitments.
Finally, commitment retraction occurs either because the agent has fulfilled its commitment, or because the agent decides that the commitment should no longer be maintained (this is identified by the maintenance condition associated with the commitment becoming invalid).
The Commitment Structure
Over a period of time, one would expect to see an agent first adopt a primary commitment, and then work to fulfil that commitment through the (possible) adoption of additional commitments. These additional commitments are then fulfilled until one of the following occurs: the primary commitment is fulfilled, one of the additional commitments fails, or the primary commitment is retracted. Each commitment is made to a chosen course of action. This course of action is either a primitive action or a plan. The agent fulfils a commitment to a primitive action through the performance of the specified action. Conversely, the agent fulfils a commitment to a plan through the refinement of the plan and the subsequent adoption of a set of sub-commitments. The agent fulfils the commitment to the plan indirectly through the fulfilment of each of the sub-commitments.
This view of commitments driving the adoption of other commitments, which, when fulfilled bring about the fulfilment of the initial commitment, has an implicit tree-like structure within it as illustrated in figure 2.
For practical purposes, the hierarchical relationship between commitments is not sufficient. Additional relationships are forged between commitments as a consequence of the types of operator employed within the plans from which non-primary commitments are derived. In this thesis, we consider four such operators: sequence (SEQ), parallel (PAR), unordered choice (OR), and ordered choice (XOR). In general, we will use the term choice operator to describe both non-deterministic and deterministic choice.
The sequence operator defines a set of steps (step is a generic term that denotes either a plan operator, a plan identifier, or an action identifier) that must be realised in the order specified. For example, consider the plan associated with boiling some water in a kettle. This plan contains two steps: (1) fill the kettle with water, and (2) switch the kettle on. The ordering of these steps is vital to the successful realisation of the plan; should step (2) be realised before step (1), the result would be a kettle full of cold water. Thus, the sequence operator defines a temporal ordering on the fulfilment of the underlying steps of the associated plan. This ordering must be reflected in the fulfilment of the resultant commitments. The consequence of this is that the temporal relationship between the commitments must be modelled as part of the commitment structure.
The parallel operator defines a set of steps that may be realised in any order. For example, consider the plan associated with the task of making a cup of tea. This plan involves: (1) boiling some water, (2) putting a teabag in the cup, and (3) pouring the boiling water into the cup. Whilst there is an obvious temporal ordering between steps (1) and (3), there is no temporal ordering upon when (2) should be performed. This may occur before (1), between (1) and (3), or after (3). Thus, (2) may be performed in parallel with (1) and (3).
The effect of the parallel operator on the ordering of commitments may be modelled by viewing the temporal relationship identified for the sequence operator to be a partial ordering of pairs of commitments (i.e. the relationship takes the form of a directed graph).
The unordered choice operator defines an unordered set of steps, of which only one must be successfully realised. In this sense, a non-deterministic choice operator is equivalent to a parallel operator with the exception that only one of the associated steps must be successfully fulfilled. For example, consider the plan associated with the task of boiling water. This plan may require either (1) the boiling of water in a kettle, or (2) the boiling of water in a pan. Either of these steps would individually achieve the overall task of boiling some water.
Finally, the ordered choice operator defines an ordered set of steps, of which only one must be successfully realised. In this sense, a deterministic choice operator is equivalent to a sequence operator with the exception that only one of the associated steps must be successfully fulfilled. For example, consider the plan associated with the task of boiling water. This plan may require either (1) the boiling of water in a kettle, or (2) the boiling of water in a pan. Either of these steps would individually achieve the overall task of boiling some water. In particular, the agent first attempts to fulfil (1), and if this fails, then attempts to fulfil step (2).
Two issues arise from the inclusion of a choice operator (either a deterministic or a non-deterministic choice operator). These issues relate to various additional constraints that are placed upon the maintenance of commitments and the handling of failure of commitments. These issues are discussed later in more detail. However, the inclusion of a choice operator has no effect upon the modelling of the commitment structure. We now illustrate these relationships through a simple example. In this example, an agent adopts a primary commitment, a, to the following plan body:
SEQ(act1, PAR(act2, OR(act3, act4)), act5)
Here act1 is the action of pouring water in the kettle; act2 is the action of boiling the kettle; act3 is the action of putting Nescafe in the cup; act4 is the action of putting Kenco in the cup; and act5 is the action of pouring water from the kettle into the cup. The agent refines this commitment through the generation of three sub-commitments,a1, a2, and a3. These commitments are made to the action act1, the plan body PAR(act2, OR(act3, act4)), and the action act5 respectively.
Further, these commitments are constrained by a temporal ordering such that a1 must be fulfilled before a2, which must be fulfilled before a3. The resultant hierarchical and temporal relationships are illustrated below in (a) and (b) of figure 3.
In this figure, we also introduce a third diagram (c), which we entitle the commitment structure. This encapsulates both relationships within a single form. To increase the expressiveness of this diagram, we include various types of connector (arrows) that represent the different operators that link the commitments. A list of these connectors is presented in figure 4.
Figure 4(a) describes a situation where the agent refines a plan body whose outermost operator is a SEQ operator (e.g. SEQ(act1, act2, act3)). This results in the adoption of three commitments (a1, a2, a3) that have a temporal ordering between them (this ordering is represented by the arrows).
Figure 4(b) describes a situation where the agent refines a plan body whose outermost operator is a PAR operator (e.g. PAR(act1, act2, act3)). This results in the adoption of three commitments (a1, a2, a3) that have no temporal ordering between them (thus, the connectors are lines and not arrows).
Figure 4(c) describes a situation where the agent refines a plan body whose outermost operator is a OR operator (e.g. OR(act1, act2, act3)). This results in the adoption of three commitments (a1, a2, a3) that have no temporal ordering between them (thus, the connectors are lines and not arrows). To distinguish between an OR operator and a PAR operator, the OR connector is denoted as a dotted line.
Figure 4(d) describes a situation where the agent refines a plan body whose outermost operator is a XOR operator (e.g. XOR(act1, act2, act3)). This results in the adoption of three commitments (a1, a2, a3) that have a temporal ordering between them (this ordering is represented by the arrows). To distinguish between an OR operator and a PAR operator, the OR connector is denoted as a dotted line.
We now use this diagrammatical notation to describe how the commitment structure evolves with the fulfilment of the example plan identified above. The refinement of the commitment to this plan is illustrated in figure 3(c).
Let us assume that the above state of the system occurred at time point, t1. At some later time point, say, t2, the agent fulfils commitment a1. This leads to the situation represented by diagram (a) in figure 5.
At this point in time, the temporal ordering that constrained the fulfilment of commitment a2 is removed. Thus, at some time point, t3, the agent decides to fulfil this commitment. However, this commitment is also to a plan body. Again, the agent must refine this commitment as specified in the plan. The result is two commitments a21 and a22, which are made to the courses of action act2 and OR(act3, act4) respectively. Further, commitment a1 was to a plan body in which the constituent steps were to be achieved in parallel. Hence, there is no temporal ordering on a21 and a22. The resultant commitment structure is presented in figure 5(b).
Now, the agent is able decide whether to fulfil commitment a21, commitment a22, or both commitments. Let us assume in this example that the agent chooses to fulfil commitment a22 only. The result is another refinement of the commitment structure resulting in the adoption of commitments a221 and a222 to steps act3 and act4 respectively. Thus, at some later time point, t4, the resultant commitment structure takes the form presented in figure 5(c).
As a consequence, the agent is now able to fulfil commitment a21, commitment a221, commitment a222, or any combination of the three. Let us assume that it decides to fulfil commitments a21 and a222. Upon fulfilment of these commitments, at some time point, say t5, the resultant commitment structure takes the form presented in figure 5(d).
It should be noted that the commitment structure at time point, t5, has been significantly pruned. In essence, the fulfilment of commitment a222 results in the fulfilment of commitment a22 because it is an optional commitment. Further, when combined with the fulfilment of commitment a21, commitment a2 is also fulfilled. The result is that only commitment a3 remains to be fulfilled. Once this occurs, both commitment a3, and the primary commitment, a, are retracted.
In summary, for a single primary commitment, the commitment structure employed within this thesis is a combination of a hierarchy, and a graph. The hierarchy models the relationship between commitments to plans and the resultant commitments generated from the refinement of that plan; and the graph models the temporal ordering enforced upon these commitments by the associated plans.
Uniqueness of Commitments
In AFAPL, two commitments are viewed as unique if any of the attributes of both commitments differ. That is, for two commitments to be the same, the name, start time, maintenance condition, and action of those commitments must be the same.
AFAPL requires that the commitments of an agent be unique.
Commitment Interleaving
Given that commitments must be unique, it is vital to understand what should happen when an agent attempts to adopt a commitment that is the same as one of its existing commitments. In such a scenario, two basic options exist: (1) fail the adoption of the commitment, or (2) perform commitment interleaving. Commitment interleaving occurs only when an agent attempts to adopt a commitment that is the same as one that currently exists. In such cases, the agent cannot adopt the new commitment without contravening uniqueness of commitments. Consequently, it must reuse the existing commitment instead of adopting the new commitment. By reusing the existing commitment it is said that we interleave the agents commitments.
Interleaving of commitments can occur either within a single commitment structure, or between two commitment structures. Generic examples of each of these scenarios are presented in figure 6 below. In these examples, we illustrate only the hierarchical relationship between agents. This is because interleaving affects only the hierarchical relationship between commitments.
In particular, case 1 of figure 6 presents a scenario in which commitments A and B have been refined. For both commitments, this refinement process resulted in the adoption of a commitment C. Upon the refinement of the second of commitments A and B (irrelevant of the order in which the refinement occurred), the second attempt to adopt commitment C causes the agent to interleave its commitments. The consequence of interleaving these commitments is that the hierarchical relationship between the commitments is no longer a tree, but is now a graph.
The second case of figure 6.7 presents a similar scenario to the first case with the exception that the commitments A and B are in different commitment structures. The result of this is that the interleaving causes the trees to be linked by a common commitment, C. However, internally, both of these structures are still tree-like.
The main effects of interleaving commitments are that:
- The fulfilment or failure of the interleaved commitment (C in figure 6.7) has a greater impact upon the overall success or failure of the agents primary commitments.
- Additional dependency conditions may be placed upon the fulfilment of the commitment (section 6.2.6.2) since it must account for the temporal orderings resulting from both commitment A and commitment B.
To further motivate the use of interleaving, considerable effort was made to describe a real world example in which interleaving would have a positive effect upon the actions of the agent. However, identifying such an example proved to be considerably more difficult than expected, and even lead to the identification of a counter-example that illustrates an undesirable side effect of commitment interleaving. This counter example is presented below.
Consider an agent-based sales application in which a sales agent receives two orders for two identical widgets (generic products) simultaneously. As a result of these orders, the agent attempts to adopt two identical commitments (X and Y) requesting that a widget be retrieved from the widget warehouse. These commitments are adopted sequentially (although the particular order of adoption does not matter here). When attempting to adopt the second commitment, the agent detects that it is not unique and interleaves them. The result is that the agent has a single commitment (say X), to request that a widget be retrieved from the widget warehouse. Thus, the agent continues operating,and at some later point finds that it is one widget short (as it only requested one widget). This problem arises because the agent really wants to adopt two commitments to request a widget from the warehouse, but as a consequence of interleaving, only adopts one commitment.
It is obvious from this example that, to adequately model interleaving of commitments something more is needed. However, such issues were not considered in this version of AFAPL. As a result, we do not consider interleaving within the remainder of this thesis. Instead, we adopt the former option identified at the start of this section, namely to fail any attempt to adopt a commitment when it is identical to an existing commitment of the agent.
Commitment Conditions
Earlier, we defined the lifecycle of a commitment in terms of three distinct phases: adoption, retraction, and fulfilment.We now discuss the respective conditions that are employed within the commitment model to manage the transition of commitments between these phases.
Commitment Adoption
Commitments are adopted principally as a result of the triggering of some commitment rule. A commitment rule is a tuple that maps a situation onto one or more commitments that should be adopted should that situation arise. The situation part of a commitment rule is termed the adoption condition of the associated commitments. Further, any commitment that is adopted as a result of the triggering of some commitment rule is known as a primary commitment.
A second scenario that results in the adoption of commitments by the agent is as a result of the refinement of a commitment to a plan (or plan body). This refinement occurs whenever the agent decides to fulfil the commitment to the plan. Consequently, the conditions relating to this section scenario are discussed in the next section.
Fulfilment Conditions
Commitment fulfilment is where an agent “makes good” on its commitments. That is, the agent decides to realise one or more of its commitments. When the agent fulfils a commitment is governed by three conditions that must be satisfied. The first condition to be satisfied is known as the dependency condition. This condition relates to the orderings that exist between the commitments of an agent. In particular, it requires that any commitments that must be fulfilled before this commitment be fulfilled. This can be best illustrated by considering the example of boiling water in a kettle.
When boiling water in a kettle, there is an ordering implicit in the actions that take place. First you must remove the kettle lid, next you fill the kettle with water, then you replace the kettle lid, and finally, you switch on the kettle. If you do not adhere to this ordering, then the likelihood is that you will fail to boil the water. Thus, when fulfilling a commitment to boil water in a kettle, the agent adopts commitments to each of the actions identified above.
Within the model of commitment employed within AFAPL, the agent cannot realise its commitment to fill the kettle with water before it realises the commitment of removing the kettle lid. This ensures that planned actions of the agent get carried out in the order intended.
The second condition to be satisfied is a temporal condition and requires that the agent only attempt to fulfil its commitment at, or as soon as possible after the start time. Once the start time has been reached, a third constraint is placed upon the fulfilment of the commitment: that the pre-conditions of the associated action/plan be satisfied. This third constraint is applied to ensure both that there is some guarantee of success for the commitment, and that the commitment does not cause any undesirable side effects.
In particular, if the agent did not require the pre-condition of the action to be satisfied, then it is perfectly possible to conceive of a scenario in which the agent performs a course of action that is detrimental (and possibly even harmful). For example, consider a “driver agent” that fulfils the commitment of leaving the garage at 10:05am even though the garage door has not yet been opened.
In summary, for a commitment to be fulfilled:
- it must not be dependent upon the completion of any other commitments,
- it must be at or after the start time of the commitment, and
- the pre-condition of the associated plan/action must be satisfied.
Retraction Conditions
Commitments are retracted when they expire. A commitment is viewed as expired when it enters a SUCCEEDED or FAILED state. This arises either through an attempt by the agent to fulfil the commitment, or through the failure of the maintenance condition.
As a result, the only conditions placed upon commitment retraction are that the commitment is in either a SUCCEEDED or FAILED state.
Maintenance Conditions
Commitment maintenance refers to the introspective abilities of an agent to understand when certain of its commitments become untenable (i.e. it is no longer in the interests of the agent to maintain the commitment). This arises because the environment is in a state that makes the commitment unachievable.
Within AFAPL, this is modelled primarily through the association of a maintenance condition for each commitment of each agent. This condition describes what must hold true in the environment for the commitment to be maintained. Should the maintenance condition fail at any point in the lifecycle of the commitment then the agent must consider that commitment to have failed (i.e. it is set to a FAILED state).
A second condition placed upon the maintenance of a commitment relates specifically to commitments that are adopted when refining some plan body whose outermost operator is a choice operator. Should the agent successfully fulfil one of the child commitments (i.e. those commitments adopted through the refinement process) associated with this commitment then, by default, any other associated child commitments must fail (i.e. they must be set to a FAILED state).
Commitment States
During its lifetime, a commitment enters various states that reflect the progress that has been made in realising the commitment:
- WAITING. This state is used to represent the situation where either the temporal condition of a commitment is false, or where there are preceding commitments to be realised (i.e. it is part of a plan – see Commitments and Plans later).
- INACTIVE. This state is used to represent when the temporal condition of a commitment is satisfied and there are no preceding commitments to be realised.
- ACTIVE. This state is used to represent where a commitment to an action has been realised.
- PLANNED. This state is used to represent where a commitment to a plan has been refined into a set of sub-commitments (see Commitments and Plans later - note that in future versions of AFAPL, this was also modeled as the ACTIVE state).
- SUCCEEDED. This state is used to in two contexts: (1) when a commitment to an action has been realised – this relates to the successful performing of the action; and (2) when a plan the agent has committed to as a result of a commitment (to a plan) has been realised.
- FAILED. This final state reflects the case where a commitment has failed. This may arise because either: the associated action has failed, or some sub- commitment has failed.
Commitment Fulfilment
A commitment is fulfilled through the realisation of the course of action to which the commitment has been made. This course of action may take one of two forms: it may be a commitment to an action, or a commitment to a plan.
In the former case, the commitment is fulfilled directly through the realisation of the associated action. In this scenario, the successful fulfilment of the commitment depends completely upon the successful realisation of the associated action. For example, if the agent has a commitment to inform another agent of a bid as part of the contract net protocol, then the fulfilment of the commitment is achieved through the realisation of a communicative act that results in the sending of an inform message to the appropriate agent.
In the latter case, the commitment is fulfilled through the adoption of an additional set of commitments that represent a refinement of the original commitment based upon some selected plan. In this scenario, the successful fulfilment of the commitment depends entirely upon the successful fulfilment of each of the associated sub- commitments adopted by the agent. For example, if an agent has a commitment to boil some water, then the fulfilment of that commitment is achieved through the adoption of a set of sub-commitments relating to some plan of action that results in some water being boiled (e.g. the plan to boil water in a kettle).
Failure of Commitments
As described earlier, it is possible that, under certain conditions, a commitment can fail. The failure of a commitment can occur due to two basic scenarios:
- The course of action to which the commitment has been made is unsuccessfully realised.
- The maintenance condition of the commitment becomes invalid.
Should either of these scenarios arise, the commitment should be set to FAILED and subsequently removed from the commitment set of the agent. In this section, we discuss the impact of the failure of a commitment on the associated commitment structure.
This discussion is tackled in two stages. First, we discuss the effect of commitment failure upon a commitment structure that contains no optional commitments. Following this, we move on to discuss how commitment failure affects commitment structures that do contain optional commitments.
When a commitment structure contains no commitments to a plan body whose outermost operator is a choice operator (hereafter called a commitment to a choice operator) the result of commitment failure is straightforward: upon detection of a failed commitment, every commitment in the associated commitment structure is caused to fail. Thus, the ultimate result of the failure of any commitment is the failure of the primary commitment of the commitment structure.
This, however, is not necessarily the case when the commitment structure does contain a commitment to a choice operator. The result of a commitment failure in this case depends upon the position of the failed commitment with respect to the occurrence of the commitment to a choice operator. In particular, two potential scenarios may arise - the failed commitment can either be in a sub tree of a commitment to a choice operator, or not in a sub tree of a commitment to a choice operator.
If the failed commitment does not occur within a sub tree of a commitment to a choice operator then the impact of the failure is the same as before (i.e. the whole commitment structure fails). However, if the failed commitment occurs within a sub tree of a commitment to a choice operator then only part of the commitment structure may fail (although, it is still possible that the whole commitment structure will fail).
To illustrate this, we describe two scenarios – one that still leads to the failure of the whole commitment structure, and one that leads to the failure of the sub-commitment structure whose root node is the relevant commitment to a choice operator. We deal with the second scenario first.
The purpose of the choice operator is to define a set of options available to the agent, only one of which must be successfully realised. The options are manifested through a set of commitments - one commitment for each of the options available. We illustrate this through the example of boiling some water. In particular, the plan body below defines two options available to the agent when required to boil some water:
XOR(boil_water_in_kettle, boil_water_in_pan)
In this example, we make use of a deterministic choice operator, however, the result would be the same for a non-deterministic choice operator. In this example plan body, the agent attempts to boil the water by first attempting to boil it in a kettle, and, should this fail, by attempting to boil it in a pan.
In addition to the above plan, we also define the plan associated with the boil_water_in_kettle plan identifier. This plan is presented below:
SEQ(fill_kettle, switch_on_kettle)
For the sake of clarity, we illustrate this example through the use of a commitment hierarchy (the hierarchy relation of the commitment structure) only. Figure 8 illustrates the commitment hierarchy at the point where the agent is attempting to fulfil its commitment to boil_water_in_kettle.
This figure identifies the commitments that the agent currently has. If in this scenario, the commitment to fill_kettle fails then the result of this failure is that all commitments in the boil_water_in_kettle sub tree also fail. However, the top commitment does not fail since there is still another option available.
Should this scenario continue, and the commitment to boil_water_in_pan (or one of its sub-commitments) fails, then the outcome is different. In this second scenario, there are no more options available to the agent when this commitment is retracted. As a result, the top commitment must also be considered to have failed (i.e. none of the options attempted by the agent led to the successful fulfilment of the commitment to the choice operator).
Commitment Management
Commitment management refers to the meta-level process that manages the evolution of the commitments of an agent. It is delivered through a set of sub-processes that support various aspects of the commitment lifecycle:
- Commitment Adoption. This aspect deals with the adoption of new commitments be the agent.
- Commitment Fulfilment. This aspect deals with controlling how an agent fulfils its commitments.
- Commitment Retraction. This aspect deals with the retraction of existing commitments of the agent.
- Commitment Update. Commitment update refers to the process by which the state of the agents’ commitments is updated to reflect any changes to their state. For example, this process is responsible for ensuring that a commitment in a WAITING state is changed to an INACTIVE state when there are no longer any commitments that are temporally before it.
- Commitment Maintenance. This aspect deals with the analysis of whether or not an existing commitment should be maintained or whether it should be considered to have failed.
- Commitment Failure Handling. This aspect deals with the handling of the failure of an individual commitment and the impact of that failure upon the other commitments in the associated commitment structure.
Structuring Commitment Management
Commitment management is the meta-process that manipulates the commitments of an agent to ensure that the agent achieves (where possible) all the tasks it has been assigned. The model of commitment management employed within the AF-APL is founded upon a set of logical axioms that are developed as part of the logic of commitment that underpins the language.
This model of commitment management is formulated about the delivery of five key processes:
- The Commitment Adoption Process deals with the adoption of new commitments.
- The Commitment Fulfilment Process deals with how the agent fulfils its commitments. This includes action realisation and plan selection.
- The Commitment Retraction Process deals with the retraction of existing commitments of the agent.
- The Commitment Update Process deals with the update of the state of the existing commitments of an agent (i.e. moving from a WAITING state to an INACTIVE state).
- The Commitment Maintenance Process deals with the analysis of whether or not an existing commitment should be maintained, or whether it should be considered to have failed.
- Finally, the Commitment Failure Handling Process deals with the handling of the failure of an individual commitment and the impact of that failure upon the other commitments of the agent.
When implementing commitment management support, the above processes must be ordered. We briefly reflect upon this ordering below:
- Commitment Retraction must occur after Commitment Failure Handling. If this ordering is not enforced, then the agent may remove failed commitments before analysing the impact of that failure.
- Commitment Fulfilment must occur after Commitment Maintenance. If this ordering is not enforced, then the agent may attempt to fulfil commitments it does not intend to maintain.
- Commitment Fulfilment must occur after Commitment Failure Handling. If this ordering is not enforced, then the agent may attempt to fulfil commitments that have failed as a consequence of the failure of some other commitment.
- Commitment Failure Handling must occur after Commitment Maintenance. If this ordering is not enforced, then the agent may fail commitments but mot be able to analyse the impact of that failure.
- Commitment Fulfilment must occur after Commitment Update. If this ordering is not enforced, then the agent may not consider a commitment for fulfilment when it is ready to be fulfilled.
- Commitment Update must occur after Commitment Adoption. If this ordering is not enforced, then the agent will not consider newly adopted commitments.
- Commitment Maintenance must occur after Commitment Adoption. The agent must ensure that the commitments it has just adopted should be maintained.
- Commitment Update must occur after Commitment Maintenance. The agent should not update commitments that are not to be maintained.
- Commitment Update must occur after Commitment Failure Handling. The agent should not update commitments that have failed.
Together, these constraints induce a specific ordering upon the occurrence of each of the Commitment Management Processes. This ordering is reflected in figure 9 below.
The AFAPL Language
To Be Completed...
The mental state architecture adopted for AF-APL is comprised of four mental attitudes: belief, action, plan, and commitment. The first three attitudes are informational attitudes, whilst the fourth is a pro-attitude. These are supported within AF-APL through the Belief, Action, Plan, and Commitment Constructs.
In the specification of the four mental constructs, the notion of a belief sentence was introduced. A belief sentence is a valid aggregation of one or more belief constructs and various logical connectives that have been implemented within the Agent Factory System.
The belief construct identified in section 7.3.2 is used to represent the beliefs of an agent at a particular point in time. By default, a belief is valid only for that point in time. Within the context of specifying agent behaviours, it is sometimes desirable to be able to represent beliefs that are more persistence, or even to be able to describe what beliefs should be valid for the next iteration. To support this, AF-APL has been extended to include various temporal constructs such as NEXT, and ALWAYS. These constructs are similar to the temporal operators commonly associated with temporal logic and are introduced in section 7.3.7.









