MaaS Provider Agent (MPA)

At a Glance

• Category: Smart Automation
• Primary environment: MaaS Provider
• Documentation focus: Design reference
• Maturity: TRL 3–4 (first release, M18)
• Related architecture docs: Reference Architecture Guide, Environments

Purpose

The MaaS Provider Agent (MPA) is defined as an intelligent, autonomous software agent that is deployed within the MaaSAI ecosystem. The system has been designed to receive and respond to manufacturing service requests, engage in automated negotiations, and dynamically update its published capabilities on the Cloud-based MaaS marketplace. The architecture of the system under discussion has been developed with the specific purpose of facilitating agile, transparent and secure decision-making throughout the provider-consumer interaction lifecycle.

Primary Actors

The D5.2 usage viewpoint defines roles, permissions, constraints, a role-task matrix, and a use case diagram for this solution.

• System administrator: Install, update and restart agents. Add users, delete users, edit users; constraint: Cannot perform actions related to editing negotiation policies, initiate and manage negotiations
• Provider Power User: Decide on the rules for negotiation and the limits that apply. Change the information you need to get into the services. Manage the knowledge base. Ask for and look at reports that explain how negotiations are going. Check the performance and statistics. Create reports about negotiations with other countries.; constraint: Cannot manage other users, which means it cannot create, edit or delete them.
• Provider Analyst: Ask for and look at reports that explain how negotiations are going. Check the performance and statistics. Create reports about negotiations with other countries.; constraint: Following actions are not permitted: editing negotiation policies, user administration, knowledge base modifications, access credentials or initiating and managing negotiations.
• Provider Agent: Proposals are to be received from the Consumer Agent. Consumer Agent will send their proposals. Check if the offers received are realistic. Manage negotiations based on the rules that have been set out. Decide if the proposals are acceptable or not. Check that everyone is on the same page and get things moving within the company.; constraint: Not possible to perform actions related to the editing of negotiation policies, the administration of users, the modification of knowledge bases, or the management of access credentials.

Use-case diagram extracted from MaaSAI deliverable D5.2.

Functional Components

MPA combines provider-side planning, offer evaluation, negotiation support, and explainability services so responses can be generated quickly and consistently. The functional view shows how planner inputs, consumer-agent interactions, and smart-contract triggers are coordinated before a provider response is accepted or escalated.

Functional components diagram extracted from MaaSAI deliverable D5.2.

Design Baseline

At its core, the MPA is built using the JADE framework and provides a FIPA-compliant agent kernel which handles messaging, behaviour scheduling and lifecycle management. To ensure consistent data exchange and semantic interoperability, ensuring that information exchanged between the MPA and other tools in the MaaSAI ecosystem (e.g., MaaS Consumer Agent (MCA), Planners agent) is interpreted consistently, the agent references a shared domain ontology, defined in OWL (Web Ontology Language), which specifies manufacturing and negotiation concepts. The MPA includes a negotiation handler, a capability publication module and a resource evaluation engine.

Unlike the MaaS Consumer Agent, the MPA does not initiate negotiations; rather, it reacts to proposals received from Consumer Agents. This event-driven activation enables the MPA to assess its availability and manufacturing parameters before finalising a contract.

The MPA’s capability publication module interacts with the Cloud MaaS Marketplace, registering and updating available manufacturing services to ensure real-time visibility of offerings. Changes in machine status, capacity or lead times are reflected automatically or via scheduled updates to preserve accuracy and reliability.

The MaaS Provider Agent (MPA) shares the same architectural principles and core components as the MaaS Consumer Agent (MCA), including the JADE-based agent kernel, ontology module, and communication mechanisms. However, these components are adapted to provider-specific requirements, such as publishing available manufacturing services, validating resource capacity, and managing contract execution. Unlike the MCA, which interacts primarily with consumer planners and edge data storage, the MPA communicates with external systems such as the Cloud MaaS Marketplace (CMM) and provider-side infrastructure to update service availability and synchronize operational data. This ensures that offers are accurate, resources are properly allocated, and negotiations remain consistent across the MaaSAI ecosystem.

Architecture diagram extracted from MaaSAI deliverable D5.2.

Technology Stack

The MaaS Agents (MPA and its consumer-side counterpart, the MaaS Consumer Agent) are built entirely on open-source technologies.

Category	Technology
AI/Agents	Python (> 3.9), SPADE multi-agent framework (XMPP messaging, asynchronous programming), NegMas for the negotiation logic (issue representation, utility-based offer evaluation, concession strategies, counteroffer generation)
Backend/Communication	FastAPI for REST endpoints, Paho MQTT clients, Prosody XMPP server for internal agent communication
Data	PostgreSQL with the TimescaleDB extension for negotiation time series
Frontend	React and Vite (testing and monitoring interface)
Containerisation	Docker / Docker Compose
Licences	open source throughout — mainly MIT (SPADE, FastAPI, React, Prosody), plus Apache 2.0, BSD 3-Clause, EPL-2.0/EDL-1.0 and ISC components

Integrations & External Dependencies

A MaaS Provider Orchestrator Agent (MPOA), hosted within the provider’s own infrastructure, deploys MPA instances on demand — one per incoming negotiation request. This distributed approach lets the orchestrator access real-time data from the local production environment (available capacity, urgent orders, rescheduling) when handling negotiation requests. The agents register with the Cloud MaaS Marketplace (CMM), which synchronises the provider’s published resources, while the negotiation between MPAs and MCAs runs over the secure MQTT broker provided by Point-to-point Secure Messaging (PSM, WP8). Future integrations include the MaaS Provider Planner (WP12) and the Edge Data Storage.

APIs & Interfaces

The provider side exposes REST endpoints invoked by CMM, complemented by MQTT topics and a web UI:

• POST /resources — CMM informs the MPOA about a resource published for the corresponding provider
• GET /requests/{request_id} — retrieve deadlines, availability and costs (quote) for a specific request
• MQTT discovery topic: the MPOA remains subscribed to its own identifier and instantiates a dedicated MPA child agent as soon as a consumer publishes a request identifier
• MQTT bilateral negotiation topics: per-negotiation channels keyed by request and provider identifiers, where the MPA processes offers on the from_consumer lane and publishes counteroffers on the from_provider lane
• React frontend to configure agents (competitive, neutral or flexible profiles, weights, parameter ranges) and monitor negotiations round by round

User Interface

Representative screens of the agents’ user interface in the first release:

Agents’ user interface — negotiations overview and results — MaaSAI deliverable D6.1.

Agents’ user interface — agents screen — MaaSAI deliverable D6.1.

Deployment & Configuration

The solution is fully containerised and deployed as a Docker Compose stack: a Prosody XMPP server, the orchestrator agent backend, a PostgreSQL/TimescaleDB database and the React frontend (users holding both provider and consumer roles host both orchestrators). No host dependencies are required beyond the container engine.

Requirement	Minimum	Recommended
CPU	2 vCPUs	4+ vCPUs
RAM	4 GB	8–16 GB
Storage	20 GB	SSD
GPU	—	CUDA GPU (for future reinforcement-learning workloads)
OS	—	Linux