Agent-Oriented and Multi-Agent Programming

1. AgentSpeak(L): BDI agents in a logical, computable language

AgentSpeak(L) was originally proposed by Rao [Rao, 1996] as a programming language for BDI agents, with an elegant notation based on logic programming. It was inspired by the PRS architecture (Georgeff & Lansky), dMARS (Kinny), and BDI Logics (Rao & Georgeff), and was conceived as an abstract programming language aimed at theoretical results — bridging the gap between BDI specification logics (complex, hard to compute) and implemented BDI systems (which used the three attitudes as data structures).

An AgentSpeak plan has the general structure:

triggering event : context <- body.

• the triggering event denotes the events that the plan is meant to handle;
• the context represents the circumstances in which the plan can be used;
• the body is the course of action to handle the event if the context is believed true at the time the plan is chosen.

Plans are context-sensitive, event-invoked recipes that allow hierarchical decomposition of goals as well as execution of actions — syntactically similar to definite clauses of logic programming, but different in behaviour. At run time, an agent consists of a set of beliefs, a set of plans, a set of intentions, a set of events, a set of actions, and a set of selection functions; the interpreter’s operational semantics was formalized as a labelled transition system, giving the language a proof theory directly related to its execution.

2. Jason: a practical AgentSpeak platform

Jason is a BDI agent programming language and platform implementing the operational semantics of a variant of AgentSpeak(L) — a Java-based interpreter, nowadays one of the most used agent programming technologies. It has various extensions aimed at making it a more practical programming language (definition of the MAS, communication, customisation hooks), and is highly customised to simplify extension and experimentation. The reference monograph is Bordini, Hübner and Wooldridge, Programming Multi-Agent Systems in AgentSpeak Using Jason (Wiley, 2007).

The main runtime structures: a belief base (where beliefs are stored), a set of events (to keep track of events the agent will have to handle), a plan library (all plans currently known by the agent), and a set of intentions (each intention keeps track of the goals the agent is committed to and the courses of action it chose, for one of various foci of attention).

The Jason interpreter’s basic reasoning cycle:

1. perceive the environment and update the belief base;
2. process new messages;
3. select an event;
4. select relevant plans;
5. select applicable plans (context check);
6. create/update an intention;
7. select the intention to execute (and execute its next step).

3. Jason language constructs

Beliefs are represented by annotated literals of first-order logic: functor(term1,…,termn)[annot1,…,annotm]. Beliefs are updated by perception (source(percept)), by intention (the operators + and - add/remove mental notes with source(self)), and by communication (a tell message adds a belief annotated with the sender, e.g. .send(tom,tell,lier(alice))).

Goals have the same syntax as beliefs but are prefixed by ! (achievement goal: goal to do) or ? (test goal: goal to know); they can be added by intentions, or by communication (achieve, askOne/askAll messages). Triggering events happen as consequences of changes in beliefs or goals: +b, -b, +!g, -!g, +?g, -?g.

Plan bodies may contain belief operators (+, -, -+), goal operators (!, ?, !!), internal actions (jia.get(X)), constraints, and external actions (close(door)). Internal actions do not change the environment — they are code executed as part of the agent reasoning cycle, used to invoke legacy code elegantly; standard ones include .print, .send, .my_name, .intend, .drop_intention.

Failure handling is first-class: plans can react to goal failure events (e.g. -!g : true <- !g. retries a goal), and meta-programming allows an agent to ask for plans on demand (askHow) and add them dynamically — plan failure is an event like any other, which is exactly what makes BDI programming robust in dynamic environments.

4. Agent-oriented programming (Shoham)

Agent-oriented programming was originally proposed by Shoham [Shoham, 1993] as a new computational framework — a specialization of object-oriented programming — based on the use of mentalistic notions and a societal view of computation (anthropomorphism), in line with the Knowledge Level philosophy. The state of an agent consists of components such as beliefs, decisions, capabilities, and obligations; for this reason it is called its mental state, described formally in an extension of standard epistemic logics (temporalized knowledge/belief operators, plus operators for obligation, decision and capability). Agents are controlled by agent programs that include primitives for communicating with other agents: in the spirit of speech act theory, each communication primitive is of a certain type — informing, requesting, offering, and so on.

