AUTOBIZ: Pushing the Boundaries of AI-Driven Process Execution and Adaptation

In today’s dynamic digital landscape, business processes (BPs) are expected to operate autonomously and adapt their structure and behavior to evolving goals, conditions, or constraints [4]. Such systems are known as autonomous business process systems (ABPs), whose key capability is self-modification.

Modifications in ABPs fall into two main categories [21]:

• $\mathrm{■}$

  Adaptation: Short-term, instance-specific changes to handle unforeseen conditions without altering the overall process schema. These real-time adjustments ensure continuity and resilience, for example by rerouting workflows, reallocating resources, or integrating new data sources during execution.

• $\mathrm{■}$

  Evolution: Long-term changes to process logic or models, affecting all future instances. These deliberate updates are driven by recurring issues or strategic shifts and may involve redesigning decision logic or updating policies.

Without these capabilities, ABPs risk brittleness and reduced responsiveness. Thus, engineering self-modifying capabilities is essential for robust, flexible process management.

The importance of adaptive and evolving BPM systems has long been recognized [3, 21, 11], with prior work exploring both adaptation [16, 20, 10, 6, 23, 26] and evolution [12, 28, 27].

In this report, we provide:

• $\mathrm{■}$

  A definition of self-modification in ABPs, distinguishing adaptation and evolution.

• $\mathrm{■}$

  A structured view of the dimensions, goals, and triggers of modifications in ABPs.

• $\mathrm{■}$

  An outline of key challenges in governance, uncertainty, and continuous learning.

To illustrate self-modifying ABPs, consider an automated warehouse where fleets of robots transport shelves to human pickers across a high-throughput environment.

If a robot fails during the busy holiday season, nearby robots reroute around the blockage, and the order is reassigned. Workers receive updated instructions, ensuring minimal disruption. This short-term response (adaptation) resolves the immediate issue without changing the overall process model.

The system also logs the failure and, after noticing similar breakdowns after about 1,000 picks, introduces a maintenance rule requiring inspection every 900 operations. This mid-term, model-level change (evolution) refines policies to prevent recurrence.

Together, these examples show how ABPs span from localized adaptations to deliberate evolution, implemented with varying degrees of automation.

Modifications in ABPs can be classified along several dimensions:

Today’s business process systems typically operate at an augmented level of autonomy, where intelligent components assist human workers but do not independently drive process execution or change. To move toward truly autonomous business process systems (ABPS), we propose a structured roadmap of autonomy levels, inspired by the SAE J3016 standard for driving automation [24]. While Sheridan’s Levels of Automation [29] offer an alternative, they focus on isolated task automation rather than holistic process-level behavior, making them less suitable for ABPS.

We define autonomy levels as follows:

• $\mathrm{■}$

  Level 0: No Automation – Execution and orchestration of all tasks are fully manual.

• $\mathrm{■}$

  Level 1: Process Assistance – The system provides recommendations or highlights anomalies to human workers (e.g., predictive monitoring [18]).

• $\mathrm{■}$

  Level 2: Partial Autonomy – The system independently executes isolated tasks (e.g., call routing, task assignment) within predefined boundaries, but without contextual or adaptive behavior.

• $\mathrm{■}$

  Level 3: Contextual Autonomy – The system autonomously performs most tasks and orchestrates flows in a context-aware manner, requiring human intervention only in exceptional cases.

While most current systems lie at Level 1 or 2, we envision Level 3 as the target state for ABPS. Achieving this level necessitates the development of self-modifying capabilities. Specifically, a Level 3 ABPS must:

1. 1.

   Detect changes in the operating environment (e.g., concept drift detection [8, 14, 25]).

2. 2.

   Decide whether the detected change requires adaptation or evolution.

3. 3.

   Select an appropriate modification strategy based on goals, context, and system history.

4. 4.

   Learn from prior adaptations and generalize successful strategies.

5. 5.

   Communicate its decisions, rationale, and uncertainty to human stakeholders.

In this section, we discuss three challenges related to governance and human oversight, continual learning for adaptation management, and uncertainty quantification and communication.

In this paper, we have laid the conceptual groundwork for understanding and engineering self-modifying capabilities in autonomous business process systems (ABPS). We defined what it means for an ABPS to self-modify, distinguished between the short-term reactivity of adaptation and the long-term reconfiguration of evolution, and introduced a structured framework for levels of business process autonomy. We further mapped these autonomy levels across different objects of modification – task, flow, and process – and connected them to system goals and capabilities.

