Intentional agents in AgentSpeak(L) & Jason

1. Implementing BDI architectures

The deck opens where Chapter 7 ended: the BDI architecture is a theory of practical reasoning, and the question now is how to implement it. The abstract control loop of BDI agents [Rao and Georgeff, 1995] gives the skeleton that every concrete architecture — PRS, dMARS, AgentSpeak(L), Jason — will fill in its own way:

1. initialize-state();
2. while true do
3.   options := option-generator(event-queue);
4.   selected-options := deliberate(options);
5.   update-intentions(selected-options);
6.   execute();
7.   get-new-external-events();
8.   drop-successful-attitudes();
9.   drop-impossible-attitudes();
10. end-while

The loop is the bridge between perception and action: events enter, options are generated from them, deliberation filters the options into intentions, intentions are executed, and the loop cleans up after itself — dropping attitudes that have been fulfilled (successful) or that can no longer be pursued (impossible). Notice what never appears in the loop: a global planner. Deliberation is a repeated, cheap step, not an expensive one-shot search — this is the deliberate/reactive tension of Chapter 7, resolved by interleaving.

Concrete BDI systems are built out of six constructs:

• a set of beliefs;
• a set of desires (or goals);
• a set of intentions — better, a subset of the goals with an associated stack of plans for achieving them; these are the intended actions;
• a set of internal events — elicited by a belief change (updates, addition, deletion) or by goal events (a goal achievement, or a new goal adoption);
• a set of external events — perceptive events coming from the interaction with external entities (message arrival, signals, etc.);
• a plan library (repertoire of actions) as a further, static component.

The architecture of a BDI agent [Wooldridge, 2009] wires these constructs together: sensors feed a belief revision function (BRF) that updates beliefs; an option generator produces options (desires) from beliefs and events; a filter turns desires into intentions; intentions drive action through effectors. The agent is literally the loop around that pipeline.

2. PRS: the first BDI architecture

Before AgentSpeak(L), the deck places the ancestor: the Procedural Reasoning System (PRS) [Georgeff and Lansky, 1987], one of the first BDI architectures. PRS is a goal-directed and reactive planning system:

• goal-directedness allows reasoning about and performing complex tasks;
• reactiveness allows handling real-time behaviour in dynamic environments.

PRS was applied for high-level reasoning of robots, airport traffic control systems, and the like. Its architecture is the blueprint that AgentSpeak(L) will simplify into a language:

• a Data Base of beliefs — the agent’s model of the world;
• a KAS (Knowledge Area Set) of plans — the procedural know-how;
• a Goals structure of desires;
• a Stack of intentions — the currently selected plans;
• an Interpreter (the reasoner) that runs the cycle;
• a Monitor feeding perceptions from sensors, and a Command Generator emitting actions to effectors.

3. AgentSpeak(L): the language

AgentSpeak(L) is an abstract language used for describing and programming BDI agents. Its pedigree is explicit:

• inspired by PRS, dMARS [d’Inverno et al., 1998] and BDI Logics [Rao and Georgeff, 1995];
• originally proposed by Anand S. Rao [Rao, 1996];
• extended so as to make it a practical agent programming language [Bordini and Hübner, 2006];
• programs can be executed by the Jason platform [Bordini et al., 2007];
• it has an operational semantics for extensions of AgentSpeak(L), providing a computational semantics for BDI concepts.

The main language constructs are three, mapping directly onto the BDI ontology:

• beliefs — current state of the agent: information about the environment and about other agents;
• goals — states the agent desires to achieve and about which it reasons (practical reasoning) based on internal and external stimuli;
• plans — recipes of procedural means the agent has to change the world and achieve its goals.

The architecture of an AgentSpeak agent has four main components: a belief base, a plan library, a set of events, and a set of intentions. Everything else in the language — syntax and semantics — is a disciplined answer to the question: how do these four components interact?

4. Syntax: beliefs, goals and events

