1 Introduction

Multi-agent systems involve core concepts such as loose-coupling, distribution, reactivity and isolated (local) state. Thus, given also its characteristics, the concept of agents has been widely studied and a large range of tools, programming languages and methodologies developed [5]. However, the adoption of these tools, programming languages and methodologies is not largely seen within industry [10]. In the same time that multi-agent systems have been largely studied, the industry has evolved through a range of enterprise paradigms and models, that have shifted from centralised systems towards highly-decentralised systems, showing properties that were exclusively found in multi-agent systems [9]. Nowadays, the industry has focused on the so-called microservice paradigm, in which systems are built from small, loosely-coupled services that maintain their own state [16]. With microservices, the industry has found a manner to develop systems towards an ecosystem of tools and components that are easy to extend, strong on fault tolerance and scaling [34].

Studies on the convergence of software engineering for microservices and multi-agent systems brings many benefits for both areas [9]. On the one side, from the multi-agent systems perspective, the main benefits are: (i) the embracing of Web models for agents; (ii) the decomposition of agent systems into self-contained subsystems, which can be independently tested, improving reliability and the creation of libraries of agents; and (iii) the alignment of multi-agent systems deployment with the best practice of software engineering into the industry. On the other side, from the microservices perspective, the main benefit is the seamless integration of agent technologies into microservices-based systems [9]. Although the convergence between modern software engineering for microservices and multi-agent systems has been studied, for example, in [9], still it is missing a formalisation for such systems. In this paper, we propose a formal operational semantics to multi-agent microservices. Thus, a formalisation for multi-agent microservices using our semantics can be directly implemented in any agent-oriented programming language that supports such components. The operational semantics provide means to specify programs which are independent of any particular programming language, taking in consideration the main components of multi-agent microservices.

The main contributions of this work are: (i) a template to define the formal semantics of multi-agent microservices, which allows us to specify the evident multiple levels of abstraction present in multi-agent microservices; (ii) abstract instances of the multi-level semantic rules, showing how the operational semantics can be used to define formally the communication processes not only between microservices and agents but also for the treatment of external communication; (iii) a discussion on how the multi-level semantics provide a specification of multi-agent microservices that promote desired characteristics like modularity and reusability. Also, we discuss how the multi-level components provide a clear specification for shared communication artifacts, which is a fundamental characteristic of microservices, given they reduce chattiness [28].

2 Background

2.1 Multi-Agent Microservices (MAMS)

In [9], the authors introduce Multi-Agent MicroServices (MAMS), which is a class of systems comprised of Agent-Oriented MicroServices (AOMS) and Plain-Old MicroServices (POMS). AOMS are microservices built using MAS methodology and they are exposed through well-defined interfaces modelled as a set of Representation State Transfer (REST). REST promotes a view in which all resources are isolated and treated as distinct services. In order to avoid an abundance of network calls, chattiness [28], a microservice may often play the role of a host to multiple resources. Thus, microservices share some characteristics with agents. Agents are not just resources; they are complex rational and decision-making entities. However, an agent can be seen itself as a resource as well as it can be seen as a host for others resources it has access to perceive and act. Also, agents rarely work separately, and multi-agent systems are normally modelled by means of a society of agents that will collaborate, through message-passing, to reach an organisational goal [33]. Another related concept present in microservices and multi-agent systems is visibility. As human organisations, some individuals are supposed to be more communicative than other. For example, in a company, sales and customers support staff are supposed to interact with the external public, while other roles within that organisation will implement internal functions necessary to keep the company running. Concepts of interface agents for organisations are already discussed in the multi-agent system literature [12, 22].

With these ideas of convergent concepts between microservices and multi-agent systems technologies, the authors in [9] have proposed that an agent (or group of agents) can implement a microservice and an organisation of agents (or multi-agent system) could be seen as a service, an approach they named as Organisation as a Service (OaaS). Figure 1 shows an example of two multi-agent systems (services), each system configured through group/set of agents representing microservices within the multi-agent system. In MAMS, agents communicate within their groups, microservices interact through interfaces usually handled by an agent, and multi-agent systems (services) interact through interfaces usually handled by a service.

Fig. 1.
figure 1

Multi-Agent Microservices

Full size image

2.2 Multiple levels in Multi-agent Systems

