Agentic Business Process Management Systems

TL;DR

For thirty years, BPM software got better at executing processes people had already designed: BPMN diagrams, workflow engines, business-rules engines, RPA bots. All of it is design-driven — a human decides the flow, the software runs it faithfully, and anything the design didn’t anticipate breaks the system or kicks it back to a human. This position paper (from a keynote at the 2025 Workshop on AI for BPM) argues Generative and Agentic AI enable a genuinely different mode: data-driven, autonomous management, where agents use process-mining insight to sense the live state of a process, decide what to do about it, and act — including redesigning parts of the process themselves, without a human re-coding anything. The authors propose calling this class of platform an Agentic BPM System (A-BPMS) and sketch three things a builder can actually use: (1) a pyramid showing that agentic autonomy has to sit on top of solid process-mining foundations, not replace them; (2) a five-layer reference architecture (data, process intelligence, action, orchestration, conversational); and (3) a triangular “autonomy spectrum” plus a catalog of agent orchestration/execution patterns for placing any given process — or sub-process — somewhere between fully manual, fully rule-based, and fully agentic. There are no experiments, no prototype, and no benchmark here — it’s a 12-page vision paper — but the vocabulary and the architecture are genuinely useful scaffolding for scoping an agentic-automation engagement.

Problem & Motivation

BPM has gone through the same loop for three decades: a new automation technology shows up, it automates more of the process, but it still only does what someone explicitly told it to do.

• Paper and spreadsheets → workflow/case management gave you digital records and task tracking, but a human still executed everything.
• BPMN + workflow engines (classic BPMS) let you design a process model separately from running it — but the model has to anticipate every path. Anything outside the diagram isn’t supported.
• Business rules engines and RPA automated routine decisions and UI-driven tasks — but both are strictly rule-based: “if all possible scenarios can be anticipated and scripted,” in the authors’ words, they work; otherwise they don’t.
• Today’s systems add real-time event processing, APIs, and ML for monitoring — but the decision to act is still either a human or a fixed rule.

The common failure mode: every one of these technologies is design-driven. A person (or a rule author) has to have already imagined the situation for the system to handle it. When reality deviates — an edge case, a new regulation, a shifting bottleneck — the system halts, escalates to a human, or silently mishandles the case. Separately, process mining grew up as a way to look at what actually happened in a process (from event logs) rather than what was designed — but historically process mining has been an analysis discipline sitting outside execution: it produces a dashboard or a report, and a human still has to act on it weeks later.

The gap this paper names: nobody had put “agentic AI that senses via process mining and acts autonomously” into a coherent systems architecture. Practitioners were experimenting with agents around BPM (customer support bots, procurement negotiation agents) without a shared vocabulary for how such agents plug into the data a company already has, or how much autonomy is appropriate for which part of a process.

What’s New (Core Contribution)

This is a position/architecture paper, so the novelty is in the framing and structure, not in an algorithm. Five things worth separating from the rest:

• A formal definition of A-BPMS with three defining properties. Before: “AI-augmented BPMS” was a broad, largely qualitative vision (the same authors’ 2023 research manifesto [6]). Now: an A-BPMS is defined precisely as a system where (1) execution flow is not fully pre-determined by rules/models/scripts, (2) adapting automated components doesn’t require changing the underlying software, and (3) improvement opportunities can be autonomously discovered, validated, and applied. That third clause is the sharpest one — it’s a testable claim about closing the loop, not just executing better.

• The Agentic BPM Pyramid — autonomy sits on top of process-mining maturity, it doesn’t replace it. Before: the process-mining capability pyramid (descriptive → predictive → prescriptive analytics) was a standalone maturity model for tactical and operational decision support [8]. Now: the paper adds Agentic BPM as a fourth layer resting on the first three, and splits it into Automated Systems (rule-based orchestration, still brittle to the unforeseen) vs. Autonomous Systems (AI agents orchestrating without supervision). The honest message here — and it’s a good one — is that an agent with no descriptive/predictive/prescriptive foundation underneath it isn’t actually “agentic,” it’s just guessing.

• A five-layer reference architecture for A-BPMS. Before: no concrete systems architecture existed connecting process-mining infrastructure to agent orchestration. Now: the paper proposes data, process intelligence, action, orchestration, and conversational layers, with the conversational layer explicitly using MCP (Model Context Protocol) to expose the system’s capabilities to other agents, not just human users. This is the first attempt to say concretely where agent orchestration and process-mining tooling should sit relative to each other in one running system.