AgentSpeak(L) borrows the logical vocabulary the course already built in Chapters 8 and 9. Beliefs: if b is a predicate symbol and t1, ..., tn are (first-order) terms, then b(t1, ..., tn) is a belief atom; ground belief atoms are base beliefs; if Φ is a belief atom, then Φ and ¬Φ are belief literals.

Goals: if g is a predicate symbol and t1, ..., tn are terms, then !g(t1, ..., tn) and ?g(t1, ..., tn) are goals:

• ‘!’ marks achievement goals (goal to do) — pointing at practical actions;
• ‘?’ marks test goals (goal to know) — pointing at epistemic actions.

This single distinction encodes two kinds of questions an agent can pursue: “bring it about that…” (achievement) versus “find out whether…” (test). It is the language-level counterpart of Chapter 3’s distinction between acting on the world and knowing the world.

Events occur as a consequence of changes in the agent belief base or goal states. Events signal to the agent that some situation is requiring servicing (triggering events), and the agent is supposed to react to such events by finding a suitable plan — or plans. Because of events and goal processing, AgentSpeak(L) architectures are both reactive (they answer to external and internal change) and proactive (they pursue goals).

If b(t) is a belief atom and !g(t), ?g(t) are goals, the six triggering events are:

• +b(t) — belief addition;
• −b(t) — belief deletion;
• +!g(t) — achievement-goal addition;
• −!g(t) — achievement-goal deletion;
• +?g(t) — test-goal addition;
• −?g(t) — test-goal deletion.

Let Φ be a literal: the triggering events are +Φ, −Φ, +!Φ, −!Φ, +?Φ, −?Φ. The key intuition: change itself is an event. Adding a belief, dropping a goal — each such change generates an event that can trigger a plan.

5. Syntax: plans

Plans are recipes for achieving goals. They declaratively define a workflow of actions; they come along with the triggering and the context conditions that must hold in order to initiate the execution; they represent the agent’s means to achieve goals — its know-how.

If e is a triggering event, b1, ..., bn are belief literals (the plan context), and h1, ..., hn are goals or actions (the plan body), then

e : b1 ∧ ... ∧ bn ← h1 ; ... ; hn

is a plan, where e : c is called the plan’s head. The general structure of an AgentSpeak plan is therefore:

triggering_event : context <- body.

• the triggering event denotes the events the plan is meant to handle;
• the context represents the circumstances in which the plan can be used — a logical expression, typically a conjunction of literals to be checked whether they follow from the current state of the belief base (belief formulae);
• the body is the course of action to be used to handle the event if the context is believed true at the time a plan is being chosen to handle the event — a sequence of actions and (sub)goals to achieve that goal.

Let Φ be a literal: the plan body (i.e., intentions in AgentSpeak) can include the following elements:

• !Φ — achievement goals;
• ?Φ — test goals;
• +Φ — belief addition;
• −Φ — belief deletion;
• Φ — actions;
• .Φ — internal actions (not actually here — this is Jason…).

An intention is thus a stack of partially instantiated plans — the body of one plan pushes subgoals that resolve into further plans, and the stack grows and shrinks as the agent executes.

6. An AgentSpeak(L) example

The deck’s running example shows how all the pieces fit — beliefs, plans, triggering events, test and achievement goals:

/* Initial Beliefs */
likes(radiohead).
phone_number(covo,"05112345").

/* Belief addition */
+concert(Artist, Date, Venue)
  : likes(Artist)
  <- !book_tickets(Artist, Date, Venue).

/* Plan to book tickets */
+!book_tickets(A,D,V)
  : not busy(phone)
  <- ?phone_number(V,N);   /* Test Goal to Retrieve a Belief */
     !call(N);
     ...;
     !choose_seats(A,D,V).

The example reads as a story. The agent initially believes it likes Radiohead and knows Covo’s phone number. When a new belief arrives — a concert of an artist the agent likes, at a date and venue — the belief addition event +concert(...) fires, the context likes(Artist) is checked against the belief base, and the plan body launches the achievement goal !book_tickets(...). Booking tickets, in turn, is a plan whose context is not busy(phone); its body first asks a test goal — ?phone_number(V,N) retrieves the venue’s number from the beliefs — then calls, and finally chooses seats. Each ! pushes a sub-intention; the stack of plans grows and shrinks as the agent proceeds.