There are various approaches to developing multi-agent systems that consider different levels of abstraction. In this section, we discuss some of such approaches in order to clarify the existence of such multiple levels in MAS, which supports the manner we are going to define the operational semantics for multi-agents microservices. One well-known practical multi-agent programming framework is JaCaMo [3, 4]. JaCaMo is built upon three existing platforms: Jason [7] for programming autonomous agents, \(\mathcal {M}\textsc {oise}\) [19] for programming agent organisations, and CArtAgO [27] for programming shared environments. JaCaMo emphasises the existence of three levels, in that work called “dimensions”, in a single framework so that all levels can be programmed using the languages provided by the combined platforms mentioned above. Also, the development of MAS based on Electronic Institutions [21, 32] considers the existence of multiple levels in MAS, emphasising that, while electronic institutions focus on the so-called macro-level (societal) aspects, the so-called micro-level has its focus on the agents [30]. Further, the PopOrg (Populational-Organisational) Model [12] also aims to structure the MAS in various levels of abstraction. The model focuses on the dynamics of the different internal organisational levels of the organisation of MAS. In addition, the work in [11] introduces so-called social sub-systems, which account for the structuring of organisational entities into sub-systems within the MAS. Other aspects that emphasises the existence of multiple levels in MAS can be found in the survey [18].

Furthermore, multi-agent microservices inherit such characteristics of multiple levels of abstraction from multi-agent systems. In multi-agent microservices, the multiple levels of abstraction not only promote the system organisation but also promote the modularity and reusability of the system’s components, i.e., microservices.

3 Operational Semantics for Multi-Agent Microservices

The main idea behind structured operational semantics proposed by [26] is to define the behaviour of a program in terms of the behaviour of its parts, providing a structural, i.e., syntax-oriented and inductive, view on operational semantics. Thus, specifying a structured operational semantics, it is possible to define the behaviour of a program in terms of a (set of) transition relation(s). The transition relation(s) take the form of a set of inference rules that define the valid transitions of composite tuples representing the transitions of its components. Defining the operational semantics allows us not only a formal analysis of the behaviour of systems but also studies of relations between systems. Furthermore, operational semantics has an intuitive look and easy-to-follow structure.

In this section, we propose a style of formal semantics for multi-agent microservices, in which their components and interfaces are formalised through an operational semantics. Updates at the system, microservices (group/set of agents), and agents internal state are given by an elegant transition system proposed by [26] extended to embrace multiple levels of abstraction. As will be discussed in this work, the operational semantics provide a formal specification of the system, guarantying the modularity necessary in those systems, encouraging the reuse of those formalisations.

figure a

We argue that our style of operational semantics promotes the following desired characteristics of multi-agent microservices: (i) The modularity of the formalisation, which not only fits into methodologies of software engineering to systems based on services but also simplifies the specification of those systems through a multi-level composition, and clear interaction between components from those multiple levels. It also promotes the scalability, considering that the operational semantics provides a modular approach to formalise the modern forefront on the development of distributed computing towards containerisation. It allows us to specify containers individually; (ii) The reusability of the formalisation, in which components (or even entire levels of the formalisation) could be reused in the development of similar systems; (iii) The clear specification of shared communication artifacts, which are essential in systems built based on the paradigm of microservices, when it is necessary that agents, microservices and system share information, thus avoiding chattiness [28].

3.1 The Basis for MAMS Operational Semantics

In our approach, a system will be represented as a tuple \(\langle s _{ id },\mathcal{M}\mathcal{S}_{s},\mathcal {D}_{ s },\mathcal {M}_{ s } \rangle \) with \( s _{ id }\) the service identifier, \(\mathcal{M}\mathcal{S}_{s}\) a set of microservices (the microservices populating the main service), \(\mathcal {D}_{ s }\) a set of data that service stores at the system level, and \(\mathcal {M}_{ s }\) is the message pooling component for that system. The microservices are represented by the tuple \(\langle ms _{ id },Ag_{ms},\mathcal {D}_{ ms },\mathcal {M}_{ ms } \rangle \) with \( ms _{ id }\) the microservice identifier, \(Ag_{ms}\) a set of agents (which are populating that microservice), \(\mathcal {D}_{ ms }\) a set of data that microservice stores at the microservice level, and \(\mathcal {M}_{ ms }\) is the message pooling component for that microservice. Each agent in the multi-agent system (a member of the microservices) is represented by a tuple \(\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \) with \( ag _{ id }\) the agent identifier, \(\mathcal {G}_{ ag }\) the agent goals, \(\mathcal {B}_{ ag }\) the agent beliefs, and \(\mathcal {A}\) the set of actions that the agent is able to execute.