Programming languages for agents have developed a lot since then, but still do not constitute a fully mature paradigm; most of them are based on the BDI model/architecture and reactive planning. Examples of agent and MAS technologies: JADE, Jason, GOAL, 2APL, SARL, JaCaMo; historical languages include Agent0, AgentSpeak(L), MetateM, 3APL, Golog.

5. Multi-agent programming and its dimensions

Multi-agent programming (MAP) extends AOP from the single agent to the MAS perspective: communication, coordination and organisation. Programming a MAS means programming along multiple dimensions, each with its own data structures and programming instructions:

• Agent dimension (AOP) — data structures: beliefs, goals, events, capabilities, plans, reasoning rules; instructions: generate plans for events/goals, process exceptions, select and execute plans; the agent interpreter/deliberation loop determines the behaviour.
• Interaction dimension (IOP) — speech-act based communication, protocols, interaction-oriented programming.
• Environment dimension (EOP) — data structures: resources, services, objects, artifacts, workspaces; instructions: realizing action effects, providing events and sense information, synchronising actions, long-term operations.
• Organisation dimension (OOP) — data structures: agents, roles, groups, norms (obligations, prohibitions, permissions, violations), dependencies, deadlines, sanctions; instructions: endogenous control (part of the agent program) or exogenous control (monitoring agent behaviour, enforcing/regimenting organisational laws).

Multi-agent oriented programming (MAOP) exploits multiple dimensions in modelling complex systems and designing multi-agent systems [BBHR]: the agent, environment and organisation dimensions as first-class, integrated programming abstractions — the subject of Section 9 with JaCaMo.

6. Environment programming and the A&A meta-model

The environment is intrinsically related to the notions of agent and multi-agent system (an agent is situated in an environment). Environment programming accounts for conceiving the computational environment where agents are situated as a first-class abstraction for programming MAS — a part of the system that can be designed and programmed, aside from agents, to encapsulate functionalities exploited by agents at runtime [Ricci, Piunti, Viroli 2011]. This improves modularity, extensibility and reusability of the MAS as a software system. The A&A (Agents & Artifacts) meta-model [Omicini, Ricci, Viroli 2008] makes the environment first-class:

• Agents — autonomous, goal-oriented, pro-active entities; they create/share/use artifacts for supporting their activities, besides direct communication.
• Artifacts — non-autonomous, function-oriented, stateful entities; they model the tools and resources used by agents — anything useful to represent/observe/control for the agents’ purposes. An artifact abstractly exposes a usage interface (operations), observable properties, and observable events/signals.
• Workspaces — group agents and artifacts, defining the topology of the computational environment.

A basic taxonomy of artifacts:

• Individual or personal artifacts — functionalities for a single agent’s use (e.g. an agenda for managing deadlines, a library);
• Social artifacts — functionalities for structuring and managing interaction in a MAS: coordination artifacts, organisation artifacts (e.g. a blackboard, a game-board);
• Boundary artifacts — represent external resources/services (e.g. a printer, a Web Service) or devices enabling I/O with users (GUI, console).

7. CArtAgO and the artifact-based interaction model

CArtAgO (Common ARtifact infrastructure for AGent Open environments) is the computational framework/infrastructure to implement and run artifact-based environments: a Java-based programming model for defining artifacts, a set of basic APIs for agent platforms to work within artifact-based environments, distributed and open MAS support (workspaces distributed on Internet nodes, Role-Based Access Control), and open-source technology.

The interaction model:

• Use — performing an action corresponds to triggering the execution of an operation on the artifact’s usage interface; operation execution is a process structured in one or multiple transactional steps, asynchronous with respect to the agent, and its completion (with success or failure, possibly with feedback) causes action completion.
• Observation — agents dynamically select which artifacts to observe (focus/stopFocus); by focusing an artifact, observable properties are mapped into the agent’s dynamic knowledge (e.g. the belief base) and signals into percepts about observable events.
• Linkability — artifacts can be linked through link interfaces, enabling inter-artifact interaction and the design of distributed environments realized by sets of linked artifacts, possibly hosted in different workspaces.

Each workspace contains by default a predefined set of artifacts: the workspace artifact (makeArtifact, lookupArtifact, focus, security), the node artifact (createWorkspace, joinWorkspace), a console (println), a blackboard/tuple space (out, in, rd), and more — a pre-defined repertoire of actions available to every agent.