• A three-way autonomy triangle, replacing the old manual↔automated line. Before: process execution was viewed as a single spectrum from manual to automated [10, 11]. Now: the paper adds a third pole — autonomous/agentic — turning the spectrum into a triangle with independent axes for who executes an activity and who orchestrates the whole process (human, rule-based, or agentic, for each). Almost every real process is a scattered mix of points inside this triangle, not a single vertex.

• A catalog of agentic orchestration and execution patterns, mapped onto BPM. Before: orchestration patterns like sequential, parallel, and supervisor/router topologies exist informally across multi-agent-system practice (LangGraph, AutoGen-style frameworks, etc.) — this part is repackaging, not new. Now: the paper’s contribution is naming seven orchestration patterns (Sequential, Parallel, Routing, Managerial, Adaptive, Mesh, Self-orchestration) and four execution patterns (Triage, Human-Assisted-Agent, Agent-Assisted-Human, Verification) specifically in BPM terms, with BPM-flavored examples (contract creation, procurement, customer support, private banking compliance). Be honest: the patterns themselves aren’t invented here; what’s new is giving BPM practitioners a shared vocabulary for something they’d otherwise have to borrow piecemeal from agent-framework docs.

How It Works (Technically)

There’s no algorithm to trace — the “mechanism” here is architectural. Three structures do the work: the pyramid (what has to exist underneath), the five-layer architecture (how the system is organized), and the triangle + patterns (how you decide who does what). Walk through all three, then trace one case through the full loop.

1. The pyramid: autonomy is only as good as the intelligence beneath it.

flowchart TD
  AB["Agentic BPM<br/>(Automated Systems | Autonomous Systems)"]
  PRES["Prescriptive Process Optimization<br/>— recommend/optimize actions"]
  PRED["Predictive Process Analytics<br/>— digital twins, forecast future states"]
  DESC["Descriptive Process Analytics<br/>— discovery, conformance, performance, variants"]
  DESC --> PRED --> PRES --> AB

Read bottom to top: Descriptive analytics (automated process discovery, conformance checking, performance mining, variant analysis) tells you what’s actually happening, as opposed to what the BPMN diagram says. Predictive analytics — digital process twins and predictive monitoring — uses that history to forecast what will happen next, at the case or process level. Prescriptive optimization turns forecasts into recommended actions, either at the strategic/tactical level (recommend a process redesign) or in near-real-time at the case level (recommend an action for this specific case right now). Only once all three exist does Agentic BPM make sense: agents “sense” using descriptive+predictive analytics, “reason” using prescriptive recommendations, and “act” — the difference between an Automated System (rules define, up front, every decision it’s allowed to make) and an Autonomous System (an agent orchestrates without a human defining every branch in advance) is whether the top-layer decision logic is scripted or agentic.

2. The five-layer architecture.

flowchart TD
  subgraph DL["Data Layer"]
    EL["Process execution event logs"]
    PMR["Process model repositories"]
    HDL["Historical decision logs"]
    DOC["Other process documentation"]
  end

  subgraph PIL["Process Intelligence Layer"]
    D["Descriptive Analytics"]
    P["Predictive Analytics"]
    PR["Prescriptive Optimization"]
  end

  subgraph AL["Action Layer"]
    PES["Process execution systems"]
    BOTS["RPA bots / planners & schedulers"]
    ENT["ERP, CRM, collaboration tools, IoT actuators"]
  end

  ORCH["Orchestration Layer<br/>(agentic + rule-based orchestration)"]
  CONV["Conversational Layer<br/>(LLM agents + MCP tools)"]

  Users --> CONV
  ExternalAgents["External agents"] --> CONV
  CONV <--> ORCH
  DL --> PIL
  PIL --> ORCH
  ORCH --> AL
  AL --> DL

Each layer’s job, in the paper’s own verbs: the data layer lets the system “perceive” (structured + unstructured operational data: event logs, model repos, decision history, docs). The process intelligence layer — the pyramid’s bottom three tiers — lets it “explain,” “predict,” and “improve.” The action layer lets it “enact” — actually change a case’s state, send a notification, trigger an RPA bot, write to a CRM/ERP, or fire an IoT actuator. The orchestration layer is where “reason” happens: it consumes the intelligence layer’s output and decides how to coordinate the action layer, using agentic and/or rule-based orchestration systems. The conversational layer is the interface: LLM-powered conversational agents for human users, and MCP tools for other software agents to call in — i.e., your A-BPMS is itself something an external agent can use as a tool.