In order to define the semantic rules, we are going to use a particular style of operational semantics introduced in [23, 24], in which multiple levels of a multi-agent system are considered. Thus, we have the template to the operational semantic rules represented in the semantic rule below, named SemanticRuleName.

In the semantic rule SemanticRuleName, we present a template to define the operational semantics of multi-agent microservices considering their multiple levels of abstraction. At the top of the semantic rule, we have CONDITIONS representing the preconditions necessary to apply such semantic rule, which also represents the context of the system at that moment. Below the conditions, there are three transitions systems: \(\rightarrow _{s}\), \(\rightarrow _{ms}\), \(\rightarrow _{ag}\), representing the transitions occurring in the system, set of microservices, and set of agents, respectively. Note that the set of agents being considered at that particular semantic rule represents the set of agents populating the microservice being considered from the set of microservices populating that system. We use the notation “\(\{\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \ldots \}\)” as a simplified representation for the set of agents, highlighting the particular agent being considered, i.e., \(ag_{id}\) is the agent currently being considered in that semantic rule. The same notation is used to highlight the microservice, from the set of microservices, being considered at that particular semantic rule. Thus, using transitions in three levels, i.e., the service, the microservices, and the agents, we are able to define the operational semantics for multi-agent microservices which is modular and reusable.

3.2 Abstract Examples

In this section, we show abstract examples of common operations regarding multi-agent microservices, for example, the creation of a new microservice in the system, and the treatment of external messagesFootnote 1.

Both, microservices approaches and multi-agent systems communicate through message passing and it should not be different in multi-agent microservices. In order to exemplify some operations in multi-agent microservices, we use the following format for messages: \(\langle \texttt{SENDER}, \texttt{RECEIVER}, \texttt{PERFORMATIVE}, \texttt{CONTENT} \rangle \), in which \(\texttt{SENDER}\) represents the sender of the message, \(\texttt{RECEIVER}\) represents the receiver of the message (a system, a particular microservice, or a particular agent), \(\texttt{PERFORMATIVE}\) represents the speech-act used, representing the intention of the sender, and \(\texttt{CONTENT}\) represents the content of the message, which together with the performative will provide the meaning of that message. For example, \(\langle \texttt{bob}, \texttt{alice}, \texttt{achieve}, \mathtt {closed(door)}\rangle \) has a different meaning than \(\langle \texttt{bob}, \texttt{alice}, \texttt{tell}, \mathtt {closed(door)}\rangle \), in the first message \(\texttt{bob}\)’s desires that \(\texttt{alice}\) closes the door, while in the second message \(\texttt{bob}\) is telling \(\texttt{alice}\) that the door is closed. This representation for messages is commonly used in the multi-agent literature, for example [25, 31]. In the semantic rules, we use a select message function, \(S_{M}\), which selects one of the messages from the message pooling being considered at that semantic rule, according to some priority for treating those messages.

figure b

In the first semantic rule, \(\texttt{CreateMicroService}\), we show how the system treats a request for a new microservice. In this semantics rule, the select message function, \(S_M()\), selects the message \(\langle \textit{sender}, s _{ id }, \mathtt {create\_microservice}, \langle ms _{ id },Ag_{ms}, \) \( \mathcal {D}_{ ms },\mathcal {M}_{ ms } \rangle \rangle \), executing the creation of such microservice. We assume that the sender of the message has permission to create a new microservice. In this case, both levels, the system and the microservices levels suffer a transition, represented in (a) and (b), respectively. Basically, the system updates the message pooling removing that message, considering that it already has been treated by the system, and creates a new microservice \(\langle ms _{ id },Ag_{ms},\mathcal {D}_{ ms },\mathcal {M}_{ ms } \rangle \) that will populate the system, represented by “\(\{ \ldots \} \rightarrow _{ms} \{\langle ms _{ id },Ag_{ms},\mathcal {D}_{ ms },\mathcal {M}_{ ms } \rangle \ldots \}\)”, i.e., the set of microservices is updated with that particular new microservice. Such request should include all information necessary to create the microservice, including the microservice identifier \( ms _{ id } \), the set of agents, \(Ag_{ms} \), that will populate that microservice, the relevant data to keep at the microservice level, \(\mathcal {D}_{ ms } \), and a message pooling for that microservice, \(\mathcal {M}_{ ms } \).

figure c

