2.1 Multi-agent system

A JaCaMo MAS is composed of a dynamic set of agents interacting within a shared, possibly distributed, environment that consists of a dynamic set of artefacts (Boissier et al., Reference Boissier, Bordini, Hübner, Ricci and Santi2013). Agents are goal-oriented autonomous entities, encapsulating a logical thread of control, that pursue their goals by perceiving and acting upon artefacts and by communicating with other agents. Artefacts are used to model any kind of resource or tool that agents can use and possibly safely share, to achieve their goals. An agent can perceive the observable state of an artefact, reacting to events related to that state change, and act by performing actions that correspond to operations provided by an artefact’s usage interface. Environments can be decomposed into one or multiple workspaces, which are artefact containers representing a logical space, defining a notion of locality Footnote ³ . An agent can join (and work with artefacts of) multiple workspaces at the same time. Workspaces can be located on different network nodes, in case of physically distributed environments.

The agent organization abstraction level makes it possible to specify and handle as a first-class aspect the coordinated and organized activity taking place in the system, resulting from the concurrent and complex tasks performed by groups of agents interacting with each other or acting within the environment. Changes in the state of the environment may lead agents to react and they may also affect the state of the organization. In order to support the joint work of agents, an organization can regulate and coordinate agent activities. For example, if there is a dependency between the tasks of two agents, when the first task is perceived as concluded through the state of the environment, the organization can require or expect the agent responsible for the second task to engage in the action it has previously committed to execute. The possibility to specify rules at the organizational level regulating and coordinating agent activities can significantly reduce the amount of work developers need to do when implementing agents for complex applications.

Of course, as agents are autonomous, this can only happen if they actively choose to participate in, and to comply with, one or more of the currently existing organizations in the system.

A MAS combines and inter-connects several different life cycles, each consisting of the creation, execution, and destruction of entities such as artefacts, workspaces, agents, and organizations. In this global picture, it is also important to stress the notion of autonomy, making clear the difference between agents and artefacts. Even though at some level both entities may be considered as processing/acting entities, only agents are meaningfully described as autonomous entities. Agents are deemed able to make reasoned/motivated decisions about the courses of action that they will take. This implies, as it will be explained below, that agents do not act upon other agents as they do with artefacts; rather, they interact with each other: the acceptance of information or the adoption of tasks from received messages are controlled by a decision-making process of the receiver. The set of abstractions expressed in agent organizations are targeted towards the agents in order to regulate and control their autonomy.

2.2 Programming dimensions

In order to support the design and programming of JaCaMo MAS, we propose three sets of (programming) abstractions. Each of these sets of abstractions, to which we refer as dimensions, take part in the creation of a multi-agent oriented program: the agent, environment, and organization dimensions.

In this paper, we focus on some of the abstractions and concepts from each dimension and we only discuss the main relations between these dimensions (cf. Figure 1). We give references for the interested reader where all the abstractions and details of our approach can be found. The objective here is to look only at the most foundational concepts and relations so that the reader can get the overall picture of our approach. Even though a few other concepts are introduced in later sections with a more practical view, the description of all the concepts in MAOP and JaCaMo in particular is not possible in this paper due to space constraints.

Figure 1

Multi-agent-oriented programming dimensions—agent (A), Environment (E), Organization (O) —with some of their inter-relations and with some of the concepts they use. In this figure, dashed purple links show the relations and inter-dependencies between the dimensions, for example, the agent dimension is related to the environment dimension through acting and perceiving

It should be noted that a MAS may lead to distributed execution of a number of heterogeneous agents, artefacts, and organizations; one of the reasons for heterogeneity is that those entities are potentially programmed by different people or indeed representing the interest of different, possibly competing, companies. Moreover, this programming approach give strong support for changes in and reorganization of the system code while the system remains running.

For example, through run-time creation of organization and artefact instances, agents joining and leaving organizations through the roles they choose to adopt, and so forth. This is useful for many of the features needed in modern computer systems pertaining, for instance, to the Internet of Things (IoT) domain.

2.3 Agent dimension

The agent dimension gathers all the programming abstractions that are used to program agents as autonomous software entities that have their own thread of control. Agents constantly perceive and act on the environment (i.e. on artefacts), interact with other agents, and take part in higher-level entities of the agent organization. In order to exhibit the property of autonomy as explained above, the programming abstractions that are used to program an agent allow it to reason about what to achieve by means of symbolically represented goals and, also importantly, how to do so by means of plans, given the current understanding of the perceived state of the system represented by means of beliefs.