As ABPS strive toward higher levels of autonomy, we identified three core research challenges that must be addressed to enable safe, intelligent, and human-aware self-modification:

1. 1.

   Establishing robust governance mechanisms and human oversight.

2. 2.

   Managing continuous learning to support sustainable and generalizable adaptations.

3. 3.

   Modeling and communicating uncertainty in ways that foster trust and informed decision-making.

Together, these challenges highlight a critical insight: autonomy is not simply about replacing humans but about redesigning systems that can responsibly decide when to act, when to adapt, and when to defer. The path forward requires integrating techniques from AI planning, machine learning, explainable AI, causal inference, process mining, and human-computer interaction into coherent architectures that balance autonomy with accountability.

We envision ABPS of the future not as black-box automation engines but as collaborative agents capable of engaging with their environments and human counterparts in a transparent, contextual, and goal-aligned manner. To that end, we encourage the community to build benchmarks, share evaluation frameworks, and develop modular toolkits that bring us closer to truly self-modifying, trustworthy, and adaptive business processes.

An ABPMS is conversationally actionable if it can interact with users or external agents using a conversational interface to support, trigger, or guide actions related to business processes. Depending on the user and use case, this conversational interface can support communications using natural language, textual abstractions of process related artifacts, images and graphical models, or specific agent communication protocols.

We identify four principal use cases in a conversationally actionable ABPMS:

1. 1.

   Creation. This use case is concerned with the elicitation of knowledge leading to the creation of business process related artifacts, such as imperative or declarative business process models, constraints, etc. The ABPMS creates the artifacts via several means, including from conversations with domain experts [1], from manually-created process documentation and maps, through discovery from event logs [2], or a combination thereof.

2. 2.

   Query. This use case is concerned with answering questions about the past and current states of business processes and their executions. Besides process monitoring information, e.g., KPI dashboards, constraint violations, and related explanations, queries may also address design time concerns, e.g. process model updates and explanations of process changes. The queries can be issued by users using natural language and other communication means or by agents using some mutually agreed upon protocol. A query can return answers in natural language, as a graphical output (dashboard, annotated process model, etc.) or using a specific agent communication protocol.

3. 3.

   Recommendation. This use case is concerned with generating 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.

4. 4.

   Automation. This use case is concerned with business process execution and evolution, which can be triggered by the user through natural language, automatically by an agent after the creation of a process-related artefact, or as the implementation of a recommendation. 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.

Figure 5 maps the use cases to the phases of the traditional BPM lifecycle.

We envision an architecture for a conversationally actionable ABPMS consisting of four subsystems (see Figure 6): a data layer, an intelligence layer, an action layer, and a conversational fabric.

The data layer brings together structured and unstructured data about a business operation, including event logs of business processes, other business data (financial data, time series), business process documentation (including text documents and process models), as well as data from physical systems relayed via IoT sensors. This layer allows the ABPMS to sense the current state and evolution of the business process and its environment. It provides a querying interface allowing other layers to leverage business process data and metadata from a variety of sources.

On top of the data layer sits a process intelligence layer, which provides capabilities for process discovery and performance analysis (process mining), predictive capabilities (e.g. based on simulation and machine learning), as well as prescriptive capabilities (recommending intervention). In other words, the process intelligence layer provides capability to describe and explain the current state of the process and to predict future states of the process under different scenarios.

Next to the process intelligence layer, the action layer provides capabilities for triggering actions affecting one or more business processes, or interactions with external actors (suppliers, customers, etc.). Example of actions include: (1) creating or altering the state of a case in a business process orchestrated by a Business Process Management System (BPMS); (2) triggering a software bot; (3) sending notifications via a communication platform; (4) updating records in a CRM, ERP or other System of Records.

The fourth component is the conversational fabric. This layer makes available the capabilities of the data layer, process intelligence layer, and action layer to different types of agents. The capabilities of the lower layers are exposed via tools. These tools are exposed to agents via a Model Context Protocol (MCP) [3] layer, which provides semantically rich descriptions of the tools for consumption by agents

An agent may leverage some of these tools to, for example, 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 the process intelligence tools to determine interventions that may be triggered to prevent this SLA violation, and it may then leverage the tools coming from the action layer to trigger actions or notifications.