Three details are worth stressing because they reappear in Jason. First, the same predicate can be both a belief and a goal: phone_number/2 is a belief here, and the test goal queries it. Second, contexts are belief formulae: not busy(phone) is checked against the belief base at plan-selection time, not when the plan was written. Third, the body is an intention: when the plan is selected, its body becomes part of the agent’s intention stack, and sub-goals are handled by finding further plans.

7. Semantics: the agent configuration

AgentSpeak(L) has an operational semantics defined in terms of an agent configuration

⟨B, P, E, A, I, Se, So, SI⟩

where:

• B is a set of beliefs;
• P is a set of plans;
• E is a set of events (external and internal);
• A is a set of actions that can be performed in the environment;
• I is a set of intentions, each of which is a stack of partially instantiated plans;
• Se, So, SI are selection functions for events, options, and intentions.

The selection functions are the knobs where agent-specificity enters the semantics:

• Se selects an event from E — the set of events is generated either by requests from users, by observing the environment, or by executing an intention;
• So selects an option from P for a given event — an option is an applicable plan for an event, i.e. a plan whose triggering event is unifiable with the event and whose condition is derivable from the belief base;
• SI selects an intention from I to execute.

The semantics of intention execution is given by transition rules on the body of the currently executing plan. Each rule says what happens when the body starts with a given element:

• tr : ct ← +φ; ... ⇒ generates event +φ and updates beliefs. If there is no applicable plan for +φ, discard the event;
• tr : ct ← −φ; ... ⇒ generates event −φ and updates beliefs. If there is no applicable plan for −φ, discard the event;
• tr : ct ← !φ; ... ⇒ generates event +!φ. If there is no applicable plan for +!φ, remove the plan and generate −!ψ if tr = +!ψ (or −?ψ if tr = +?ψ);
• tr : ct ← ?φ; ... ⇒ generates event +?φ. If there is no applicable plan for +?φ, remove the plan and generate −!ψ (or −?ψ);
• tr : ct ← φ; ... ⇒ if the action fails, remove the plan and generate −!ψ (or −?ψ);
• tr : ct ← .φ; ... ⇒ if the internal action fails, remove the plan and generate −!ψ (or −?ψ).

If no plan is applicable for a generated −!ψ or −?ψ, then the whole intention is disregarded and an error message is printed. Failure handling is thus semantic: a failing sub-goal propagates a goal-deletion event up to the plan that generated it.

The configuration is then refined into a richer tuple ⟨ag, C, M, T, s⟩, where:

• ag is an AgentSpeak program consisting of a set of beliefs and plans;
• C = ⟨I, E, A⟩ is the agent circumstance: I is a set of intentions (each a stack of partially instantiated plans); E is a set of events, each a pair (tr, i) where tr is a triggering event and i is an intention (a stack of plans in case of an internal event, or T representing an external event); A is a set of actions to be performed in the environment — an action expression in this set tells other architecture components to actually perform the action, thus changing the environment;
• M = ⟨In, Out, SI⟩ is the communication component: In is the mail inbox (all messages addressed to this agent), Out is where the agent posts all messages it wishes to send, and SI keeps track of intentions suspended due to the processing of communication messages. A message is a tuple ⟨messageid, agentid, ilf, content⟩;
• T = ⟨R, Ap, ι, ε, ρ⟩ is the temporary information component: R for the set of relevant plans (for the event being handled), Ap for the set of applicable plans (the relevant plans whose contexts are true), and ι, ε, ρ keep record of a particular intention, event and applicable plan being considered along the execution of the agent;
• s is the current step within an agent reasoning cycle.

8. Semantics: deliberation steps

The current step s within an agent reasoning cycle is one of the following:

• ProcMsg — processing a message from the agent mail inbox;
• SelEv — selecting an event from the set of events;
• RelPl — retrieving all relevant plans;
• ApplPl — checking which of those are applicable;
• SelAppl — selecting one particular applicable plan (the intended means);
• AddIM — adding the new intended means to the set of intentions;
• SelInt — selecting an intention;
• ExecInt — executing the selected intention;
• ClrInt — clearing an intention or intended means that may have finished in the previous step.

Read the list as a pipeline: the mailbox is drained first, then one event is picked, its relevant plans are collected from the library, their contexts are checked (applicable plans), one of them is selected as the intended means and pushed onto the intentions, an intention is chosen for execution, one step of it runs, and finished intentions are cleared. The next cycle starts again from the mailbox — this is the BDI control loop of section 1, made into a precise state machine.

9. Jason: the interpreter

Jason [Bordini et al., 2007], developed by Jomi F. Hübner and Rafael H. Bordini, implements the operational semantics of a variant of AgentSpeak [Bordini and Hübner, 2006]. Its design is a two-level deal:

• AgentSpeak as the high-level language to define agents’ goal-oriented behaviour;
• Java as the low-level language to realise mechanisms — e.g. agent internal functions — and customise the architecture.

Jason extends AgentSpeak with a set of powerful mechanisms to improve agent abilities, aimed at making it a more practical programming language; and it comes with a framework for developing multi-agent systems (jason.sourceforge.net). In the course’s terms: AgentSpeak is the theory — an abstract language with an operational semantics — and Jason is the engineering — a working interpreter plus a MAS framework. Chapter 12’s Jade was a FIPA platform for weak agents; Jason is a platform for intentional agents, where the ACL machinery of Chapter 11 becomes the M component of the configuration.

10. The Jason reasoning cycle

The Jason reasoning cycle makes the semantics operational in ten steps:

1. perceiving the environment;
2. updating the belief base;
3. receiving communication from other agents;
4. selecting ‘socially acceptable’ messages;
5. selecting an event;
6. retrieving all relevant plans;
7. determining the applicable plans;
8. selecting one applicable plan;
9. selecting an intention for further execution;
10. executing one step of an intention.

Steps 1–2 are perception and belief revision (the BRF of the abstract architecture); 3–4 handle the mailbox with a social-acceptance filter; 5–8 are event selection and means–end reasoning; 9–10 are intention selection and execution. The cycle repeats; an action produced in step 10 is dispatched to the environment.

In the interpreter, the cycle is literally a Java method, reasoningCycle() in jason.asSemantics.TransitionSystem:

public void reasoningCycle() {
    try {
        C.reset();    // C is the actual Circumstance
        if (nrcslbr >= setts.nrcbp()) {
            nrcslbr = 0;
            ag.buf(agArch.perceive());
            agArch.checkMail();
        }
        nrcslbr++;        // counting number of cycles
        if (canSleep()) {
            if (ag.pl.getIdlePlans() != null) {
                logger.fine("generating idle event");
                C.addExternalEv(PlanLibrary.TE_IDLE);
            } else {
                agArch.sleep();
                return;
            }
        }
        step = State.StartRC;
        do {
            if (!agArch.isRunning()) return;
            applySemanticRule();
        } while (step != State.StartRC);
        ActionExec action = C.getAction();
        if (action != null) {
            C.getPendingActions().put(action.getIntention().getId(), action);
            agArch.act(action, C.getFeedbackActions());
        }
    } catch (Exception e) {
        conf.C.create(); // ERROR in the transition system, creating a new C
    }
}

Three engineering details stand out. Perception and mail checking happen only every nrcbp cycles (a configurable budget — the environment is sampled, not polled). If nothing can be done, the agent sleeps — autonomy includes the right to be idle. And the inner do…while applies semantic rules until the step returns to StartRC: the cycle is a sequence of semantic-rule applications, exactly as the operational semantics dictates.

11. The Jason programming language

Jason includes all the syntax and the semantics already defined for AgentSpeak, plus the operators a programmer expects: boolean operators ==, <, <=, >, >=, &, |, \==, not; arithmetic +, −, /, *, **, mod, div.

Then Jason includes several extensions. Let Φ be a literal: a Jason plan body can include the following additional elements:

• !!Φ — to launch a given plan Φ as a new intention (the new intention will not be related to the current one; its execution will be as if it is in a new thread);
• −+Φ — to update a belief Φ in an atomic fashion (atomic deletion and update).

Belief annotations. Jason introduces the notion of annotated predicates:

ps(t1, ..., tn)[a1, ..., am]

where the ai are first-order terms. All predicates in the belief base have a special annotation source(si), where si ∈ {self, percept} ∪ AgId:

myLocation(6,5)[source(self)].
red(box1)[source(percept)].
blue(box1)[source(ag1)].

The developer can define customised annotations too — e.g. a degree of certainty on a belief:

colourblind(ag1)[source(self),doc(0.7)].
lier(ag1)[source(self),doc(0.2)].

Strong negation (operator ~) is another Jason extension to AgentSpeak, allowing both closed-world and open-world assumptions. The distinction is between “not believed” (not) and “believed to be false” (~). The deck’s pit-stop example shows all three cases:

+!pit_stop(fuel(T), tires(_))
  : not raining & not ~raining   /* Lack of knowledge: no belief of raining, no belief of ~raining */
  <- -+tires(intermediate);        /* Atomic Belief Update */
     !fuel(T+2); ...

+!pit_stop(fuel(T), tires(_))
  : raining                       /* There is a belief indicating raining */
  <- -+tires(rain);
     !fuel(T+5); ...

+!pit_stop(fuel(T), tires(_))
  : ~raining                      /* There is a belief indicating ~raining */
  <- -+tires(slick);
     !fuel(T); ...

Three different plans for the same goal pit_stop, distinguished only by context: rain tyres when it is believed raining, slick tyres when it is believed not raining, intermediate tyres when the agent simply does not know. Open world: absence of evidence is a third case, not a fallback.

Belief rules. In Jason, beliefs (and their annotations) can be pre-processed with Prolog-like rules — Chapter 8’s logic meets Chapter 13’s annotations:

likely_color(Obj,C)
  :- colour(Obj,C)[degOfCert(D1)]
     & not (
        colour(Obj,_)[degOfCert(D2)]
        & D2 > D1 )
     & not ~colour(Obj,C).

12. Internal actions and message passing

Internal actions (.Φ) are self-contained actions whose code is packed and atomically executed as part of the agent reasoning cycle. They can be used for special-purpose activities: to interact with Java objects, to invoke legacy systems elegantly, and — as the rest of the course will show — to use artefacts in A&A systems. An example of a user-defined internal action:

userLibrary.userAction(X,Y,R)

can be used to manipulate parameters X and Y and unify the result of that manipulation in R — exactly the input/output discipline of a Prolog predicate, Chapter 8 again.

Defining a new internal action is writing a Java class. The deck’s example, myLib.randomInt(M, N), unifies N with a random int between 0 and M:

package myLib;

import jason.JasonException;
import jason.asSemantics.*;
import jason.asSyntax.*;

public class randomInt extends DefaultInternalAction {

    private java.util.Random random = new java.util.Random();

    @Override
    public Object execute(TransitionSystem ts, Unifier un, Term[] args) throws Exception {
        if (!args[0].isNumeric() || !args[1].isVar())
                throw new JasonException("check arguments");
        try {
            int R = random.nextInt( ((NumberTerm)args[0]).solve() );
            return
                 un.unifies(args[1], new NumberTermImpl(R));
        } catch (Exception e) {
            throw new JasonException("Error in internal action 'randomInt'", e);
        }
    }
}

Many internal actions are available for printing, sorting, list/string operations, manipulating beliefs/annotations/plan library, waiting/generating events, etc. (see jason.stdlib). Predefined internal actions have an empty library name:

• .print(1,X,"bla") — prints out to the console the concatenation of the string representations of 1, of the value of variable X, and of the string "bla";
• .union(S1,S2,S3) — S3 is the union of the sets S1 and S2 (represented by lists); the result set is sorted;
• .desire(D) — checks whether D is a desire: D is a desire either if there is an event with +!D as triggering event or it is a goal in one of the agent intentions;
• .intend(I) — checks if I is an intention: I is an intention if there is a triggering event +!I in any plan within an intention; intentions can be suspended and appear in E, PA (intentions with pending actions), and PI (intentions waiting for something) as well;
• .drop_desire(I) — removes events that are goal additions with a literal that unifies with the one given as parameter;
• .drop_intention(I) — drops all intentions which would make .intend true.

Message passing uses internal actions. A sender agent A sends a message to agent B via:

.send(B, ilf, m(X))
.broadcast(ilf, m(X))

• B is the unique name of the agent that will receive the message (or a list of names);
• ilf ∈ {tell, untell, achieve, unachieve, askOne, askAll, askHow, tellHow, untellHow};
• m(X) is the content of the message.

The receiver agent B receives the message from A as a triggering event, and handles it by customising a reaction:

+m(X)[source(A)] : true
<- dosomething; ...

The annotation [source(A)] is how the receiver knows who sent the message — the source annotation of section 11, used at runtime. The ilf performatives are Chapter 10’s FIPA communicative acts, repurposed: tell informs, achieve asks the receiver to adopt a goal, askOne/askAll request information, tellHow shares plans.

13. Environments and hierarchical planning

To build and deploy a MAS you need to rely on some sort of environment where the agents are situated; the environment has to be designed and implemented as well. There are two ways to do this:

1. Defining perceptions and actions so as to operate on specific environments — done in Java by defining lower-level mechanisms and by specialising the Agent Architecture and Agent classes;
2. Creating a ‘simulated’ environment — done in Java by extending Jason’s Environment class and using methods such as addPercept(String Agent, Literal Percept).

import jason.*;
import ...;
public class myEnv extends Environment {

   public myEnv() {
      Literal loc = Literal.parseLiteral("location(3,5)");
      addPercept(loc);
   }

   public boolean executeAction(String ag, Term action) {
      if (action.equals(...)) {
          addPercept(ag,
                     Literal.parseLiteral("location(table,c(3,4))"));
      }
      ...
      return true;
   }
}

The environment is where Chapter 4’s situatedness becomes code: the agent perceives what the environment publishes (addPercept), and the environment reacts to the actions the agents execute (executeAction).

Hierarchical planning. The deck closes the language tour with an advanced BDI aspect. Hierarchical abstraction is a well-known principle, exhibiting great effectiveness in planning: it is used to reduce a composite intention — or a given task — to a greater number of independent sub-intentions — or sub-tasks — placed at a lower level of abstraction. An agent can manage at runtime an alternating hierarchy of (meta)goals and plans, emerging from top-level goals over plans to subgoals and so forth. This highly simplifies the structure of plans, and allows plans to be conceived around self-contained actions — the leaves of the goal hierarchy — which can be reused for different purposes too. The hierarchy is defined having in mind the problem domain (the goal to be achieved) and trying to imagine those fine-grained actions which in turn are supposed to accomplish the required activities.

The crucial contrast is with traditional planning systems: they mainly make offline planning — creating plans to achieve goals by composing actions in a repertoire. Intentional systems, differently, need to plan in dynamic environments and cope with changing contexts and situations [Sardina et al., 2006]. BDI planning is a hybrid approach: plans are defined at design time and at the language level, but their execution is ruled by the architecture (means–end reasoning) according to context conditions — as in Jason and Jadex — or planning rules, as in 2APL.

14. Conclusion

The deck concludes by positioning the two artefacts of the chapter:

• AgentSpeak — a goal-oriented notion of agency; mentalistic notions as building blocks; agent programming; logic + BDI; operational semantics;
• Jason — an AgentSpeak interpreter; implements the operational semantics; support for an Agent Communication Language; highly customisable, open source.

Two books anchor the literature: Programming Multi-Agent Systems in AgentSpeak using Jason [Bordini et al., 2007] and Multi-Agent Oriented Programming [Boissier et al., 2020] — the latter opening the road toward JaCaMo, the A&A (agents & artefacts) framework the course’s later modules build upon.

Check your understanding