The plan construct of the programming language is used to define sequences of actions and the manipulation of beliefs and goals when necessary. These are the ‘recipes’ for action that provide knowhow to the agent. Changes in beliefs and goals may happen by means of plan execution but also as a consequence of interaction with other agents and the environment. Furthermore, the changes in both these types of mental attitudes are recorded internally in an agent as events. It is the events that then lead to the execution of particular plans depending on the current state of environment, the agents beliefs, possibly the other intentions (i.e. other plans the agent is already committed to execute), and so forth.

All these abstractions make it possible for agents to be proactive, that is, to act so as to achieve their goals, but also to be reactive, that is, to react to changes in beliefs about the environment, the agent organization, or other agents. It should be noted that agents may interact with other agents through particular actions that are called communicative actionsFootnote ⁴ .

2.4 Environment dimension

The environment dimension offers a set of programming abstractions to represent the shared environment. These programming constructs concern first the notion of artefact, the basic environment entity that encapsulates computing or other forms of resources. Artefacts are used by agents through a set of operations that agents can perform on the artefact. It offers also a partial view on its state through a set of observable properties and on its activities through a set of signals. Both observable properties and signals are perceived by the agents only after they focus on the corresponding artefact (thus potentially avoiding information overload by only focussing the attention on the artefacts that matter to the agent). It should be noted that the connections between the agent and the environment dimensions happen through the transformation of observable properties and signals issued from the artefacts into beliefs/events of the agents and to the transformation of actions within executing plans of the agents into calls to operations on artefacts.

Note that artefacts can make direct references to real-world environments, to various forms of existing computational resources, or simply support agent coordination through shared resources in an implicitly controlled way. This dimension offers a second important programming abstraction, used to structure the activities of the situated agents by defining topological or symbolic regions called workspaces. Artefacts are situated in a workspace. Agents may dynamically join or leave one or several workspaces. Joining a workspace allows agents to perceive all artefact activity taking place in itFootnote ⁵ .

2.5 Organization dimension

Finally, the organization dimension gathers the abstractions that are used to structure and guide how the activities resulting from the actions and interactions of the agents within the environment should be coordinated. In an organization, a group can be used to provide social structure by means of roles that agents may decide to adopt within that group. When taking part in an organization, an agent plays at least one role in a particular group. Norms are used by MAS designers to express the behaviour that is expected from agents playing a particular role in the context of a particular group.

These programming constructs are used to state that agents playing specific roles will have certain obligations or permissions within the group activities in order to achieve collective goals. The individual behaviours are part of collective plans, called schemes, that provide a structured way to achieve a collective goal in which various different agents will have to work on different parts (sub-goals) of that activity by using some resources deployed in some configuration of the environmentFootnote ⁶ .

The development of a JaCaMo application starts by the definition of instances of the abstractions from each of these dimensions and their connections. Since some concepts from different dimensions are aligned (e.g. organizational goals and agent goals, environment operations and agent actions, observable properties and agent beliefs), developers currently use the same identifier to link the dimensions. For instance, if a norm obliges and agent to achieve goal g34, the agent has to have, at runtime, a plan to achieve goal g34Footnote ⁷ . In the next section, these definitions and their integration are concretely illustrated through code excerpts.

3.1 Agent–environment programming

We first show a simple program where three agents (named agt1, agt2, and agt3 ) perceive one artefact (named art1), as shown in Figure 2. The first two agents have the same initial program (file a.asl), however, they have different initial beliefs. To start a MAS with such an initial state, a JaCaMo project file as shown below is usedFootnote ⁸ . After the initialization, new agents and artefacts can be created by the agents themselves (we discuss this later).

Figure 2

Situated agents interacting with an artefact

3.2 Agent–environment interaction

All three agents in Figure 2 perceive the artefact situated in workspace ws1 by focussing on it and thus will have beliefs representing the current state of the observable properties b1 and b2 (these properties have one assigned value, as indicated by /1 in Figure 2). For instance, if the value of b1 is 10 in artefact art1, the agents have a belief b1(10)[source(percept)] in their belief base and this belief is automatically updated every time the value changes in the artefact. Agents agt1 and agt2 will also act on art1 executing the operation inc. The square brackets following a belief predicate are used to add annotations to a belief. They may be omitted in the code when there are no constraints on particular annotations of a belief but all beliefs in the belief base will have at least the annotations about the origin of the beliefs.

Agents can react to changes in the environment using plans. For instance, the program a.asl of agents agt1 and agt2 contains the following plan (planB1) which is triggered when the value of b1 changesFootnote ⁹ :

