BDI Agent Architecture
Agent systems are becoming increasingly popular for solving a wide range of complex problems. Intentional agent systems have a substantial base in theory as well as a number of implemented systems that are used for challenging applications such as air-traffic control and space systems (Rao and Georgeff 1995). One of the strengths of the BDI Belief, Desire, Intention class of systems (including IRMA (Bratman et al. 1988), PRS (Georgeff and Ingrand 1989), JACK (Busetta et al. 1999b), JAM (Huber 1999) and UMPRS (Lee et al. 1994)) is their strong link to theoretical work, in particular that of Rao and Georgeff (Rao and Georgeff 1991), but also Cohen and Levesque (Cohen and Levesque 1990), Bratman et al. (Bratman et al. 1988) and Shoham (Shoham 1993). Although the theory is not implemented directly in the systems it does inform and guide the implementations (Rao and Georgeff 1992).
In this paper we investigate how a notion of capability can be integrated into the BDI logic of Rao and Georgeff (Rao and Georgeff 1991), preserving the features of the logic while adding to it in ways that eliminate current intuitive anomalies and mismatches between the theory and implemented systems. We understand capability as the ability to react rationally towards achieving a particular goal. Depending on circumstances a capability may not always result in an achievable plan for realising the goal, but it is a pre-requisite for such.
We describe a possible formal relationship of capabilitiesto the other BDI concepts of beliefs, goals and intentions. The addition of capabilities enriches the existing formal model and allows for definition of a self-aware agent which takes on and remains committed to goals only if it has a capability to achieve such goals. The formalisation we introduce deals only with a single agent, but we indicate directions for development that would be suitable for dealing with rational behaviour in a multi-agent system which takes into account the known capabilities of other agents.
This work is partially motivated by the recently reported development and use of a capability construct in JACK, a java based BDI agent development environment (Busetta et al. 1999b), which follows the basic abstract interpreter described in (Rao and Georgeff 1992). We indicate how capabilities can be integrated into this abstract interpreter and also indicate some issues for consideration in implementation of capabilities that are highlighted by this work. This work can be seen as part of the ongoing interplay between theory and practice in the area of BDI agent systems. It provides a foundation for exploring some of the practical reasoning mechanisms involving capabilities and for further developing the theory as well as informing the ongoing implementations.
Using Capabilities in Reasoning
Most BDI systems contain a plan library made up of plans which are essentially abstract specifications for achieving certain goals or doing subtasks on the way to achieving a goal. Each plan is associated with a triggering event (which may be an event of type achieve goal X). Each plan may also have a list of pre-conditions or a context which describes the situation in which the plan is intended to be used. The context condition may be used to bind variables which are then used in the plan body. The plan body is the code which executes the plan. This may contain invocations of subgoals which allow new plans to flesh out the detail of the plan, calls to external “actions”, or other code in the plan or host language.
We understand having a capability to achieve X as meaning that the agent has at least one plan that has as its trigger the goal event achieve X. That is the agent has at least one way it knows how to achieve X in some situation. At any given time the agent may be unable to actually use this plan (depending on whether its pre-conditions match the state of the world), but having some such plan is clearly a prerequisite to being able to achieve X.
In the description of the implementation of capabilities in JACK (Busetta et al. 1999a) a capability is essentially a set of plans, a fragment of the knowledge base that is manipulated by those plans and a specification of the interface to the capability. The interface is specified partially in terms of what events generated external to the capability, can be handled by this capability. Thus a part of the interface to a capability will be a list of the goal achievement events that the capability is designed to handle. Additional subgoal events and the plans that deal with these can be hidden within the internals of the capability. The interface also specifies what events generated by the capability are to be visible externally and gives information as to what portion of the knowledge base fragment is used by the capability.
As an example a scheduling capability may contain a set of plans to construct a schedule in a certain domain. The knowledge base fragment defined as part of this capability may have knowledge about the objects to be scheduled, their priorities, and various other information that is generated and used as a schedule is being built. There may be a single external goal event called achieve-schedule which this capability responds to while the only events it generates that are seen externally are events which notify the schedule or which notify failure to generate a schedule.
It is easy to see how this abstraction of a set of plans into a capability could be used to advantage in finding plans that are a possibility for responding to a specific event. Rather than examining all plans it is only necessary to look within the plans of either the generating capability, or a capability that has the relevant event specified as part of its external interface. Naturally this relies on appropriate software engineering design and will preclude the system “discovering” a plan within the internals of a capability that achieves a goal that is not specified as part of the interface of the capability. This is consistent with the practical reasoning approach inherent in these systems which relies on forward chaining based on specified triggers (combined with the ability to manage failure and retry alternative mechanisms to achieve goals and subgoals). The abstraction of sets of plans into capabilities also provides a mechanism for name scoping which is a practical help in building large and complex systems.
Busetta et al. (Busetta et al. 1999a) describe how agents can be built by incorporating specific capabilities. A growing amount of work in multi-agent systems discusses agents with varying “roles”. If an agent changes roles dynamically the expectation is that their behaviour also changes. One way to achieve this could be to use capabilities. A capability could specify and implement the things that an agent could do within a particular role. As an agent changed role, appropriate capabilities could then be activated or de-activated.
While a capability (in general language usage) cannot be regarded as a mental attitude similar to beliefs, desires, goals and intentions, beliefs about capabilities (both one’s own and others) are clearly important mental attitudes for reasoning about action.
When we talk about goals and intentions we expect that they are related to aspects of the world that the agent has (at least potentially) some control over. While it is reasonable to talk about an agent having a desire for it to be sunny tomorrow, having a goal for it to be sunny tomorrow makes little intuitive sense - unless of course our agent believes it can control the weather. Just as goals are constrained to be a consistent subset of the set of desires, we would argue that they should also be constrained to be consistent with its capabilities (at least within a single agent system - this needs to be modified for multi-agent systems but the notion of capability remains relevant; for multi-agent systems one must also consider capabilities of agents other than oneself). As intentions are commitments to achieve goals these also are intuitively limited to aspects of the world the agent has some control over. Consequently, we would wish our agent’s goals and intentions to be limited by its capabilities (or what it believes to be its capabilities).
Capabilities may also provide a suitable level at which agents in a multi-agent heterogeneous system have information about other agents. An agent observing an (external) event that it may not itself have the capability to respond to, may pass on the event to another agent if it believes that agent has the capability to respond to the event. (Beliefs about) capabilities of other agents may also provide a mechanism for supporting co-operation. An agent in a multiagent system may contact or try to influence some other agent with the required capability, or alternatively may make decisions about its own actions based on the believed capabilities of other agents. Goals of an agent in a multi-agent system are likely to be constrained (in some way) by the capabilities of other agents as well as one’s own capabilities.
We explore a possible formalisation of capabilities within BDI logic that lays the initial foundation for addressing some of these issues. We first summarise the BDI logic of Rao and Georgeff and then explore how this can be extended to incorporate capabilities - currently in the context of a single agent reasoning about its own capabilities, although we are also working on extending this to multi-agent systems.