In the semantic rule CreateAgentS, we show how the system treats a request for the creation of a new agent inside a particular microservice \( ms _{ id } \). Considering that this request comes from a source that is external to the system, this request first will be treated by the system message pooling, as we show in the semantics rule CreateAgentS, which forwards the message to the corresponding microservice \( ms _{ id } \). Note that, at (a), both components \(\mathcal{M}\mathcal{S}_{s} \) and \(\mathcal {M}_{ s } \) are updated, give that updates at (b) always will cause an update to the \(\mathcal{M}\mathcal{S}_{s} \) component, given it represents the set of microservices populating that system.

When the microservice treats a request for creating an agent, represented in the semantic rule CreateAgentMS, by selecting the message \(\langle \textit{sender}, ms _{ id }, \) \(\texttt {create\_agent}, \langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \rangle \) from its message pooling \(\mathcal {M}_{ ms } \), it updates the message pooling component, \(\mathcal {M}_{ ms } \), and the set of agents populating that microservice, \(Ag_{ms} \), including the agent \(\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \) to the set of agents populating that microservice, represented in (c) by “\(\{ \ldots \} \rightarrow _{ag} \{\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \ldots \}\)”. Note that, similar to the previous semantic rule, both components at (b) are updated: the set of agents populating the microservice \( ms _{ id } \) represented by \(Ag_{ms} \) and the messsage pooling \(\mathcal {M}_{ ms } \).

We assume that external communication is treated by the system, in which an interface for authentication could be implemented through the message pooling component, \(\mathcal {M}_{ s } \). However, microservices communicate directly through shared artifacts, which reduces the chattiness [28]. In the next semantic rules, we present an example of communication between microservices, following the message format introduced above.

In the semantic rule SendRequestInfoMS, an agent \( ag _{ id } \) selects a goalFootnote 2 to be executed using the goal selection function \(S_G()\), which returns the goal \(\texttt {request(}\psi \texttt {,} ms _{ 2 } \texttt {)}\). Consequently, \( ag _{ id } \) posts a message \(\langle ms _{ 1 }, ms _{ 2 }, \texttt {Request}, \psi \rangle \) in the message pooling of the microservice \( ms _{ 2 } \), requesting the information \(\psi \) from the microservice \( ms _{ 2 } \). Then, the agent \( ag _{ id } \) updates its goals, considering that it reached that goal. Note that \( ag _{ id } \)’s goals are updated at (c), which causes an update to the set of agents, \(Ag_{ ms _{ 1 }} \), populating the microservice \( ms _{ 1 } \) at (b). Also, the message pooling of the microservice \( ms _{ 2 } \) is updated with that new message at (b). Finally, given that both microservices \( ms _{ 1 } \) and \( ms _{ 2 } \) have been updated, consequently the set of microservices of the system \( s _{ id } \), \(\mathcal{M}\mathcal{S}_{s} \), also is updated at (a). Note that, the operational semantics allows us to specify multiple elements from the sets of microservices and agents. In order to make it clear to which set of agents we refer at the transition (c), those sets are labelled with their respective microservices. In the semantic rule SendRequestInfoMS, \(\{\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \ldots \}_{ ms _{ 1 }}\) represents the set of agents \(\{\langle ag _{ id },\mathcal {G}_{ ag },\mathcal {B}_{ ag },\mathcal {A} \rangle \ldots \}\) populating the microservice \( ms _{ 1 } \).

figure d
figure e

In the semantic rule ReceiveRequestInfoMS, the microservice \( ms _{ 2 } \) selects the message \(\langle ms _{ 1 }, ms _{ 2 }, \texttt {Request}, \psi \rangle \) from the microservice message pooling \(\mathcal {M}_{ ms _{ 2 } } \) through the select message function \(S_M()\). Also, considering that \( ms _{ 2 } \) owns the requested information, i.e., \(\psi \in \mathcal {D}_{ ms _{ 2 } } \), it answers the request message posting a message \(\langle ms _{ 1 }, ms _{ 2 }, \texttt {Answer}, \psi \rangle \) in the message pooling of the microservice \( ms _{ 1 } \). Both messages pooling are updated at (b), there is no update at (c), and, given that two microservices of the system have been updated, then the set of microservices of that system, \(\mathcal{M}\mathcal{S}_{s} \), also is updated at (a).