That can be read as ‘Whenever the belief about the value of b1 changes, provided the value of b1 is currently less than 10, the agent may execute the operation inc. to increase that value by half’. The part of the plan between: and <− is called context. It states the conditions under which the course of actions in the plan body is appropriate for handling the triggering event (the initial part of the plan preceeding:).

An agent program could be as simple as a line like the one above alone. The developer does not need to explicitly program the perception of the environment (this is done automatically in the agent reasoning cycle based on what artefacts the agent has focussed on) nor handle how the action request is passed on for execution by the artefact.

Beyond reactive behaviour as introduced above, proactive behaviour can be programmed by creating goals and reacting to changes in the agent’s goals. For instance, the new plan planB1 below creates a goal g5 given the same context conditions of the last example. The plan to achieve that goal may have many steps, including the creation of other goals, addition/deletion of beliefs, and execution of actions (i.e. operations provided by artefacts).

This plan may take a long time to finish—for instance, depending on how difficult it is to achieve all the required goals and execute all the required actions—so an observer of the behaviour of the agent could perceive it as a long-term proactive behaviour.

On the environment side, the artefact art1 is an instance of the artefact type Art1 and is programmed in Java with some provided classes and annotations that support artefact programming. For instance, the implementation of the operation inc., which increments the value of the observable property b2, is

It is worth noting that, as operations are atomically executed in an instance of an artefact, developers do not need to handle concurrency issues such as when several agents trigger the inc. operation at the same time. Furthermore, the platform takes care of suspending a particular agent intention when it requires an action to be executed in the environment. The intention remains suspended until the corresponding operation in the artefact is completed. In a plan body such as … a1; a2; … , the programmer can safely assume that action a2 will only be executed after the execution of a1. Suspending intentions that are waiting for the execution of environment actions allows agents to carry on executing intentions related to other aspects of the environment or to its internal reasoning. The agent continues its reasoning cycles, that is, perceiving and acting on the environment, so as to maintain its reactivity to other possible changes in the environment.

3.3 Changing the environment

In the code examples we introduced so far, the environment is fully defined in the project file by the application developer through the definition of workspaces, artefacts, and the agents that join/focus on them. In that case, the environment is fully created and configured at the launching of the system. However, in some cases it may be important to reconfigure and create new parts of the environment while the system is running. For instance, creating artefacts in reaction to some particular situation or from some deliberation of one or several agents. This means that the agents themselves should be able to create and change the environment configuration at run-time. This is another important feature of JaCaMo that enables agents to control the whole environment life cycle by creating workspaces, joining them, creating new artefacts, focussing on them, using them, and destroying them. As an example, the following agent program excerpt illustrates the use of this feature to achieve goal g4 within plan planG4.

The possibilities for agents to dynamically change the environment include also other programming constructs that can be used in the development of a MAOP. For instance, an agent can create or destroy other agents while executing. Furthermore, we discuss later in this paper how agents can deploy and reconfigure organizations at runtime.

3.4 Distribution

Another important feature of MAOP is that it allows us to distribute the execution of agents and artefacts in a straightforward way. In JaCaMo, this is done as follows. Let us consider that agents of type c, in order to achieve goal g2, need to perform a heavy computation and several machines should be used to distribute the load. Considering further that such computation is better implemented in Java. We could implement it in an artefact, hence externalizing (i.e. moving outside of the agent program) that computation as shown in Figure 3. In JaCaMo, workspaces and agents can be distributed on multiple machines; the simplest way of doing this is using project filesFootnote ¹⁰ . In the example below, two project files would be needed. The first project file ker_h1 runs in host1 and the following lines are added to the previous version of this project file:

Figure 3

Distributed agents and workspaces

The second project file, to be executed in host2, should be as follows:

The JaCaMo infrastructure manages the communication between the distributed components (workspaces, agents) so that we can deploy the system differently by just changing the project files (i.e. different distributed deployments do not require changing the code of the agents or artefacts).

In this setup, there are two artefacts with the same name (art2) but in different workspaces, one is used by agt3 and the other by agt4. These artefacts have the calc operation that returns some value instead of changing some observable property as done, for example, in the operation inc. of artefact Art1. The calc operation is implemented as follows:

Note that return values are modelled as action feedback, and there can be more than one. The Java API exploits OpFeedbackParam argument types to represent such feedback.

The agents do not need to know where artefacts are running to use their operations. For example, agents of type c, based on which artefacts they are focussing, can use distributed artefacts in plans as followsFootnote ¹¹ :

Although we do not exemplify this here, often artefacts are used to connect human users to the system or to connect the system to elements of a real-world environment. The examples included in the JaCaMo distribution exemplify artefacts used for graphical user interfaces and various other uses of artefacts.

