1. AOSE Agent-Oriented Programming

2. Preliminaries Much early research focused on theories of agency –How to conceptualize agents? –What properties should agents have? –How to formally represent and reason about these properties? Two approaches: –Macro Theories: theories that try to analyse and capture how a group, an organisation, or a society behaves as a whole. –Micro Theories: theories that try to model how to behave in certain desired ways, as part of the whole. Many approaches inspired by the intentional stance…

3. The Intentional Stance (Dennett) Three levels of abstraction can be used to predict and explain the behaviour of an object: –Physical Stance: the domain of physics and chemistry; concerned with mass, energy, velocity, chemical composition, … Predicting where a ball will land based on trajectory –Design Stance: the domain of biology and engineering; concerned with purpose, function and design. Predicting that a bird will fly when flapping its wings because this is what wings are for –Intentional Stance: the domain of software and minds; concerned with belief, thinking, and intent. Predicting that the bird will fly away because it knows the cat is coming and it is afraid of being eaten.

4. Intentional Stance and Agents Using the Intentional Stance allows: –Abstraction from the underlying system complexity Beliefs and knowledge, wants and desires, fears and joys, … –Simple to model rational decision-making processes: X intends to move away from Y because X believes Y is too close and is afraid of Y. The Robot goes to the fridge because it believes that its master wants a beer. –Sits well with logic: Believes(X, close(Y)) & Afraid(X, Y) => Intends(X, moveFrom(Y)) Believes(Robot, wants(master, beer)) => Intends(Robot, goto(fridge);get(beer);goto(master);give(beer))

5. Intentional Stance and Agents What mental states should we use? –Wooldridge and Jennings (1995): 1: information attitudes, e.g. beliefs and knowledge which pertain to the knowledge the agent has about the environment in which it finds itself. 2: pro-attitudes, e.g. desires, intentions, obligation, which concern the actions an agent takes. –At least one of each is necessary for modeling decision-making –A defacto standard has emerged: Beliefs: the current state of the environment Desires: the agent ideal future state of the environment Intentions: subset of the desires that the agent commits to –Known as the Belief-Desire-Intention (BDI) architecture

6. Agent-Oriented Programming “Programming in the Intentional Stance”

7. Agent-Oriented Programming Class of programming language introduced in 1993 by Yoav Shoham (Stanford). OOPAOP Basic UnitObjectAgent Parameters describing unconstrainedbeliefs, commitments, state of basic unitcapabilities Process of Computationmessage passing andmessage passing andresponse methods Types of Messageunconstrainedinform, request, offer Constrains on Methodsnonehonesty, consistency

8. Agent-Oriented Programming AOP System Requirements: –a formal model (language) with clear syntax and semantics for describing mental states. –an interpreted programming language in which to define and program agents, with primitive commands (such as request and inform). –an ”agentifier”, converting neutral devices into programmable agents. Shoham illustrates this through a prototype language, known as Agent-0.

9. AgentSpeak(L)

10. Devised by Anund Rao in 1995: –Attempts to bridge the gap between theory and practice –One-to-one correspondence between model theory, proof theory and abstract interpreter. –Based on Belief-Desire-Intention model –based on a restricted first-order language with events and actions. –agent behavior dictated by programs written in AgentSpeak(L). Implementations: –Jason (2004 – Bordini) –AF-AgentSpeak (2010 – Collier).

11. AgentSpeak(L): Basic Notions Beliefs: –Constants (objects/concepts) are represented as lower case strings – rem, man, ball, … –Variables are represented as upper case strings – X, Value, … –Relationships/properties are represented as predicates: isa(rem, man) : represents the fact that rem is a man. see(ball) : represents the fact that the ball can be seen. Goals: –What the agent wants to achieve (predicates prefixed with !) – !see(ball), !goto(rem), …

12. AgentSpeak(L): Basic Notions Events: –Represent changes to the agents beliefs / goals. –an event can be internal, when a subgoal needs to be achieved external, when generated from belief updates as a result of perceiving the environment. –two types of triggering events: related to the addition (‘+’) and deletion (‘-’) of attitudes (beliefs or goals).