Finally, in the semantic rule ReceiveInfoMS, the microservice \( ms _{ 1 } \) selects the message \(\langle ms _{ 2 }, ms _{ 1 }, \texttt {Answer}, \psi \rangle \) from its message pooling \(\mathcal {M}_{ ms _{ 1 } } \) through the select message function \(S_M()\). Then, the message is removed from the message pooling \(\mathcal {M}_{ ms _{ 1 } } \), and the microservice data \(\mathcal {D}_{ ms _{ 1 } } \) is updated with that information. In that semantic rule, no agent is updated, thus there is no update at (c). At (b), both, the message pooling \(\mathcal {M}_{ ms _{ 1 } } \) and data \(\mathcal {D}_{ ms _{ 1 } } \) components of the microservice \( ms _{ 1 } \) are updated, and; therefore, the set of microservices of that system, \(\mathcal{M}\mathcal{S}_{s} \), also is updated at (a).

4 Example - Taxi Service Application

In this section, we discuss how our approach for multi-level semantics for multi-agent microservices can be used to specify systems that already have been implemented according to the MAMS paradigm. In particular, we discuss how some processes from a taxi service application, described in [2], could be formalised using our approach. In [2], the authors propose a multi-agent system that is responsible for providing a taxi allocation service, in which taxis drivers dynamically enter the system, becoming available for allocation. When a client requests the system for transportation, the microservice responsible for treating requests in that particular area that the client departs from allocates one of the available taxis drivers to that client. In the system, different areas are covered by different microservices according to an architecture based on MAMS [9], and the microservices are dynamically created according to the system’s demand.

Figure 2 shows the dynamism of the microservices according to the areas covered by the system. Each area is covered by a microservice responsible for registering, receiving requests, and allocating taxis drivers.

Fig. 2.
figure 2

Dynamic reorganisation for geometric treatment. It shows an evolution from the top-left configuration to the bottom-right configuration [2].

Full size image

In the system proposed by [2], one of the main operations is to create a new microservice always when a particular region (controlled by a microservice) has too many registered taxis drivers and requests, spliting such region into two small regions, one of them controlled by the new microservice. This situation can be observed in Fig. 2, in which region A01 is divided in two regions, the old microservice remains responsible for A01, and a new microservice becomes responsible for that new region A04.

First, the agent called controller01, which populates and is responsible for the region A01, requests to the taxi service system TX01 to create a new microservice A04, populated by controller04, which will be responsible for that region and its registered taxis, i.e., \(\varDelta _{A01'}\) contains all registered taxis in the region of A04. The rule CreateMicroServiceA04 shows how TX01 processes this message creating the new microservice A04.

In the application proposed in [2], each user’s application (clients and taxis drivers) runs an agent that interacts with the user. While clients’ application can request for taxi drivers, taxi drivers’ applications allow them to register in the systems, being notified always that a client is allocated to them.

Continuing our example, imagine that a client in region A01 requests a taxi driver to go from a particular address at region A01 to another address at region A04. Also, imagine that the microservice responsible for A01 has no taxi drivers available, thus it requests to microservice A04 the closest taxi driver in the region A04. This request can be observed in the semantic rule SendRequestInfoMSA04.

In the semantic rule SendRequestInfoMSA04, the controller agent, in the microservice A01, responsible for allocating taxi drivers to clients, i.e., controller01, selects the goal request(closest(TD,A01),A04) from its goals, which can be achieved by sending a message to A04 requesting the information closest(TD,A01). Thus, a message of the type \(\langle A01, A04, \texttt {Request}, closest(TD,A01),A04) \rangle \) is posted in the message poll \(\mathcal {M}_{A04}\) and its goals are updated accordingly.

In the semantic rule ReceiveRequestInfoMSA01, when the microservice A04 selects that message from its message pool \(\mathcal {M}_{A04}\), and the microservice A04 has that particular information in their data base \(\mathcal {D}_{A04}\), then it answer that particular request posting a message \(\langle A04, A01, \texttt {Answer}, closest(tx245,A01),A04) \rangle \) into A01’s message poll \(\mathcal {M_{A01}}\), informing that the taxi tx245 is the closest taxi from A01.

Finally, in the semantic rule ReceiveInfoMSA04, when the microservice A01 receives the requested information, selecting that message from the message poll \(\mathcal {M}_{A01}\), it updates its database \(\mathcal {D}_{A01}\) with that particular information, also removing the message \(\langle A04, A01, \texttt {Answer}, closest(tx245,A01),A04) \rangle \) from its message poll. Now, A01 microservice is able to allocate that taxi driver tx245 to that particular client.

figure f

5 Related Work