3.5 Agent–agent interaction

Besides the interaction that agents can have with or through the artefacts in the environment, direct agent–agent interaction is also possible. It is based on speech acts. To illustrate this kind of interaction, two changes are made in the program of agt2 and project file as follows: (i) the goal g2 of agt3 will not be set in the project file anymore, it will be delegated by agt2 instead, and (ii) the belief b3 of agent agt4 will be informed by agt2 , as shown in Figure 4.

Figure 4

Agent communication

To program the first change, agent agt2 uses the .send (internal) action to send an achieve message to agt3. This action has three parameters: the name of the receiver, the performative (stating how the sender intends the message to affect the receiver), and the content. The performative used in this example, achieve, asks the receiver to achieve a new goal corresponding to the content of the message. The code used by agt2 to send the message is thus the following:

When agt3 receives this message, the default interpretation for the message (as implemented in the platform but user customization is possible) leads to the creation of a new goal g2. The program for agent agt3 does not need to be changed since it already has a plan to react to the creation of a goal g2 (previously created from the project file instead).

To implement the second change, agt2 uses the tell performative:

The default interpretation of a tell message on the receiver side leads to the creation of a belief corresponding to the content of the message (b3(15) in that case). Again, the code for agent agt4 does not need to be changed. In JaCaMo, the source of an agent’s beliefs is either external (through the initial project file, from tell messages sent by other agents, or perception of the environment in particular through observable properties of artefacts) or internal (i.e. created with a belief addition operator ‘+’ within some executed plan in the agent program). Similarly, goals can be created externally (through the initial project file or achieve messages sent by other agentsFootnote ¹² ) or internally (using the goal addition operator ‘!’ in the agent program).

3.6 Wrapping up

In this section, we showed how to program a set of agents situated in a shared environment populated with artefacts. The following features have been demonstrated through programming constructs from the agent and environment dimensions:

Situatedness: using the environment dimension and the ability to join workspaces where artefacts have been deployed. Artefacts can be individual computational tools, multi-agent coordination tools, graphical interfaces, or interfaces with the external world. Agents can perceive this environment and represent part of it through beliefs. They can also act on it through the current set of actions associated with the operations that are exposed by the currently instantiated artefacts.

Autonomy: agents have a reasoning cycle, with support to reactive and proactive behaviour through programming constructs such as goals, plans, intentions, etc.

Interaction: agents can interact through communicative actions and the shared environment.

Openness: agents can enter and leave workspaces and also create and change the environment structure and configuration at run time, by dynamically creating and disposing artefacts.

Distribution and deployment: the JaCaMo project files makes it possible to specify the initial deployment of multi-agent applications that could involve multiple workspaces running on different nodes (hosts).

4.1 CNP with a message-based implementation

