Related Agent Programming Languages

The GOAL agent programming language is related to but different from other agent programming languages. There are quite a few other languages that provide support for programming agents. Some of these languages are listed below.


2APL is a successor of the language 3APL and actively being developed at Utrecht University. 2APL can be downloaded from SourceForge.

An 2APL multi-agent system (mas) is created by means of a mas file which is formatted in using XML. Below we see an example of an 2APL mas file. The first line starts the mas file. The second starts the description of the environment with its name and the file where specifications are given. The next three line note parameters that are used to setup the environment. the sixth line ends the environment description. The next two line denote agents that will be running in the system. They both have a name and a source file. The last line ends the mas description.

 <environment name="blockworld" file="blockworld.jar">
  <parameter key="gridWidth" value="18" />
  <parameter key="gridHeight" value="18" />
  <parameter key="entities" value="2" />
 <agent name="harry" file="harry.2apl" />
 <agent name="sally" file="sally.2apl" />

2APL agents decide what to do using plans. An example of a plan is illustrated below. Plans are put in the section Plans in a 2APL agent program. The plan below instructs the agent to perform the enter command to start the agent at a particular position in the blockworld environment. The [...] construct is used to create an "atomic" plan that must be executed in one go and cannot be interrupted by any other plans nor in any other way by the reasoning cycle of the agent. The comma separates plans. The second plan sends a message to the admin agent with the request to register the agent, using the special keyword me to refer to the agent itself.

  send(admin, request, register(me))

Agent Factory

See AF webpage. Agent Factory can be downloaded from SourceForge.

JACK Intelligent Agents

JACK is a commercial agent programming language that extends Java with various agent programming constructs and is being developed by AOS.

JACK is an extension of Java and uses most of the same syntax. Below we show a code snippet showing the implementation of the Socrates agent. It has JACK specific data which are preceded with a \#. The first is data of the type Board. The second and third are events that the agent is able to handle. These are followed by the plans Move and ChooseMove? that are used by the agent, but implemented at another point. The last data is the event that Socrates hands to the environment. This is followed by two functions. The first is the constructor of the agent and the second tells the agent what to do when it is activated.