The agents in the conversational fabric receive instructions and goals from end users, directly via for example a chat interface, or indirectly via agents operating in other systems, such as an agent running in a CRM platform.

Some agents rely on general-purpose LLMs, others are based on fine-tuned or domain-specific models, and some possess explicit planning or reasoning capabilities. Each agent operates autonomously but may collaborate with other agents by passing tasks, sharing context, or requesting specific operations.

Conversations do not only happen when external (human or artificial) agents interact with the ABPMS to obtain information, insights, and explanations about the current state or the history of the ABPM itself. They are also central to enable actionability, that is, to support actions in a broad sense. Actions may pertain to:

• $\mathrm{■}$

  The very execution of the process, e.g., approving a purchase order request, or sending a warehouse replenishment request.

• $\mathrm{■}$

  Process (re)framing, e.g., adding or removing constraints, and (re)modelling, e.g., evolving a model due to changing requirements.

• $\mathrm{■}$

  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, conversating 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 the agent can conversate with other agents, as well as it can invoke the tools needed for the task at hand.

In general terms, 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 sufficient quality control to be trusted.

As shown in Figure 7, to enable agents in using components and interpreting the obtained results, some key aspects must be described:

• $\mathrm{■}$

  Input – an input object (possibly with some preconditions) necessary to invoke the component; for example, the process model required by a simulator.

• $\mathrm{■}$

  Parameter – an auxiliary input used to tune the component; for example, hyperparameters used to configure the simulator.

• $\mathrm{■}$

  Result – an output object produced by the component; for example, the process cycle time produced by the simulator.

• $\mathrm{■}$

  Auxiliary output – an auxiliary output produced by the component to help interpreting the output; for example, quantified uncertainty associated to a prediction.

• $\mathrm{■}$

  Manifest – a description of the component, its behaviour, and its inputs and outputs; the manifest relates to MCP, as its main purpose is to enable agents to discover and properly consume the component.

• $\mathrm{■}$

  Behavioral indicator – a quantitative or qualitative indicator characterising the (functioning of the) component along a key functional or non-functional concern (cf. Section 4.3.4), such whether the component produces analytical or approximate results, or whether it guarantees data privacy, whether it requires a rigid description of the input, and the like; relevant aspects that cannot be clearly described as indicators could still be included in the manifest of the component.

An agent may jointly employ multiple tools through different 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 conversate with other agents. This could lead to an autonomous decision taken by the agent relying on the result of the conversation and of the employed software components, or in an even more complex setting, resulting from collective decision making (akin to multi-agent systems [4]).

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.

In other words, trust propagates from tools to agents if the agents are able to trace their own outputs to outputs obtained from the components. Actionability is in the components, while conversationality is provided by the agents. This trust propagation approach from tools to agents is sketched in Figure 8.

In the context of an ABPMS, tools provide access to descriptions about the current state of the process, diagnosis for issues, predictions, explanations, and recommendations, among others. Other components may provide actions, e.g. executed by rule-based bots, or by bots driven by automated planners, which perform actions on top of systems that have an impact on the “real world” such as transactional systems (which maintain ground-truth of reality) or communication systems (e.g. sending an email).

We have identified a non-exhaustive list of key concerns (mostly non-functional in nature) closely relevant to the conversational actionability of ABPMS (Figure 9 and Table 3). These concerns (except Training and probably Strategy Flexibility and Knowledge Representation) are expected to be specified, tracked, and composed using measurable indicators (e.g., in components), as has been done in other areas such as Service-Oriented Architecture [5].

Stemming from these concerns and the previous discussion, we identify important challenges for the development of conversationally actionable ABPMS. Most are short-term, but the last two are longer-term.

1. 1.

   How are actionable conversations defined and evolved?

2. 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 (e.g., simulators or AI-based agents)?

3. 3.

   How can the concerns identified in Table 3, and especially trust, be understood and increased in an ABPMS?

4. 4.

   How can indicators for these concerns be specified, measured, and aggregated within the ABPMS but also within component contexts (e.g., with MCP)?

5. 5.

   How can unreliable AI-based components and certified tool components be composed dynamically to contribute towards satisfying the goals of an actionable conversation while addressing the identified concerns?

6. 6.

   How can an ABPMS itself become a component (MCP-based or other) that can be used by larger ecosystems?

7. 7.

   (Long-term) How can we support the automated generation of automations (RPA, AI agents, others) from within an APBMS?