The CNP can be programmed using message passing between agents, as illustrated in Figure 5. The askOne performative is used by the initiator (agent agt1) to consult the participants (agents agt2–agt4 ) about their price for task t1. The default behaviour for a receiver of such a message is to consult its belief base for the message content (the query is task(t1,Price) in this case) and to send back a tell message with the result of the query (e.g. send(agt1,tell,task(t1,300)). It should be noted that the initiator simply chooses the lowest-price bid.

Figure 5

CNP: message-based version

In this section, we do not intend to program agents with sophisticated reasoning, so their programs, presented below, are the simplest we can write. Comments are used to explain them. Code initiator.asl for agent agt1 contains an initial goal aiming at achieving allocate(t1) and the plan labelled allocateTask that achieves this goalFootnote ¹³ .

Code agt2.asl for a participant agent has an initial belief where a price is fixed for the task task(t1,300). It also has two plans, one for handling the case of winning an allocation and another for performing task t1.

Code agt3.asl used for another participant agent does not fix the price with an initial belief but with a rule generating a random price for task t1. It also has the two plans for the winning case and for doing task t1.

Code agt4.asl for another participant agent is more sophisticated in the sense that the agent will only answer to the askOne price query if it comes from a friend and if it has a plan for task t1 in its plan library (see plan fixingPrice). As we can see this code also has a plan for the winning case and one for completing a task. However, this plan is for task t2 and not for task t1 for illustration purposes, as explained below in the execution steps.

When we launch these agents using a JaCaMo project, the execution produces the following steps:

1. 1. agt1 broadcasts to all agents a query for the price of task t1 (line 5) and waits 2 seconds for the answers (line 6);

2. 2. agt2 answers with a fixed price according to its initial belief task(t1,300);

3. 3. agt3 answers with a random value following the rule in its belief base;

4. 4. agt4 does not answer given that it does not have a plan for task t1 (it only has a plan for task t2);

5. 5. agt1 receives the answers as beliefs in its belief base (contents of messages with a tell performative are interpreted as belief additions) as illustrated by the screenshot of the JaCaMo mind inspector in Figure 6;

6. 6. agt1 collects the bids (line 8) into a list based on a query task(T,P)[source(A)] (i.e. the bids it has received from agents agt2 and agt3), selects the best bid in line 10 (the agent who placed the bid with the lowest price for the task), and broadcasts the name of the winner to all agents (line 12);

7. 7. agt2 starts the task as soon as it receives the message saying it has been awarded the contract for that task.

Figure 6

MindInspector of agent agt1 after the call for proposals

The output of the execution of these agents on the console is as follows:

We now briefly discuss this implementation of the CNP and highlight some of its drawbacks:

1. 1. The initiator agent uses .broadcast for the announcements (i.e. cfp and winner), so all agents, even those not interested in the allocation process, receive the message and have their belief bases updated with the new belief (unless they are customized to ignore specific messages).

2. 2. In open systems, where new agents can enter and leave at any time, if an agent arrives after the cfp announcement (and before the deadline), it will miss the opportunity to participate in the ongoing allocation process.

3. 3. In usual implementations of CNP, participant agents do not know the bids placed by the other agents and thus are not able to decide whether to make a better offer. Allowing that to happen in the CNP implementation described above would require all bids to be broadcast, which would cause a significant increase in the number of exchanged messages that would be required for allocating the tasks.

Even though we could improve the agent programs to avoid some unnecessary messages, in the next section we avoid these drawbacks using artefacts instead.

4.2 CNP with an artefact-based implementation

The artefact-based implementation, as illustrated in Figure 7, slightly changes the previous protocol to better highlight the possibilities brought about by the use of artefacts. Instead of broadcasting the cfp, agt1 creates an artefact that shows, as an observable property, the required task and the current best proposal. Participant agents interested in that allocation process can focus on that artefact and, if they have a better proposal (although this is not allowed in the original ‘sealed bid’ CNP protocol), they can place further bids using the operation bid. After the deadline, agt1 checks the best proposal and announces the winner using again the artefact (the operation set_winner). Agents then perceive who is the winner based on the winner observable property of that artefact.

Figure 7

CNP: artefact-based version

To implement this version, the program of the initiator agt1 is changed toFootnote ¹⁴ :

Comparing the code of plan allocateTask to the one in the previous section, it can be noted that the program is shorter, since part of the previous code was externalized in the CNP artefact, for example, the determination of the best proposal. We can also notice that the belief base of agt1 is not populated with all the proposals as before. It only gets the updates of the current best_proposal belief from the CNP artefact.

On the participant side, the code agt2.asl, agt3.asl, and agt4.asl are extended with the following two plans:

In the focusCNP plan, the agent reacts to receiving the announcement of the creation of the CNP artefact by looking for the artefact with the given name (variable T) and focussing on it if it has a belief task for the announced task handled by the CNP artefact. The bidding plan reacts to changes in the best_proposal observable property: if the agent’s price is better than the current proposal, the agent places a new bid through the CNP artefact using the bid operation available on CNP artefacts. It is worth noting that agents now have the possibility to improve their bids compared to the bids from other participants throughout the execution of the biding phase. More importantly, agents can retrieve information about all available artefact instances when joining a workspace. The broadcast in the code above alerts agents currently in the system about the new CNP artefact so that agents do not need to be constantly looking for newly created artefacts. Therefore, agents that just entered the system do not miss the opportunity to participate in allocations that had been already announced when they joined the system and that are still within the deadline. Note also that many instances of the same artefact type can be created at the same time, so several CNP processes for various different tasks can be running in parallel. The code of the CNP artefact is as follows:

The execution of these agents has the following steps:

1. 1. agt1 creates the artefact (line 6) and broadcasts the information about the newly created task allocation to all agents (line 9) so that they can focus on the relevant artefact if interested;

2. 2. agt3 focusses on the artefact and places a bid;

3. 3. agt2 focusses on the artefact and places a better bid;

4. 4. agt4 does not focus on that artefact since it is not interested in task t1. As shown in Figure 8, its belief base does not include the observable properties from the CNP artefact.

5. 5. agt1 looks for the best proposal in line 11 (the best_proposal observable property) and simply sets the agent that placed it as the winner in line 13 (of course, agt1 could use more complex criteria to decide the winner);

6. 6. agt3, the winner, does the task.

Figure 8

MindInspector of agents agt1, agt2, and agt4 after the execution of the CNP

The output of the execution is the same, but the belief bases of the agents are quite different: (i) agent agt4 does not focus on the CNP artefact and so does not have the belief about the current best proposal for that task; (ii) agent agt1 does not store all proposals, only the current best one. The state of the belief bases at the end of the execution is shown in Figure 8.

An important point here is that the programmers choices in regards to the use of the programming dimensions may have impacts on the properties of the resulting program. In this section, we have addressed the limitations listed at the end of Section 4.1 by using an artefact-based implementation in which:

1. 1. Agents not interested in the allocation processes (e.g. agt4) simply do not focus on the CNP artefact.

2. 2. Since the current best proposal is an observable property, agents can have better strategies to choose their own bidsFootnote ¹⁵ . For instance, the following plan implements a strategy that always wins the CNP (unless the deadline finishes right before its latest proposal arrives):

   

3. 3. As mentioned before, even though in this version agent agt1 broadcasts an announcement of the newly created CNP instance, agents entering the system can search, for instances, of CNP artefacts available in the system, focus on them according to the tasks that they can handle or are interested in, and place their proposals, provided they are not too late with respect to the deadline that agent agt1 has in its allocateTask plan.

The decision to externalize some operation into an artefact (such as the determination of the current best proposal in our example) should be carefully considered during the design of the system, as it may transfer some decision making from an agent to an artefact, possibly limiting the autonomy of the agents (in this case, the determination of the best proposal). For some applications, in particular open systems where the developer does not know what the incoming agents will do, such a limitation in the autonomy could be useful against malicious agents. Note, however, that, as with all design choices about which dimension to use for implementing a particular feature, this should be carefully considered by designers of a MAS.

5.1 Shaping an agent organization

The organization is mainly used to shape the set of agents into groups and roles (structure), to specify the coordinated achievement of goals (function), and to assign them to agents in the system by means of roles and norms. By assigning goals to roles using norms, we provide a way to abstract away from the agents and to define the functioning of the system independently of the particular agents that will be available at runtime. As soon as agents start to play roles, the organization becomes instantiated, bringing obligatory, permitted, or forbidden goal achievements to the agents in the context of their roles and participation in groups. These organizational abstractions provide support for handling the overall complexity of the system.

As we did with the programming of agents and environment in Section 3, we start with a simple organization program exemplifying the structural, functional, and normative components of an agent organization. In JaCaMo, the organization is specified in a XML file, org.xml in this case. Figure 9 depicts a simplified graphical representation for the content of this file. The structural specification states that for an organization to comply with this specification it must be composed of one group instance of the root group orgGroup. All agents taking part in that organization plays the member role. The group named orgGroup contains subgroups of type taskExecutionGroup , where participating agents can play three roles: hirer (at least one and at most one agent playing it), contractor1 (at least one agent playing it), or contractor2 (at least one agent playing it). An agent cannot play more than one role in this subgroup because there are no compatibility relation between the roles in the specification. These three roles inherit from the abstract role taskHandler the compatibility with the role member (i.e. an agent can play the member role while playing the hirer, contractor1, or contractor2 roles). As role taskHandler is an abstract role, no agent can adopt it directly.

Figure 9

Simplified graphical view of the org.xml organization specification. Only the necessary elements for understanding the organization specification are shown

For this example, the functional specification has only one social scheme (taskExecution). This scheme is composed of a goal decomposition tree stating that by achieving goals g1, g2, and g3 the goal execute is achieved (operator and). Due to their dependencies, they have to be achieved in sequence. As defined by the normative specification, the norms linking the taskExecution scheme to the roles of the taskExecutionGroup state the duties of the agents when participating in the group. In this example any agent is obliged to achieve g1 when playing the hirer role, g2 when playing the contractor1 role, and g3 when playing the contractor2 role. As these goals are part of the scheme, they can only be achieved by agents that are obliged or permitted to do so through the roles they are playing.

We now describe the agents that participate in this organization. An important principle in this programming approach is that agent may achieve goals g1, g2, and g3 required by the organization in their own way. For simplicity here, the same agent program (file d.asl) is used for all agents who participate in this simple organization:

This program simply reuses the actions of the artefacts as defined in Section 3 to achieve the organizational goals. In this first implementation, agents are obedient, that is, they obey obligations, permissions, and prohibitions as determined by the norms of the organizationFootnote ¹⁶ .

In order to deploy such an organization when the system execution is initiated, the JaCaMo project file introduced in Section 3 is enriched with a set of instructions for creating group and scheme instances, and to assign roles to agents:

As we can see, group tag1 is in charge of (responsible-for) the execution of scheme s1 of type taskExecution while group tag2 is in charge of scheme s2.

Participating in the organization means for the agents to adopt roles and to commit to achieve the goals under their duties as stated by the norms. The organization management infrastructure in JaCaMo interprets organization specifications in order to coordinate collective agent activities at runtime. It will start the coordinated execution of a scheme as soon as the group instance that is in charge of it is well formed (i.e. to say that the minimal numbers of agents that are required to play the roles have already adopted those roles) and that the scheme is also well formed (which in this case means to say that all agents have committed to performing the corresponding goals under their responsibility). The developer does not need to implement coordination mechanisms. The infrastructure lets the agents know whenever they have goals to achieve according to the scheme specification. The scheme specification defines the order in which the goals have to be achieved. For example, the scheme specifies that goal g2 has to be pursued after goal g1 has been achieved (due to a g2 dependence relation); agent agt1 is committed to g1 and agent agt2 to g2. In this case, agt2 has to wait for agt1 to achieve g1 before starting to pursue g2 . The infrastructure itself checks if new goals have been enabled to be pursued because its dependencies have been achieved by other agents. The agent committed to a goal that become enabled can then start acting on that particular goal. This coordinated execution within an organization is a distributed process taking place in each of the group and scheme instances that are running in the current state of the organization.

The execution of this system follows these steps:

1. 1. agents, environment, and organization are instantiated as defined in the project file;

2. 2. agt1 is obliged to commit to goal g1 in scheme s1, because it plays role hirer in group tag1, which is responsible for s1;

3. 3. similarly, ag1 commits to goal g1 in scheme s2, ag2 commits to goal g2 in schemes s1 and s2, ag3 commits to goal g2 in scheme s2 and goal g3 in scheme s1, ag4 commits to goal g3 in schemes s1 and s2;

4. 4. the schemes are now well formed and the goal g1 is enabled in both;

5. 5. agents committed to g1 are thus obliged to achieve it and they do so;

6. 6. since g1 is satisfied, g2 is now enabled and agents committed to it are obliged to achieve it and they do so using their own plans;

7. 7. g3 is now enabled and agents committed to it are obliged to achieve it, and they do so.

As can be seen in this example, designers can structure both the set of agents and the collective activity taking place among them. Changing the organization deployment in a JaCaMo project file or the specification in files such as org.xml makes it possible to change the structure and the functioning of the system respectively at the organization instance or at the organization specification levels. For example, even if the system is composed of the set of agents with the previous simple code to achieve each of the goals g1, g2, and g3, the collective activity may differ depending on the way the agent organization is created. By changing the scheme and dependence between goals, we are changing the collective behaviour of the agents, and we can do this without changing any code of the agents and without interrupting the system execution. In the same way, changing the minimum or maximum number of agents playing roles leads to different coordinated activities in the system by limiting or opening the possibility for more or less agents to participate in the execution process. It should also be noted that the system has a boundary to the specification of the organization: only agents being part of the instance of orgGroup have the possibility to participate in some task execution process by adopting either the hirer or contractor1 roles in the appropriate group instance. For example, any agent that is not part of the organization does not receive information about the organization activities. Besides this possibility, organizations introduce means for coordination, expectations on the behaviour of the other agents participating in the same social scheme, modularity in terms of sets of agents (e.g. several group instances of taskExecutionGroup may exist), and in terms of activities (e.g. s1 and s2 in the JaCaMo project file following the defined schemes) attached to different groups of agents.

5.2 Changing the organization

Now that the elements to program organizations have been introduced and we have shown how an initial organization is deployed by the designer through project files, we can discuss how agents themselves can further instantiate their own organization on-the-flyFootnote ¹⁷ . For instance, an agent playing the hirer role may launch a new coordinated task for the agents belonging to its group instance by creating a new instance of the appropriate taskExecution scheme (line 6 below).

Going a step further in this ability for agents to instantiate their organization, we add a new scheme to the previous organization specification. This new taskAllocation scheme aims at coordinating the recruitment of agents to execute tasks g2 and g3 following the CNP introduced in Section 4. It defines a sequence of the cfp, bid, and announce goals. The goal cfp has one argument G which is used to enable the agent that will achieve this goal to specify the task that is the target of the allocation process (e.g. g1, g2, or g3) for which agents will have to bid.

As specified by norms and by the social scheme (taskAllocation), any agent playing role initiator is obliged to manage the task allocation—that is the cfp—and to announce the winner (announce), while agents playing role participant are obliged to make some proposal (bid).

Using this new organization specification, agent agt1 defines two group instances of taskAllocationGroup in which it adopts the initiator role. Both groups are responsible of a social scheme following the taskAllocation specification: one for allocating g2 and one for allocating g3. When the scheme is successfully finished (i.e. goal allocate is achieved), using the plan below, agent agt1 creates a group instance of taskExecutionGroup where it adopts the role hirer and asks the winner of each task allocation process (cf. org.xml and Figure 10) to play the contractor1 or contractor2 roles in the TaskExecutionGroup instance.

Figure 10

Simplified graphical view of the new version of the org.xml organization specification. Only elements necessary for understanding the organization specification are presented here. Note the compatibility relation added between initiator and hirer in order to allow an agent to play both roles in the context of the same orgGroup instance

Using organization specification and programming as shown above, agents can instantiate functional schemes (i.e. social plans), groups, and norms that coordinate and structure the activities taking place in the MAS. The task-allocation process that was hidden and hard coded in the shared coordination artefact of the previous section is made explicit and declarative. Agents have the possibility to reason about and change the protocol, the way the task should be executed, and so forth. Furthermore, openness is facilitated, that is, agents can discover and understand how to participate in interactions following these coordination patterns specified in the functional, structural, and normative specifications.

5.3 Regulated organizations

Besides making it possible for agents to discover and use the groups, roles, and the coordinated activities that could take place, agent organizations also allow agents to regulate their own functioning. This section illustrates this kind of regulation and how openness can be managed through organization programming using norms. Consider that some participants in the taskExecution did not achieve the goals allocated to them, even though they were obliged to do so. In the execution, the scheme does not progress to the next goal in the sequence (goal g3), nor the execution of the scheme is finished, as the organization is waiting for the execution of other goals: goal g2 is enabled and goal g3 is waiting (see Figure 11).

Figure 11

Organization inspector showing scheme s1 for taskExecution

Considering the deadline for goals g2 and g3, after the corresponding elapsed time the platform that manages the current state of the scheme and the corresponding norms raises a signal informing the agents committed to the scheme that some obligations were not fulfilled.

Any agent participating in the scheme can then react to such events. For instance, one of the other agents could choose to add the violating agent into a black list and setting the outstanding goal as satisfied in order to allow the scheme to progress. For that, agents can use a BlackList artefact for sanctioning agents, as exemplified below. A unique instance of this artefact is used to gather the names of the agents that have been blacklisted in previous task allocation processes for being bad contractors (their names is accessible through an observable property containing a list of names of the agents known to have not fulfilled their obligations). The artefact then provides an operation addBadContractor for blacklisting agents. The following plan illustrates the use of that operation:

From this solution, we could go further and use the elements of the organization dimension to enrich the organization specification by including the explicit regulation. Briefly, in JaCaMo sanctions are not directly expressed as an element of the norm formula. However, the normative specification may contain norms that are sanctions or rewards based on the (un)fulfilment of other norms. For instance, a norm can be written to express that any agent playing the hirer role has the obligation to sanction (i.e. to achieve a blacklisted goal) any agent playing contractor1 or contractor2 that do not fulfil their obligations.

5.4 Wrapping up

In this section, we showed how to program organizations structuring and coordinating the activities of agents situated in a shared environment populated with artefacts. From these various programs, we can highlight the following features:

Boundaries and modularity: using the explicit organization model representation and the ability to adopt roles, to create groups, to create schemes, and to assign them to particular groups, we can structure and coordinate the interactions and deployment of the agents in the system. It is also possible to have several and various agent organizations in the same system. Agents can perceive this organizational shaping and represent it through beliefs, as well as to conduct some reasoning about the organizations. Agents can also act on them through the current set of actions that are provided by the underlying organization management infrastructure. In JaCaMo, this infrastructure is deployed by dedicated artefacts providing distributed organization management and uniform interaction means (through agent actions’) between agents and their organization and environment.

Autonomy and regulation: even though organizations have norms, agent behaviour is not regimented in our approach. The MAOP approach that is promoted here allows the agents to keep their thread of decisions with respect to their own set of goals and actions as well as those coming from the organizations and their norms. However, the allowed autonomy is monitored by the organization management mechanisms that trigger events signalling violations. These events may, in turn, lead some agents to making decisions about applying appropriate sanctions.

Adaptation and reorganization: given an organization specification, the examples in this section show how agents can deploy and create various organization instances on-the-fly, and to change them by creating/deleting groups and schemes. This feature of adaptation at the organization-instance level may be extended to the organization specification also. Due to lack of space, it was not possible to illustrate this feature in this paper. Nevertheless, agents do have the possibility to create and change their own organization specification at run time as they do for the organization instances.