AI-augmented Business Process Management Systems (ABPMS) are an emerging class of process-aware information systems that do not follow predefined process models. Instead, an ABPMS uses AI techniques to adapt execution flows dynamically based on the current state, context, and evolving objectives of the business processes it orchestrates. An ABPMS is conversationally actionable if it can interact with users or agents through natural language or other unstructured communication modalities to initiate, support, or guide process executions. This position paper articulates key properties of a conversationally actionable ABPMS, proposes a reference architecture, and outlines research challenges to realize such systems.
Recent advances in AI technology, combined with the increasing availability of business process
execution data, provide the foundation for the so-called AI-augmented Business Process Management
Systems (ABPMS) [
The scope of the actions triggered by an ABPMS in response to the conversations vary depending on the use case. In this respect, we distinguish the following broad categories of use cases:
CEUR
ceur-ws.org
Query: The ABPMS may answer questions about the past and current states of business processes and their executions. Besides (run-time) process monitoring information, e.g., KPI values and related explanations, queries may also address design-time concerns, e.g. process model updates and explanations of process changes. The queries may be issued by users in natural language or by agents using some mutually agreed upon protocol. A query may return answers in natural language, as a graphical output (dashboard, annotated process model, etc.) or using a specific agent communication protocol.
Recommend: The ABPMS generates recommendations for process instance adaptation and process evolution (future states). The ABPMS can provide such recommendations based on internal parametric knowledge or it can combine its knowledge with output retrieved from external components, such as simulators, optimizers, and solvers. Recommendations can be issued proactively by the ABPMS or requested by users or agents through a conversational interface. A recommendation can be presented to users in natural language or sent directly to an automation component to be directly implemented.
Create: The conversations may elicit knowledge leading the ABPMS to create one or more business
process artifacts, such as imperative or declarative business process models, constraints, etc. The ABPMS
may create these artifacts from conversations with domain experts [
Execute: Following a recommendation, the ABPMS may trigger and coordinate a set of actions that result in moving the business process to a new state. Depending on the type of action to be taken, automation is delegated to a suitable component, e.g., an RPA bot for automating the execution of an activity or an agent updating the business rules of an ERP system.
via a communication platform; and (4) updating records in a CRM, ERP or other Systems of Records.
The top subsystem is the conversational layer, which exposes the capabilities of the lower layers
to diferent types of agents via tools. These tools are exposed to agents via a Model Context Protocol
(MCP) [
An agent may leverage tools (herein called components) to, e.g., detect degradations in the performance of a process that may lead to a violation of a Service Level Agreement (SLA). Having detected this risk, the agent may leverage process intelligence components to determine interventions to prevent this SLA violation, and components of the action layer to trigger actions or notifications. The agents in the conversational layer receive instructions and goals from end users, directly (e.g., via a chat interface), or indirectly via agents operating in other systems (e.g., CRM platform).
Conversations do not only happen when external agents (human or not) interact with the ABPMS to obtain information, insights, and explanations about the current state or the history of the ABPMS itself. They also enable actionability, that is, to support actions in a broad sense. Actions may pertain to: (1) The very execution of the process, e.g., approving a purchase order request; (2) Process (re)framing (e.g., adding or removing constraints) and (re)modelling (e.g., evolving a model due to changing requirements); or (3) Decisions and interventions for process improvement, e.g., hiring a new resource to improve cycle time, or deciding to cancel an order because of economic considerations.
In this context, conversing is essential to gather information and insights before taking — or deciding whether to take — an action. For example, an agent would need to ponder the impact of hiring a new resource before committing to do so, or may decide to cancel an order depending on the corresponding penalty. This can only be achieved with good quality guarantees if (i) the agent can converse with other agents, as well as (ii) it can invoke the tools needed Figure 2: Component with inputs, outfor the task at hand. puts, and metadata
A component is conceived as a deterministic, verifiable unit of software that realises a certain task and/or produces some result given some inputs and preconditions. A tool may be a manually crafted software or it may rely on generative AI, but in any case, it is deemed to have gone through suficient quality control to be trusted. As shown in Figure 2, to enable agents in using components and interpreting their results, some key aspects must be described: • Input – an object necessary to invoke the component; e.g., process model required by a simulator. • Parameter – an auxiliary input used to tune the component; e.g., simulator hyperparameters. • Result – an output object produced by the component; e.g. the cycle time returned by the simulator. • Auxiliary output – an additional output produced by the component to help interpreting the output; for example, quantified uncertainty associated to a prediction. • Manifest – a description of the component, its behaviour, and its inputs and outputs; the manifest relates to MCP, as its purpose is to enable agents to discover and properly consume the component. • Behavioral indicator – a quantitative or qualitative indicator characterising the (functioning of the) component along a key functional or non-functional concern.
Table 1 provides a non-exhaustive list of concerns closely relevant to the conversational actionability of ABPMS (Table 1). Most of these concerns are expected to be specified, tracked, and composed using behavioural indicators, as has been done in other areas such as Service-Oriented Architecture.
An agent may employ multiple tools through diferent usage patterns, like concatenating two
components to obtain a new functionality, or invoking two components in parallel and then aggregating
their results. In addition, as pointed out before, it may converse with other agents. This may lead to an
autonomous decision taken by the agent relying on the result of the conversation and of the employed
components, or resulting from collective decision making (akin to multi-agent systems [
A crucial aspect of this architecture is trust. Agents are only deemed trustworthy if they can transparently explain their outputs. This is achieved by enabling agents to trace and articulate how they invoked specific components, what input they provided, and how the resulting outputs contributed to their decisions or responses have been used. This traceability, which relates to the more general concept of ABPMS explainability, ensures that agent outputs are not opaque, but grounded in reproducible and verifiable actions. Actionability is in the components, while conversationality is provided by the agents.
From the above architecture and concerns, we identify the following challenges for ABPMS:
2. How can conversation needs and mechanisms (e.g., MCP) be elicitated and specified to enable an
ABPMS to use discover, understand, and invoke the capabilities of other tools and services? 3. How can the concerns in Table 1 be measured, aggregated, and increased in an ABPMS? 4. How can an ABPMS itself become a component (MCP-based or other) of a larger ecosystem? 5. How can an ABPMS support the automated generation of automations (e.g. RPA, AI agents)?