13. AgentSpeak(L): Basic Notions Plans: – the basic abilities of an agent (i.e. how it can affect its environment). te : ct <- h Where: –te - triggering event (denoting the purpose for that plan) –ct - a conjunction of belief literals representing a context. –h - a sequence of basic actions or (sub)goals that the agent has to achieve (or test) when the plan, if applicable, is chosen for execution.

14. AgentSpeak(L): Basic Notions Example Plans: –“If we believe a concert by artist A will take place at venue V and we like A, adopt an achievement goal to book tickets for the concert.” +concert (A,V) : likes(A) <- !book_tickets(A,V). –“If we have a goal to book tickets and the phone is not busy, call the venue and adopt an achievement goal to choose seats.” +!book_tickets(A, V) : ¬busy(phone) <- call(V); !choose seats(A,V).

15. AgentSpeak(L): Basic Notions Intentions: plans the agent has chosen for execution. –Represented as a stack. –Intentions are executed one step at a time: query or change the beliefs perform an action on the external world suspend the execution until a certain condition is met submit new goals. –The operations performed by a step may generate new events, which, in turn, may start new intentions. –An intention succeeds when all its steps have been completed. It fails when certain conditions are not met or actions being performed report errors.

16. AgentSpeak(L): Interpreter Design An AgentSpeak(L) agent combines: –A set of events Events can be either internal (interpreter events) or external (environment events) –A set of intentions: A stack of partially instantiated plans –Three selection functions: SE (the event selection function): selects a single event from the set of events SO: selects an “option” (i.e., an applicable plan) from a set of applicable plans SI: selects one particular intention from the set of intentions.

17. AgentSpeak(L): Interpreter Design

18. Summary AgentSpeak(L) is a theoretical (but computationally tractable) AOP language. The central concept in AgentSpeak(L) is the notion of a partial plan that can be applied to resolve some triggering condition in some context. AgentSpeak(L) says nothing about communication. But, AgentSpeak(L) has been used as a basis to explore a range of more advanced concepts (cooperation, organisation, …)

19. Agent Factory and Agent Speak

20. AF-AgentSpeak Built using the Agent Factory Common Language Framework. Standard Logic Framework Planning Framework Eclipse Integration Debugger Support Extended version of AgentSpeak(L) Basic language implemented with some minor changes to syntax Extended suite of plan operators Environment Model based on sensors, actions, and modules Integrated FIPA ACL based communication

21. Basic Logic Concepts Variables: begin with a ? –?name is the variable name Functions: –happy is a constant (function of arity 0) –fatherof(?x) is an unbound function of arity 1 –motherof(Coral) a bound function of arity 1 Lists: –[] the empty list –[tanya, coral] list containing two terms –head([tanya, coral]) head of the list (tanya) –tail([tanya, coral]) head of the list (coral) –merge([tanya], [coral]) a combined list ([tanya, coral])

22. Basic Logic Concepts Arithmetic Operations ( +, -, *, / ): –Constant Terms have implicit types –1 + 2 evaluated to 3 –?x / 5 evaluated to 2 (assuming ?x = 10) –10.0 / 4 evaluated to 2.5 Comparison Operators ( >, <, ==, != ): –?x > 5 if ?x is greater than 5 Strings: –“a string” quotes “ override syntax –“?x is “ + ?x string concatenation

23. Basic Logic Concepts Predicates: –isa(rem, man) –~isa(rem, woman) –children(rem, [tanya, coral]) Conjunctions: –has(?x) & ~poisonous(?x) & likes(rem, ?x) Special values: –true –false

24. Environment Model Sensing and Acting: –Sensors: Java Classes that convert raw data into predicates. –Actions: Java Classes that do things (primitives) Resources: –Modules: Java Classes that model internal resources that are private to the agent (possibly combined with relevant sensors and actions). –Platform Services: Shared platform-level resources (interaction via sensors and actions)

25. Environment Model Sensors and Actions are the same for most languages: –Unique identifier –Supports addition / removal of beliefs –Supports retrieval of references to resources –Core API provided for all languages Modules are somewhat similar: –Can contain aggregations of related sensors and actions (Custom APIs) –Can encapsulate the interface to a platform service