The example shows the pattern: an @OPERATION annotated method updates an observable property and emits a signal; a user agent creates and uses the artifact, while observer agents focus it and react to property changes (+count(V)) and signals (+tick). Long-term operations with await/guards support coordination artifacts like a bounded buffer, and internal operations implement controllable processes such as a clock.

8. The organisation dimension: Moise+

In open MAS we do not know what kind of agent will enter the system; the organisation is a set of behavioural constraints that a group of agents adopts to control the agents’ autonomy and easily achieve their global purposes — based on how human societies use social roles for globally coherent behaviour. The Moise+ organisational model (Model of Organisation for multI-agent SystEms) unifies three dimensions in an Organisational Specification (OS):

• Structural specification — roles and groups: the behaviours an agent is responsible for when it adopts a role (individual level), acquaintance/communication/authority links between roles (social level), and the aggregation of roles into groups (collective level), including well-formedness constraints (e.g. exactly one goalkeeper, three backs in a defense group).
• Functional specification — the society’s global plans: a social scheme decomposing organisational goals into sub-goals, grouped into missions, with temporal constraints (sequence, parallelism, time-to-fulfil).
• Deontic specification — norms binding roles to missions: obligations, permissions and prohibitions relating the structural and functional dimensions (e.g. a bricklayer is obliged to achieve floors laid once the site is prepared).

S-Moise+ is the middleware that fills the gap between organisational constraints and agent autonomy: it ensures that all agents follow the organisation without requiring that they are developed in a specific language or architecture — an exogenous, organisation-centred approach suitable for heterogeneous and open systems. When a set of agents adopts an OS they form an Organisational Entity (OE), whose history runs through events like agents entering/leaving, group creation, role adoption, and mission commitment.

9. JaCaMo: multi-agent oriented programming

JaCaMo [Boissier, Bordini, Hübner, Ricci, Santi 2013] brings together agent-oriented programming, organisation-oriented programming and environment-oriented programming into a single programming model and platform — multi-agent oriented programming. It builds upon three existing platforms, one per dimension:

• agent dimension — BDI and the Jason agent programming language;
• environment dimension — based on the A&A conceptual model and the CArtAgO platform;
• organisation dimension — based on the Moise model.

The integrated programming meta-model defines the synergies among the dimensions, which come for free (transparently, without extra programming):

• Agent–environment (A–E): agents’ external actions are semantically mapped into artifacts’ operations, and artifacts’ observable properties/events into agents’ percepts (beliefs and triggering events). Benefits: a dynamic action repertoire (the set of actions available is reshaped by creating/disposing artifacts), a more expressive action model (process-based semantics: long-term, overlapping actions, coordination), and a well-defined success/failure semantics for actions.
• Organisation–environment (O–E): the organisational infrastructure is reified in the environment as organisational artifacts — OrgBoard, GroupBoard and SchemeBoard — providing actions to adopt roles, commit to missions, signal goal achievement, and observable properties exposing the organisational state. Outcomes: uniformity, distribution, dynamism, heterogeneity, and high-level reorganising capabilities.
• Agent–organisation (A–O): organisational goals are delegated to agents through obligations; when an agent perceives an obligation and chooses to adopt it, a corresponding individual goal is created — the agent remains free to decide which courses of action to use (autonomy preserved).

The Building-a-House example (from the JaCaMo distribution) shows all three dimensions working together: Giacomo runs auctions through auction artifacts (agent–environment), winners join the house-building organisation adopting roles such as site_prep_contractor (agent–organisation), and the scheme creates obligations — e.g. obligation(companyB, achieved(s1, site_prepared), “4/1/2011”) — which the agents perceive and adopt as individual goals. Changing the scheme specification changes the behaviour of the whole agent team without changing a single line of agent code: the scheme is the program for social coordination, and the SchemeBoard artifact is its interpreter.

10. The cognitive era: from programming to learning

Learning is a key aspect also for cognitive architectures, with different kinds of approaches in the literature: “chunking” (learning from experience), Reinforcement Learning (as sub-symbolic learning), Bayesian learning (uncertainty), … and an open research line on integrating symbolic and sub-symbolic approaches. From an engineering point of view this is the question of programming vs learning — Software 2.0 (and now 3.0).