In [15], the authors propose an Agent Infrastructure Layer (AIL) for BDI-style programming languages, aiming to (i) provide a common semantic foundation for various BDI languages, and (ii) support formal verification through an optimized model-checker. They design AIL based on comprehensive operational semantics from [14], claiming it encompasses all key features of common BDI languages.

In [13], the authors introduce operational semantics for modularisation, which they argue simplifies the implementation of agents, roles, and profiles—key aspects in structured programming. They provide operational semantics for creating, executing, testing, updating, and realizing module instances, essential for agent programming.

In [17], operational semantics are provided for managing goals—dropping, aborting, suspending, and resuming them. The authors argue that these semantics clarify how an agent handles its goals and support the verification of correct agent behavior. They emphasize that this work contributes to a detailed specification of appropriate operational behavior when a goal is pursued, succeeds, fails, or undergoes changes by the agent.

In [11], the author proposes an operational semantic framework for legal systems within agent societies, modeling their structure and dynamics. This work focuses on actions within legal systems (internal and external legal acts, social acts, etc.) under an action-based dynamics, where system transitions are determined by actions of legal organs and legal subjects. It exemplifies the use of operational semantics to formalize multi-level systems.

In [29], the authors propose a semantic framework for \(\mathcal {M}\textsc {oise}^+\) [19] and a linear temporal logic (LTL) to express its properties. They argue that organizational specifications help agents achieve their goals and prevent undesired behavior by imposing organizational constraints on agents’ behavior, which they must consider in decision-making. The work defines the formal semantics of \(\mathcal {M}\textsc {oise}^+\), focusing on ensuring agents respect (i) preconditions for organizational actions and (ii) acquaintance and communication links.

As mentioned before, the use of operational semantics has been quite extensive in multi-agent languages so we cannot cover all that literature here. Our work differs from all those in that we present a new style for the semantics of multi-level systems which has been developed to the formalisation of multi-agent microservices. We are not focused on a special semantics for BDI languages as in [15], in semantics for module-related actions [13], in semantics for goals [17], in semantics for legal systems [11], or semantics for the \(\mathcal {M}\textsc {oise}\) model [29] specifically. We focus on proposing an operational semantics to the formalisation of multi-agent microservices that takes into account the desired characteristics of the software engineering based on microservices, i.e., modularity, scalability, reusability, and the specification of shared communication artifacts. To the best of our knowledge, we are the first to propose a formalisation for multi-agent microservices, providing a template that considers the multiple levels of such systems, and also promotes those desired characteristics.

6 Conclusion

In software engineering, there are many benefits of formal specification of systems [1, 20]: (i) it allows the proof of formal properties; (ii) it allows a concise description of high-level behaviour of the system; (iii) it eliminates imprecision and ambiguity; and (iv) it allows model checking the system.

While operational semantics has been almost a standard method for the formalisation of agent-oriented programming languages, only recent research has been applied to make those formalisations adequate to the multiplicity of levels of abstraction (i.e., organisation, groups, agents, environment, etc.) present when engineering multi-agent systems, and there is no such work on the formalisation of multi-agent microservices. Following those recent approaches, in this work, we introduced an approach to the formalisation of multi-agent microservices using operational semantics; we use an approach based on the multi-level semantics proposed by [24].

We introduced a template for semantic rules that provide separated transition systems to multiple levels of multi-agent microservices. We also demonstrate how our template can be used to formalise some operations commonly present in multi-agent microservices, detailing how different (sets of) components are represented through the semantic rules. Our approach allows the representation of the interactions between components of different levels. Given the complexity and ubiquity of such multiple levels in multi-agent microservices, the approach seems to allow for a clearer understanding of such complex semantics, improving its readability. Furthermore, with the multi-level representation, our operational semantics style also provides independence between the specification of the various levels present in multi-agent microservices, so that each level is formalised through its own transition system. This promotes the modularity and reusability of formal models.

Using the multiple levels of formalisation, it is possible to make clear the representation of shared communication artifacts and how the different components of the system interact with such shared components, as we have illustrated in this paper through the formalisation of abstract operation for communication in multi-agent microservices. Shared communication artifacts are considered an essential part of the paradigm based on microservices, given they avoid chattiness [28]. In our future work, we intend to explore other relations between the multiple levels of multi-agent microservices. Also, we intend to investigate how our multi-level semantics and shared communication artifacts can play a part in research towards model checking of such systems [6], towards the verification of multi-agent microservices.