3. A concrete trace — one case going all the way around the loop.

The paper doesn’t walk a single case through the architecture end-to-end, so here’s one built directly from its own description of how the layers interact (Sec. 3), to make the abstraction concrete:

flowchart LR
  E["New invoice arrives<br/>(Data Layer: event log entry)"] --> S["Descriptive: conformance check<br/>flags this case as off the happy path"]
  S --> PD["Predictive: digital twin estimates<br/>85% chance of missing payment SLA"]
  PD --> RC["Prescriptive: recommend<br/>fast-track routing"]
  RC --> OD{"Orchestration Layer:<br/>is agentic action authorized<br/>for this activity? (the 'frame')"}
  OD -->|yes: Automated/Autonomous| A1["Action Layer: agent reroutes case,<br/>notifies vendor via collaboration tool"]
  OD -->|no: needs sign-off| A2["Conversational Layer: agent asks<br/>a human approver, waits for decision"]
  A1 --> FB["Outcome recorded"]
  A2 --> FB
  FB --> E

Notice the loop closes back into the data layer — the outcome of this case becomes tomorrow’s training/mining data, which is exactly what “improvement opportunities may be autonomously discovered, validated, and applied” (defining property #3) requires: without that feedback edge, you have a smart executor, not a self-improving system.

The Agentic BPM Pyramid (Fig. 1 in the paper). Click a layer to see what it does and a worked example — notice you cannot skip layers to get to Agentic BPM.

The algorithm, simplified

There’s no algorithm in the paper — the contribution is structural. Here’s the control loop that falls out of Section 3’s layer-by-layer description; it’s the shape you’d actually code if you built a minimal A-BPMS:

# One tick of an A-BPMS control loop, assembled from the paper's layer descriptions (Sec. 3).
# Each named layer contributes one step; the orchestration layer gates autonomy per activity.

def a_bpms_tick(case, data_layer, intelligence, orchestrator, action_layer, conversational):
    # 1. Data layer: "perceive" — ground the loop in real history + the live event
    context = data_layer.fetch(case)                      # event log slice, process model, past decisions

    # 2. Process intelligence layer: "explain" -> "predict" -> "improve"
    state = intelligence.describe(context)                 # descriptive: conformance, performance, variants
    forecast = intelligence.predict(context, state)        # predictive: digital twin / case-level forecast
    recommendation = intelligence.prescribe(state, forecast)  # prescriptive: suggested action + rationale

    # 3. Orchestration layer: "reason" — check the autonomy boundary (the "frame") for this activity
    autonomy = orchestrator.autonomy_level(case, activity=context.next_activity)  # human | rule | agentic
    decision = orchestrator.decide(recommendation, autonomy)

    # 4. Action layer: "enact" — act directly, or hand off through the conversational layer
    if decision.mode == "agentic" and autonomy.allows_unsupervised_action:
        outcome = action_layer.act(decision)                # reroute, call API, trigger RPA bot, notify
    else:
        outcome = conversational.request_approval(decision)  # human-assisted-agent / agent-assisted-human

    # 5. Feedback: every outcome becomes new data — this is what closes the "autonomously improve" loop
    data_layer.record(case, outcome)
    return outcome

The part worth noticing: autonomy_level is doing all the governance work, and the paper never specifies how it should be computed — that’s the single biggest open engineering problem hiding inside this architecture (more on that in “How to Improve It”).

Built on Prior Work

The honest read: almost nothing here is a new mechanism. What’s new is a synthesis — connecting process mining’s maturity model, BPM’s execution spectrum, and agentic-AI’s orchestration folklore into one shared frame, written by people with 20+ years of BPM research credibility, aimed at getting the BPM field to converge on vocabulary before everyone invents their own.

Results & Evidence

There is no empirical evaluation in this paper, and it doesn’t claim to have one — it’s explicitly a position paper based on a keynote talk. The “evidence” offered is entirely illustrative:

• Worked mini-examples per concept: criminal investigations (human orchestration), Tesla welding/assembly robots (rule-based orchestration), autonomous procurement negotiation agents (agentic orchestration), contract-creation pipelines (sequential pattern), private-banking investment recommendations (human-assisted-agent pattern), customer-service triage (triage pattern), and several more — each is a plausible scenario, not something the authors built or measured.
• No prototype A-BPMS exists. No case study of an organization running this architecture. No comparison of orchestration patterns against each other or against classical BPMS on cost, cycle time, error rate, or compliance outcomes.
• Section 5 (“Implications for Research”) is itself an admission of how unfinished this is: the authors flag that BPMN has no constructs for expressing an agent’s planning capability or its “constitutional frame,” that verification-centric process design doesn’t exist yet as a methodology, and that the classical redesign-heuristics catalogue (task elimination, parallelism, etc.) has no agentic extension yet.

What this establishes: a plausible, internally consistent conceptual scaffold, written by credible authors, that names real gaps other people should now go fill. What it does not establish: that the five-layer architecture is buildable at production scale, that MCP-based conversational layers are safe for autonomous enterprise action, that any of the seven orchestration patterns actually outperforms classical BPMN orchestration on any real process, or that “improvement opportunities autonomously discovered, validated, and applied” (their own definition, clause 3) is achievable without a lot of unsolved governance work. Treat this as a shared map of the territory, not a report from someone who’s already walked it.

How You’d Use It

This paper is closer to a scoping framework for your own agent rollout than a technique to implement.

• Use the pyramid as a readiness check before you automate anything with agents. Before you point an agent at a real process — claims handling, invoice processing, whatever — check what’s underneath: clean event logs? A discovered process model? Any conformance checking today? If the descriptive layer is missing, you’re building autonomy on top of nothing. This turns a tempting all-at-once agent project into a phased one: descriptive → predictive → prescriptive → agentic, each phase useful on its own even if you never reach full autonomy.
• Use the autonomy triangle to set your own expectations. Plot where your process actually sits (almost always mostly human-orchestrated, partly rule-automated) and pick a realistic target — “60% agent-executed, still human-orchestrated” is an honest goal; “fully autonomous” usually isn’t yet. Useful for calibrating your own roadmap.
• Use the orchestration/execution pattern names as your own solution-design vocabulary. Routing pattern → a supervisor/triage LangGraph graph for a support desk. Managerial pattern → a master agent decomposing a multi-step proposal or onboarding flow. Verification pattern (human-assisted-agent or agent-assisted-human) → the right shape for anything compliance-sensitive (loan approvals, contract review, clinical documentation) where full autonomy isn’t appropriate yet, but you still want AI in the loop. These map directly onto the role/message-passing designs you’re probably already building in your own multi-agent system.
• Add the conversational + MCP layer to your own stack. Making your process data MCP-addressable is a concrete, scoped project on its own — it’s exactly the conversational layer this paper describes, and it’s the piece most agent stacks don’t have yet regardless of how mature their process mining is.

Build Your Own (Minimal Recipe)

There’s no reference implementation to port — you’re building the scaffold the paper describes, at whatever fidelity you can afford right now.

Components, in build order:

1. Data layer. Point at what already exists: event logs exported to XES/CSV from your process/case-management system, a Git repo of BPMN/process docs, a simple table for decision history. Don’t build new infrastructure here first — inventory what’s already loggable.
2. Process intelligence layer, descriptive first. Use pm4py (open source) for automated discovery, conformance checking, and performance mining. This alone is often the most valuable phase and requires no agents at all.
3. Predictive + prescriptive, only once descriptive is solid. A simple ML classifier or an LLM-with-context predictor for case-level forecasting; hand-rolled heuristics or a small optimizer for the prescriptive recommendation. Resist the urge to skip to agents before this layer produces something an agent could act on.
4. Orchestration layer. Start with one pattern — Routing is the easiest to justify and demo. Build it in LangGraph or your own multi-agent system: a supervisor node reads the prescriptive recommendation, checks an explicit autonomy_level policy (see the pseudocode above), and either dispatches to an action-layer tool or escalates.
5. Action layer. Wrap your real systems as callable tools — ERP/CRM APIs, an RPA library (UiPath, Playwright for web-based systems), a scheduler for planner-driven tasks.
6. Conversational layer. A thin LLM chat frontend for internal users, plus the same tools exposed as an MCP server so other agents (your own future agents, or someone else’s) can call in.

The 1–2 genuinely hard parts:

• The intelligence layer is usually the real bottleneck, not the agent. Most event logs are incomplete, inconsistently timestamped, or scattered across systems that were never designed to be mined. The pyramid’s warning is correct in practice: teams get excited about the orchestration layer and discover, three weeks in, that descriptive analytics alone needs real data-engineering work first.
• Defining autonomy_level (the “frame”) is a governance problem, not a code problem. The paper names this need (the constitutional frame, verification-centric design) but gives no mechanism. You’ll have to build this yourself: per-activity allow-lists, sign-off thresholds, and an audit trail — likely your single highest-value, most defensible piece of work, since it’s what lets you actually turn autonomy on with confidence.

Reach for: pm4py or a commercial process-mining tool (Celonis, UiPath Process Mining) for the intelligence layer, LangGraph or your own multi-agent system for orchestration, and the MCP Python/TypeScript SDK for the conversational/tool-exposure layer.

How to Improve It

The paper flags several of its own gaps in Section 5 — these are the most concrete, testable places to push past it.

1. Specify the “frame” as an enforceable artifact, not a concept. Turn “constitutional frame” into an actual policy object — a per-activity allow-list keyed to the triangle position (human/rule/agentic) — that the orchestration layer checks before acting. This closes the biggest hole in the architecture and is directly buildable.
2. Design the missing process-modeling notation. The paper explicitly says BPMN lacks constructs for an agent’s planning capability or its frame. Prototype a BPMN extension (or a parallel DSL) with objective-based blocks, guardrail annotations, and verification points — a genuinely open, scoped research/product opportunity.
3. Make “autonomously discovered, validated, and applied” (their own definition, clause 3) concrete. Wire variant/deviance analysis (descriptive layer) into an agent that proposes a redesign, but require it to pass through a digital process twin (predictive layer) as a validation gate before auto-applying — the paper never specifies what “validated” means operationally.
4. Test the pyramid’s dependency claim empirically. Run the same “agentic” task with descriptive/predictive/prescriptive layers deliberately degraded or removed, and measure how badly agent decisions suffer. This turns a qualitative architectural claim into a testable one — and would make a strong applied research paper or a compelling demo.
5. Benchmark the orchestration patterns against each other on one real process. Build Sequential vs. Managerial vs. Mesh on the same process (e.g., invoice-to-pay or claims handling) and measure cycle time, cost, and error rate. Right now the paper gives zero evidence for which pattern suits which BPM archetype — first mover here owns a genuinely useful result.

Glossary

• BPM / BPMS — Business Process Management (the discipline) / Business Process Management System (the software that runs BPMN-modeled processes).
• BPMN — Business Process Model and Notation; the standard boxes-and-arrows diagram language for designing processes upfront.
• RPA — Robotic Process Automation; rule-based bots that mimic human clicks/keystrokes across software UIs.
• Process mining — techniques that reconstruct and analyze what a process actually does from event logs, as opposed to what it was designed to do.
• Descriptive / predictive / prescriptive process analytics — respectively: what’s happening now (discovery, conformance, performance, variants), what will happen next (digital twins, predictive monitoring), and what to do about it (optimization, real-time recommendations).
• Digital process twin (DPT) — a data-driven simulation model of a process, built from historical event logs, used to estimate the impact of a hypothetical change before making it.
• Conformance checking — comparing recorded (real) process behavior against a designed process model to spot deviations.
• Agentic AI — software that senses (perceives its environment), decides (reasons about options), and acts (executes) proactively toward a goal, as opposed to generative AI, which reacts to a prompt.
• Orchestrator — the entity (human, rule-based system, or agent) responsible for the overall flow of a process: sequencing, dependencies, and goal achievement.
• Frame — the set of constraints an agent must respect while pursuing a goal (a “constitutional” boundary on autonomous action); the paper names this concept but doesn’t specify how to encode it.
• A-BPMS — Agentic Business Process Management System; a process-aware system where execution flow isn’t fully pre-determined, adaptations don’t require code changes, and improvements can be autonomously discovered, validated, and applied.
• MCP (Model Context Protocol) — a standard for exposing a system’s tools/capabilities to external AI agents with machine-readable descriptions, used here for the conversational layer’s agent-facing interface.
• Autonomy spectrum / process-execution triangle — this paper’s model classifying a process by who executes its activities and who orchestrates it overall: a human, a rule-based system, or an agentic AI, for each.
• Orchestration patterns (Sequential, Parallel, Routing, Managerial, Adaptive, Mesh, Self-orchestration) — named topologies for how multiple agents coordinate a workflow, from a fixed pipeline (Sequential) to fully decentralized peer coordination (Mesh) to agents self-selecting tasks (Self-orchestration).
• Execution patterns (Triage, Human-Assisted-Agent, Agent-Assisted-Human, Verification) — named patterns for how a human and an agent share responsibility for a single activity, from routing work to the right performer (Triage) to one checking the other’s output (Verification).