26. Planning Components // Belief state query (? In AgentSpeak(L)) query(isa(rem, ?x)) // Print Hello World.println(“Hello World”) // Loop through the values 0, 1, …, 9 and print them out ?i = 0, while (?i < 10) {.print(?i + “ “), ?i = ?i + 1 }// plan failure try { // plan expansion.fail foreach (workerId(?x)) {} recover {.send(request, ?x, sayHello).println(“failed”), } stop // list creation} ?idList = list[ ?x | workerId(?x) ]

27. Core API Actions: –.abolish(?belief) : remove the specified belief from the belief set. –.send(?perf, ?rec, ?content) : send the given content using the specified performative to the specified reciever. –.print(?string) : print the string to the console. –.println(?string) : print the string to the console and start a new line. –.fail : Generate a failed action. –.nil : do nothing. –.bind(?serviceId) : bind the agent to the given platform service. Sensors: –.services : set of beliefs about the bound platform services. –.inbox : set of beliefs about messages that have been received. –.self : set of beliefs about the agent (name + Agent Identifier).

28. Basic AF-AgentSpeak Examples

29. AF-AS Examples “Hello World” Agent #agent alive +initialized : true <-.println(“Hello World”); public class Main { public static void main(String[] args) { Map designs = new HashMap<String,String(); designs.put("alive", "alive.aspeak“); new AgentSpeakDebugConfiguration(“test“,designs). configure(); } NOTES: –The initialize event is generated by the interpreter to allow plan rules to be invoked on the first iteration

30. AF-AS Examples “Hello 10 Times” Agent #agent alive10 // Print Hello World +initialized : true <- ?i = 0, while (?i < 10) {.println(“Hello World”), ?i = ?i + 1 };

31. AF-AS Examples #agent Ping +friend(?name, ?addr) : true <-.send(request, agentID(?name, ?addr), ping); +message(request, ?sender, ping) : true <-.send(inform, ?sender, pong); +message(inform, ?sender, pong) : true <-.send(request, ?sender, ping); NOTES: –The message(…) event is generated when a message is received. –The friend(…) event is an initial event passed by the main method.

32. Example: FIPA Request Protocol

33. Protocol Overview Usage: Requesting an activity / service be performed Example: implement a protocol and develop two simple task tasks: –Drinking beer task: prints “Mmmm tasty beer” –Time task: returns the time in the form time(?h, ?m, ?s)

34. Example The example consists of two agents: –requester.aspeak: this agent is the participant and performs the tasks –requestee.aspeak: this agent is the initiator and requests that the tasks be performed. First I will discuss requester implementation and then the requestee implementation. –Both programs will be preceded by explanations.

35. Requester A protocol can be viewed as having a “main” flow together with a number of “exceptional” flows (a flow is a sequence of messages). –For the request protocol, the main flow is where the participant agrees to perform the task, performs the task successfully, and tells the initiator that the task has been performed. –The first exceptional flow relates to the case where the participant refuses the request. –The second exceptional flow relates to the case where the requested task fails. Let’s look at each flow individually…

36. Requester (MAIN) For the request protocol, the main flow can be encoded through a single rule: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); When the agent receives the “request” message for ?task, if it believes that is canDo(?task), then the main flow is followed (actions in italics).

37. Requester (MAIN) For the request protocol, the main flow can be encoded through a single rule: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); First, it adopts a belief that it is performing the task, and then it sends a message to the initiator agreeing to perform the task.

38. Requester (MAIN) For the request protocol, the main flow can be encoded through a single rule: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); Now it performs the task by raising the !performTask(…) goal.

39. Requester (MAIN) Default behaviour for performTask(…): +!performTask(?agentID, ?task) : true <-.fail; –If this rule is triggered then there is no implementation of the task, so the agent views the task as having failed. Drink beer task: +!performTask(?agentID, drink(beer)) : name(?name) <-.println("[" + ?name + "] Mmmm tasty beer"),.send(inform, ?agentID, done(drink(beer))); –The agent prints out “[ ] Mmmm tasty beer” and informs the initiator that the task is done. –This rule must be written before the default rule (see full code)

40. Requester (MAIN) For the request protocol, the main flow can be encoded through a single rule: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); Finally, the agent drops the performingTask(…) belief.