8. 8.

   (Long-term) How can frames related to conversations and to interactions with external services/tools be flexibly managed?

An autonomous business process (ABP) is the next generation of AI-Augmented Business Process Management System (ABPMS) [1], which is a self-executing ABPMS that leverages advanced technologies such as Artificial Intelligence (AI) and Machine Learning (ML) to operate with minimal to no human intervention. ABPs can sense and respond to various inputs, reason, make decisions, and adapt to changing circumstances in real time, all without relying on manual triggers or continuous oversight. Think of it like a self-driving car for your business operations. Instead of a human driver controlling all aspects, the system uses sensors, data analysis, and intelligent algorithms to navigate and achieve its objectives.

The notion of ABPs was recently introduced at the AutoBiz Dagstuhl seminar⁶⁶6See https://www.dagstuhl.de/25192. We express our gratitude to the Scientific Directorate and staff of Schloss Dagstuhl for their invaluable support. We also thank our fellow participants for their engaging discussions., during which the core material for this paper was jointly developed.

One reason for realizing ABPs is to improve operational efficiency, reduce errors, lower costs, improve response times, and free human workers for more strategic and creative work. However, despite the promises that ABPs offer, their characteristics can lead to particular concerns in the context of BPM:

• $\mathrm{■}$

  ABPs may erode trust among stakeholders – including process owners, business analysts, end-users, and customers – who may be hesitant to rely on or adopt AI-based process recommendations or automated decisions if they cannot understand the rationale behind them.

• $\mathrm{■}$

  The opacity of ABPs may make it difficult to debug process models, as well as identify potential failures, or understand why a process might be under-performing.

• $\mathrm{■}$

  Using ABPs may hinder accountability; if an ABP leads to a failure or an unfair outcome, the inability to explain its underlying decisions makes it challenging to assign responsibility or implement corrective actions.

• $\mathrm{■}$

  ABPs may perpetuate hidden biases of their underlying AI and ML components. Such biases may lead to discriminatory or unfair process outcomes, which can be difficult to detect and mitigate.

• $\mathrm{■}$

  Demonstrating the compliance of ABPs with regulatory frameworks, such as the EU’s GDPR and AI Act, requires an increasing level of transparency, particularly in high-risk domains like finance, healthcare, and human resources, which are common areas for BPM applications.

We argue that explainability will be a key characteristic of ABP systems to address the aforementioned concerns [1, 2], leading to the notion of eXplainable ABPs (XABPs).

XABPs are particularly relevant when ABPs are realized in the form of Agentic BPM systems. An Agentic BPM system is an advanced approach to managing and automating complex business workflows by integrating autonomous AI agents. Unlike traditional BPM or Robotic Process Automation (RPA) systems that follow rigid, predefined rules and workflows, agentic BPM leverages AI to enable systems to make independent decisions, adapt to changing conditions, and learn from experience with minimal human intervention. Here, explainability offers a central mechanism through which agents can articulate the rationale behind their behavior. As such, explainability becomes a first-class citizen in the realization of Agentic BPM systems, supporting agent autonomy from two perspectives:

• $\mathrm{■}$

  Enabling agents to independently resolve misalignments in other agents’ behavior.

• $\mathrm{■}$

  Reducing human intervention by making agent behavior understandable and transparent.

Employing state-of-the-art explainable AI (XAI) techniques [3] for XABPs pose several limitations:

1. 1.

   Inability to express business process model constraints [4].

2. 2.

   Failure to capture the richness of contextual situations that affect process outcomes [5].

3. 3.

   Inability to reflect causal execution dependencies among activities in the business process [6].

4. 4.

   Explanations are often nonsensical or not interpretable for human users [7].

We start with a generic conceptualization of explainability and then refine this to particular concerns in the BPM setting.

We structure the challenges along the four main explainability concepts as well as along overarching concerns.

An autonomous business process (ABP) represents a paradigm shift towards self-executing workflows driven by AI and ML Yet ABPs introduce challenges related to trust, transparency, accountability, bias, and regulatory compliance within BPM. To address these issues, this paper introduced the notion of explainable ABPs (XABPs), which can articulate the rationale behind their actions and underlying models. Current explainable AI (XAI) techniques fall short in capturing the complexities of the BPM setting. We therefore introduced a set of challenges to stimulate further research on XABPs.