public agent Socrates extends Agent {
  #private data Board board();
  #handles event NextMove;
  #handles event PlanChoice;
  #uses plan Move;
  #uses plan ChooseMove;
  #posts event NextMove nm;
  public Socrates(String name){
  boolean begin(){
    return postEventAndWait(;

You can not only specify agents in JACK there is also a system to make specify teams. This is done in much the same way as agents as can be seen in the code snippet below. First a team is declared like any other class. Then in a similar way as the agent the JACK specific data is declared. In this example two roles are first declared that are performed by the team. These roles are declared instead of agents. To fill spots in the team the specification calls for certain roles to be filled and does not specify in what way these roles are specified. After the roles the team indicates that it uses the IncrementSome? and DecrementSome? plans. And lastly the team constructor is declared.

team Clever extends Team{
  #performs role UpCounter;
  #performs role DownCounter;

  #uses plan IncrementSome;
  #uses plan DecrementSome;

  Clever(String name){


Jadex is an agent platform or language for developing multi-agent systems using Java and XML-based Agent Definition Files. Jadex is being developed at Hamburg University.

The syntax of Jadex reuses the existing techniques of Java, OQL and XML. You can see the combination of these three techniques in the code snippet below. In this code snippet you see how the belief base of Jadex is set up. The first three lines show how a belief is formatted where XML is used to format the beliefs and the internal commands are Java code with added functions of OQL. In the example the belief system_time is a long value that is updated every second and contains the current system time. The second item in the code snippet is a belief set with the name alarm_time. It is also of the type long and is filled with two facts. The first is the current system_time from the belief base plus two hours and the second is the system_time plus three hours.

<belief name="system_time" class="long" updaterate="1000">

<beliefset name="alarm_time" class="long">

The goals in Jadex are distinguished into 4 different types. These are perform goals that call for an action to be performed, achieve goals to meet certain criteria, query goals to gather information and maintain goals to make sure certain facts remain applicable. In the code snippet below you can see the specification of a perform goal and a query goal. The snippet begins with a performgoal with the name playsong. The parameter that belongs to the goal is the place where the song that has to be played can be found. The second part of the snippet is the querygoal named retrieve_song. It will let the agent look for the song with the string that is in the parameter for a name.

<performgoal name="playsong">
  <parameter name="Queen - 39.mp3" class="MediaLocator"/>

<querygoal name="retrieve_song">
  <parameter name="Bohemian Rhapsody" class="String"/>


Jason builds on and extends AgentSpeak(L). Jason can be downloaded from SourceForge.

An agent within Jason consists of a belief base and a plan library. Plans are chosen and executed based on the goals and beliefs that are current in the belief base, where goals are added and removed by plans. We can see an example of this in the code snippet below where we see the code of a baggage carrying agent in which the belief of certain baggage standing somewhere generates a goal and a belief. The snippet starts with denoting which noting a few beliefs of the agent. It beliefs it has the skill to deal with Laptops and carryon's but not the skill to deal with animals. It also has the belief that field1 is a safetyArea. After the beliefs we have the first plan from the Jason agent plan-base. The plan says that when the agent receives an event that there is Baggage at Gate of Terminal of BaggageType? and it has the skill to deal with that kind of Baggage it then generates the goal to go to the Gate and to pickup the baggage. Here the goal is indicated by the !-mark.



+Baggage(Terminal, Gate, BaggageType) : skill(BaggageType)
    <- !go(Terminal, Gate);

The code snippet below contains an action description. It starts with declaring the CPHAgent which inherits from Agent. In the CPHAgent we declare an action called socAcc with a Message as a parameter. This is a thinking action in which the agent decides if it should accept an assignment it receives. To accept the assignment has to come from one of the mds agents and it should be an assignment to achieve a certain goal. It returns true if it accepts, otherwise it returns false.

public class CPHAgent extends Agent {
  public boolean socAcc(Message m) {
    if(m.getSender().startsWith("mds") && m.getIlForce().equals("achieve"))
      return true;
      return false;


The JIAC agent platform is being developed by the Distributed Artificial Intelligence Laboratory at Berlin. Find out more about JIAC here.

Classical Agent Oriented Languages


The classic reference to Agent Oriented Programming (AOP) is Shoham's 1993 paper, based on earlier work reported in e.g. a paper from 1991. The language was introduced informally by means of examples and discussion but a formal semantics for the single agent core of AGENT0 can be found here.

AGENT0 has been implemented in Lisp but is no longer maintained. An example agent using Lisp-style syntax can be found below.

;;;  Responds to requests to (becool) subject to the mental condition
;;;  that he believes (now... at the moment of receipt of the message)
;;;  that he will be cool (i_am_cool) at the time stated in the
;;;  message, when he is requested to be cool.
;;;  Defined in AGENT0 Lisp-like Syntax

(defagent joetriv
    :timegrain 10			; in seconds (not used yet)
    :beliefs '((2881906857 (i_am_cool))
	       (2881906857 (on a b)))
    '( ((or (and (?agent1 REQUEST (DO ?time (behot)))
		 (?agent1 REQUEST (DO ?time2 (betepid))))
	 (?agent1 REQUEST (DO ?time (becool))))
	((B (?time (i_am_cool))))
	(do ?time (becool))) )

;;;  (BECOOL)
;;;  Prints a message of coolness on the screen

(defun becool ()
  (format t "~&Yo, dudes, I am the cool Joe Triv Agent. ~%"))

A manual from 1991 also contains a description of the syntax of AGENT0.


In 1996 Anand Rao wrote a paper in which he introduced a language he called AgentSpeak(L). AgentSpeak(L) was introduced as an alternative formalization of BDI agents and to provide a language for writing agent programs. According to Rao these agent programs could be "interpreted in a manner similar to that of horn-clause logic programs" which also seems to suggest that AgentSpeak(L) is a kind of logical language. We do not agree with this view. We have shown that AgentSpeak(L) is a rule-based agent language which is very similar to the agent language 3APL and can in fact be embedded in that language.

Beliefs in AgentSpeak(L) are simple ground facts such as:

adjacent(a,b), location(robot, a)

An AgentSpeak(L) program consists of various rules called plans in Rao's paper:

+location(waste,X):location(robot,X) &
                   <- pick(waste);

In this rule +location(waste,X) is a template that needs to match with a triggering event in order for the rule to fire. In addition, an instance of the condition location(robot,X) & location(bin,Y) must be believed and the variable X is used to retrieve the current position of the robot and variable Y to retrieve the position of the bin. Note that since the triggering event locates the waste at the position of the robot it then makes sense to pick up the waste, which is the first action of the rule body. Thereafter an event is created to indicate that the robot needs to be at position Y where the bin is. The idea is that if that has been achieved, the robot will drop the waste in the bin.

Rules to get to a particular location are provided by:

+!location(robot,X):location(robot,X) <- true
+!location(robot,X):location(robot,Y) &
                    (not (X = Y)) &
                    adjacent(Y,Z) &
                    (not (location(car, Z)))
                    <- move(Y,Z);

The language AgentSpeak(L) has been taken as a starting point in the design of the agent programming language Jason.


In 1997 the language 3APL was developed by Koen Hindriks in a paper describing its formal semantics. A comprehensive overview of the language can be found here.

The language 3APL was later implemented and extended with other notions such as goals that were originally developed for the language GOAL. See here for a brief overview. A webpage on 3APL is still maintained at Utrecht University.

Other Languages

Some of the agent programming languages introduced above rely on logical inference to compute what follows from an agent's beliefs, for example. Logical inference, however, is not the only computing mechanism that is provided in these languages.

The languages introduced below are completely based on logical inference and can be said to execute fragments of particular logics (recall that most interesting logics are undecidable or are intractable).


BRAHMS is a language developed at the NASA. It is based on the paradigm of activity orientated agents. This paradigm focuses on the fact that agents are always doing something even if it does not further the goal. For humans you could consider things like sleeping or toilet breaks. These things do not normally help us accomplish any goals but they are still activities that we perform.

A big advantage of the acticity paradigm is that it allows for easy modelling of human behaviour and the programming of agents that can easily coordinate with humans or that can model the behaviour of a human, or represent a human, in a virtual environment.

A well known APL that uses this paradigm is \textsc{Brahms} as described by Sierhuis, Clancey and Hoof\cite{brahmsover}. With its focus on simulating the behaviour of human workers it makes it possible to model coordination between agents. In the paper the authors show that they can use \textsc{Brahms} to create cooperating agents partly thanks to the communication possibilities.

\textsc{Brahms} has its origin in the modelling and simulation of the work practices that are used in human organizations. Since then the language has been developed to a full Agent Oriented Programming Language. And among its users it can count prestigious organizations like NASA.

Brahms has various interesting features. One of the important ones is its use of inheritance and polymorphism. Examples of the use of these constructs can be seen in the code fragment below. One of the special things about the inheritance/overwriting of BRAHMS can be seen in the code fragment as Kim_Agent inherits from Student and Kim is an Agent while Student is a group. In BRAHMS Groups can inherit from other groups but agents can only inherent from a group.

The other interesting syntax element in the code fragment below is that a primitive_activity is overwritten by a composite_activity. This is because they are both activities that can overwrite each other but composite_activities as the name implies are a group of work- and thought process while a primitive_activity is a single action.

The last important thing that we show in the code fragment below is a special kind of action called a move. It does exactly what the name implies: define movement of your agent between locations.

group Student {
  primitive_activity study() {
    max_duration: 3000;

  move moveToLocation(World loc){

agent Kim_Agent memberof Student {

  composite_activity study() {


In BRAHMS both an agent and a composite_activity separate their thoughts from there activities. The thoughts are modeled in thoughtframes and the activities are described in workframes as can be seen in the code snippet below. In operation the difference is that a thoughtframe takes no time to execute while a workframe can. It is also possible for a workframe to contain only reasoning and no actions making it in effect a thoughtframe but the opposite is not possible since it is not possible to specify actions in a thoughtframe.

workframe wf_getFood{
  repeat: true;
  when(knownval(current.howHungry > 20.00) and
    knownval(current.checkedDiner = true) and
    knownval(current.needCash = false) and
    knownval(current.calculatedCash = true))

    conclude((current.calculatedCash = false));

thoughtframe tf_chooseBlake {
  repeat: true;

    forone(Cash) cs;             
  when(knownval(current hasCash cs) and
    knownval(cs.amount > 15.00) and
    knownval(current.checkedDiner = false) and
    knownval(Campanile_Clock.time < 20))
    conclude((current.chosenDiner = Blakes_Diner));
    conclude((current.checkedDiner = true));

The Code snippet above also show the content of the Work- and Thoughtframes. The workframe wf_getfood will repeat as long as its requirements are met. The requirements are indicated by where keywords are that the agent is hungry enough, it has selected a diner, does not need cash and that it has checked the amount of cash it has. When these requirements are met the do section is executed. In the example this means we do the action getfood and that afterwards we are no longer certain about our money. The thoughtframe chooseBlake also repeats, with the requirements that cs is our cash that the amount is enough, that we have not selected a diner yet and that it is before closing time. Then we can conclude that we chose Blakes_Diner and that we have selected a Diner.


Golog is a programming language based on the situation calculus. It does not incorporate the main BDI notions but offers a programming language that facilitates searching plans.

Concurrent MetateM

Concurrent MetateM is a programming language based on temporal logic.

Other Multi-Agent Platforms


One of the distinguishing feature of GOAL is the concept of a declarative goal. Goals of a GOAL agent describe what an agent wants to achieve, not how to achieve it. Different from other languages, GOAL agents are committed to their goals and only remove a goal when it has been completely achieved. GOAL provides a programming framework with a strong focus on declarative programming and the reasoning capabilities required by rational agents.

Literature on the notion of a goal:

  • Lars Braubach, Alexander Pokahr, Daniel Moldt and Winfried Lamersdorf (2004). Goal Representation for BDI Agent Systems, in: The Second International Workshop on Programming Multiagent Systems.
  • Philip R. Cohen and Hector J. Levesque (1990). Intention Is Choice with Commitment. Artificial Intelligence 42, 213–261.
  • Andreas Herzig and D. Longin (2004). C&l intention revisited. In: Proc. of the 9th Int. Conference Principles of Knowledge Representation and Reasoning (KR’04), 527–535.
  • Koen V. Hindriks, Frank S. de Boer, Wiebe van der Hoek, John-Jules Ch. Meyer (2000). Agent Programming with Declarative Goals. In: Proc. of the 7th Int. Workshop on Intelligent Agents VII (ATAL’00), pp. 228–243.
  • Anand S. Rao and Michael P. Georgeff (1993). Intentions and Rational Commitment. Tech. Rep. 8, Australian Artificial Intelligence Institute.
  • Birna van Riemsdijk, Mehdi Dastani, John-Jules Ch. Meyer (2009). Goals in Conflict: Semantic Foundations of Goals in Agent Programming. International Journal of Autonomous Agents and Multi-Agent Systems.

Last modified 6 years ago Last modified on Mar 22, 2011, 4:07:33 PM