41. Requester (FAILURE) For the request protocol, the main flow can be encoded through a single rule: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); NOTE: the failure exceptional flow is implemented here by the try {…} recover {…} operator. –if the agent fails to perform the task, then the recovery plan involves the agent sending a failure message to the initiator.

42. Requester (REFUSE) For the request protocol, the refuse exceptional flow can be encoded through a single rule: +message(request, ?initiator, ?task) : ~canDo(?task) <-.send(refuse, ? initiator, ?task); Here, the participant refuses to perform a requested task if it does not have the belief canDo(?task).

43. Requester (CANCEL) In our discussion of the basic protocol, we did not consider how to cancel a request. –Doing this requires that we make use of a previously un-described feature of AF-AgentSpeak that is not part of the basic AgentSpeak language. –Specifically, we associate a maintenance condition (see code in bold below) with the rule that implements each task. If this condition becomes false, the agent causes the associated intention to fail. +!performTask(?initiator, drink(beer)) : name(?name) <- [performingTask(?initiator,drink(beer))].println("[" + ?name + "] Mmmm tasty beer"),.send(inform, ?initiator, done(drink(beer))); For the performTask(…) rules, the maintenance condition is that you believe that you are performing the task.

44. Requester (CANCEL) Now, we can add a rule for handling cancellation requests: +message(cancel, ?initiator, protocol(request, ?task)) : performingTask(?initiator, ?task) <- -performingTask(?initiator, ?task); –This rule basically has the effect of removing the performingTask(…) belief whenever the participant receives a request to cancel a task that it is currently performing. –The side effect of removing this belief is that the maintenance condition on the !performTask(…) rule becomes false, causing the agent to fail the intention. –The last thing we need to do is to modify our MAIN flow to cater for the task that the !performTask(…) rule has been intentionally failed…

45. Requester (CANCEL) The updated rule is: +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover { if (performingTask(?initiator, ?task)) {.send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); The full code is presented on the next slide.

46. Requester (Code) #agent requester +message(request, ?initiator, ?task) : canDo(?task) <- +performingTask(?initiator, ?task),.send(agree, ?initiator, ?task), try { !performTask(?initiator, ?task) } recover { if (performingTask(?initiator, ?task)).send(failure, ?initiator, ?task) } -performingTask(?initiator, ?task); +message(request, ?initiator, ?task) : ~canDo(?task) <-.send(refuse, ?initiator, ?task); +message(cancel, ?initiator, protocol(request, ?task)) : performingTask(?initiator, ?task) <- -performingTask(?initiator, ?task); canDo(drink(beer)); +!performTask(?initiator, drink(beer)) : name(?name) <- [performingTask(?initiator, drink(beer))].println("[" + ?name + "] Mmmm tasty beer"),.send(inform, ?initiator, done(drink(beer))); +!performTask(?initiator, ?task) : true <-.fail;

47. Requestee For the requestee, the protocol flows are not so complicated: –Send a request for the participant to drink beer. –If this request is completed successfully, send a request for the participant to drink wine. –Notice that the agent identifier uses the address: “local:localhost”. This can now be used for agents on the same platform The full code for the requestee is: #agent requestee +initialized : true <-.send(request, agentID(requester, addresses("local:localhost")), drink(beer)); +message(inform, ?agentID, done(drink(beer))) : true <-.send(request, agentID(requester, addresses("local:localhost")), drink(wine));

48. Deployment public class Main { public static class DebugConfig extends AgentSpeakDebugConfiguration { public DebugConfig() { super(“afas", null); } public void configure() { super.configure(); addAgent("requester", “acre/requester.aspeak"); addAgent("requestee", “acre/requestee.aspeak"); } public static void main(String[] args) { new DebugConfig().configure(); }

49. Summary The participant code has been designed to be extensible. –To add another task, all you need to do is add a canDo(…) belief, and implement a !performTask(…) rule. –Example: time canDo(tell_time); +!performTask(?initiator, tell_time) : name(?name) & time(?h, ?m, ?s) <- [performingTask(?initiator, tell_time)].send(inform, ?initiator, result(tell_time, time(?h, ?m, ?s))); –NOTE: The inform message this case is result(?task, ?value) which corresponds to the inform-result message in the protocol.