The cognitive era narrative (IBM, 2015): from the Tabulating Era (1900s–1940s) through the Programming Era (1950s–present) to the Cognitive Era (2011–), “cognitive computing as a necessary and natural evolution of programmable computing”. And Software 2.0 (Karpathy, 2018): the modern form of software alchemy where instead of writing programs we train them — requiring “a radical rethinking of the ancestral software engineering and programming practices” (Meijer, PLDI 2018). Yet the debate is open: Software 2.0 so far misses qualities essential for software engineering — robustness, understandability/explainability, modularity (Parnas, 2017).

The module frames the programming–learning segment: from fully-designed, programmed agents (e.g. BDI) to purely trained agents (e.g. RL agents), exploring learning as a core/enabling feature integrated in the full engineering process, supported by the agent interpreter and possibly by the agent programming languages. A recent approach: BDI agents with soft + hard plans [Bosello & Ricci 2019] — hard plans are programmed/classic, soft plans are learnt during development (“education”) and possibly refined/adapted at runtime.

And the provocations: “the end of agent programming?” — not really, but triggering/renewing interesting directions (Bordini, El-Fallah Segrouchni, Logan, Hindriks, Ricci, JAAMAS 2020; Ricci, EMAS 2021 invited). Agent development as an education process (metaphor): set up an agent with a first designed/programmed part, then grow the agent through an education-like process based on learning techniques — objective, technique/method, assessment, monitoring, integration. From Software 2.0 to “Software 3.0”: “the hottest new programming language is English” (Karpathy) — vibe coding and full-fledged agentic-based software development (Replit Agent 3, Google Antigravity).

Finally, hybrid cognitive architectures: agentic AI lacks solid engineering foundations; open research lines include hybrid agent architectures — (Cognitive) Language Agents + BDI Architecture — and empowering the standards emerging in agentic AI with concepts and results from Autonomous Agents and MAS: the notion of “tool” (and MCP) vs. the notion of artifacts (and A&A), and the A2A protocol vs. agent communication languages.

11. Agents for DDD — back and forth

The closing reading of the module [Ricci, Burattini, Ciortea, Castellucci, 2024] explores the bi-directional interaction between DDD (Chapters 6–10 of this course) and Agent-Oriented Software Engineering. The two communities tackle complexity from different perspectives: DDD mainly concerns structural complexity (inherent complexity of entities within a domain), while AOSE mainly concerns dynamic complexity (autonomy, reactivity, adaptability, distribution).

• DDD’s relevance for AOSE: DDD is a proven method for building consensus and structuring domain models; in MAOP, domain knowledge can live in the agent, environment, interaction or organisation dimensions — DDD’s Bounded Contexts add a vertical separation across the dimensions, and the Ubiquitous Language keeps knowledge consistent across layers.
• DDD’s limitations that call for agents: DDD helps mitigate structural complexity, but dynamic complexity (arbitrary connections among autonomous components) is not really addressed in DDD — domain events are one step, yet proper abstractions for managing events to accomplish tasks remain an open issue.

Empowering DDD with agent-oriented modelling happens at two levels:

• Single Bounded Context, with increasing metamodel complexity: a Bounded Context as a single agent (the thermostat example: goal keep_temperature(Min,Max), beliefs from sensors, actions on the HVAC — with the hexagonal/clean architecture preserved: percept/action ports and adapters keep the domain model decoupled); as a single agent plus environment (artifacts for the temperature sensor, user preference subsystem, HVAC — artifacts as DDD aggregate roots of the environment); or as a multi-agent system (multiple communicating agents sharing the environment).
• Bounded Context integration: multiple Bounded Contexts as interacting agents (each context modelled as an agent or as part of the environment; high-level interaction semantics via ACLs such as FIPA ACL or KQML, or protocol languages such as BSPL), or as an agent organisation (groups and roles from AGR/Moise for dynamic structures — e.g. a smart room whose configuration adapts to the users entering, based on their roles).

Note that agent and artifact concepts are used here first of all as modelling abstractions for the domain — Bounded Contexts modelled as agents can be implemented with mainstream technologies such as (micro)services.

Check your understanding