Process Mining + AI: See Your Real Process Before You Automate

Posted on: 10/19/2026 1:18:22 AM

A distributor wants to put AI agents into its order-handling process. The internal wiki shows a tidy seven-step flow: create order, credit check, approve, pick from warehouse, deliver, invoice, collect payment. But when the data team rebuilds the process from the ERP's logs, they find more than four hundred different "paths" that orders actually take: some skip the credit check, some get their price edited after approval, some loop through "edit – re-approve" five times. Hand the paper process to an agent and it will run faster — on a process that does not exist.

Process mining is the discipline of reconstructing the real process from the traces your systems leave behind: every time an order is created, approved or shipped, your ERP, CRM or application writes a timestamped record. From millions of such records, algorithms draw the process map, measure waiting time between steps, and point out deviations from the norm. In 2026 the field is turning into process intelligence: combined with LLMs for natural-language Q&A, and becoming a source of operational context for AI agents themselves. This article goes from the algorithmic foundations and the OCEL 2.0 data standard to how to plug LLMs and agents into the right places — with runnable Python code using pm4py.

1. What process mining is, and why it matters now

The core idea is simple: almost every business system records who did what, to which object, and when. ERP change-history tables, ticket statuses in a support system, audit logs of internal apps, even OpenTelemetry traces — all of it is raw material. Three fields are enough to get started:

From records like these, process mining solves three problems:

• Discovery: without anyone drawing it first, algorithms build a process model from the log — what the real process looks like, how many variants there are, which paths are highways and which are back roads.
• Conformance checking: compare the log against the normative model the business wants — which cases skipped approval, which ran steps out of order, which breached the SLA.
• Enhancement: overlay time, cost and resource data onto the model to reveal bottlenecks, root causes and predict which cases are about to run late.

Why is this heating up in 2026? Because the AI agent wave has every company wanting to "automate process X", yet very few know how process X actually runs. On 5 May 2026 Gartner officially renamed its Magic Quadrant from "Process Mining Platforms" to "Process Intelligence Platforms" — a signal that the market no longer stops at retrospective analysis, but wants processes to become live context for decisions and for agents.

flowchart LR
  subgraph SRC["Source systems"]
    ERP["ERP
orders, invoices"]
    CRM["CRM / Tickets"]
    APP["App audit logs"]
    OT["OpenTelemetry traces"]
  end
  SRC --> ETL["Extract and normalize
case · activity · timestamp"]
  ETL --> LOG[("Event log
XES or OCEL 2.0")]
  LOG --> D["Discovery
what does it really look like?"]
  LOG --> C["Conformance
where does it deviate?"]
  LOG --> E["Enhancement
where is it slow, and why?"]
  D --> ACT["Action
redesign · automate · AI agent"]
  C --> ACT
  E --> ACT
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class LOG dark
  class D,C,E light
  class ACT hot

2. From event log to process map

The most fundamental technique is the Directly-Follows Graph (DFG): each node is an activity, each edge A → B means "within the same case, B happened right after A", annotated with frequency and waiting time. DFGs are easy to read, fast to compute over tens of millions of events, and usually the first thing that makes managers sit up.

flowchart LR
  S(("Start")) --> A["Create order
10,000 cases"]
  A -->|"9,200 · 2 h"| B["Credit check"]
  A -->|"800 · skipped"| D["Approve order"]
  B -->|"8,900 · 26 h"| D
  B -->|"300 · 4 h"| X["Edit order"]
  D -->|"2,100 · 5 h"| X
  X -->|"2,400 · 31 h"| D
  D -->|"9,700 · 3 h"| W["Pick from warehouse"]
  W -->|"9,600 · 18 h"| G["Deliver"]
  G -->|"9,500 · 1 h"| I["Issue invoice"]
  I -->|"9,100 · 34 days"| P["Collect payment"]
  P --> F(("End"))
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  class X hot
  class A,B,D,W,G,I,P light

Reading the map above, three problems jump out without interviewing anyone:

• Rework loop: the "Approve order ↔ Edit order" pair occurs 2,400 times. Each loop adds about a day and a half of waiting. This is candidate number one for root-cause analysis (wrong price from the start? missing delivery details?).
• Skipped control: 800 orders go straight from "Create order" to "Approve order" without a credit check. That may be legitimate (VIP customers) or a receivables-risk hole.
• Waiting, not working: the credit check takes minutes, but orders wait 26 hours on average before approval. The bottleneck is the queue, not the work — something a total-cycle-time KPI will never show.

DFGs have limits: they cannot tell parallel branches from exclusive choices, and on real logs they turn into "spaghetti" once there are hundreds of variants. That is why discovery algorithms with stricter semantics are used as well, most commonly the Inductive Miner — it produces a process tree or Petri net that is guaranteed to be sound (no deadlocks, always able to finish), with a noise threshold to drop rare paths.

import pandas as pd
import pm4py

# Event log exported from the ERP: one row per event
df = pd.read_csv("order_events.csv")          # order_id, activity, ts, resource
df["ts"] = pd.to_datetime(df["ts"], utc=True)
df = pm4py.format_dataframe(df, case_id="order_id",
                            activity_key="activity",
                            timestamp_key="ts")

# 1) "Who follows whom" map with waiting times
perf_dfg, starts, ends = pm4py.discover_performance_dfg(df)

# 2) How many different paths are there?
variants = pm4py.get_variants(df)
print(len(variants), "variants")

# 3) Keep the 10 most frequent variants, then discover a sound model
top = pm4py.filter_variants_top_k(df, 10)
net, im, fm = pm4py.discover_petri_net_inductive(top, noise_threshold=0.2)
pm4py.save_vis_petri_net(net, im, fm, "o2c_model.png")

3. Conformance checking: where the process deviates

Once you have a normative model (drawn by operations in BPMN, or derived from internal policy), conformance checking answers: does each case comply, and at which step does it deviate? There are four main families of techniques, trading accuracy against computational cost:

# Normative model drawn by operations in BPMN
bpmn = pm4py.read_bpmn("o2c_normative.bpmn")
net, im, fm = pm4py.convert_to_petri_net(bpmn)

fit = pm4py.fitness_alignments(df, net, im, fm)
print(fit["log_fitness"])            # 1.0 means every case fits perfectly

diag = pm4py.conformance_diagnostics_alignments(df, net, im, fm)
deviating = [d for d in diag if d["fitness"] < 1.0]
# d["alignment"] holds (log, model) pairs; ">>" marks a skipped or inserted step

# Timing violations: activity pairs more than 2 standard deviations off
tp = pm4py.discover_temporal_profile(df)
sla = pm4py.conformance_temporal_profile(df, tp, zeta=2.0)

In practice, conformance checking is where process mining pays off fastest for finance and internal control: detecting duplicate payments, purchases without a prior PO ("maverick buying"), price edits after approval, or shipments to customers on credit hold. Unlike sample-based audits, it checks 100% of transactions.

4. The limits of "one case id" and Object-Centric Process Mining

Every technique above assumes each event belongs to exactly one case. The business world does not work that way. An order has many items, items are grouped into different deliveries, and one invoice bundles several deliveries. The "Create order" event involves one order and three items; a "Deliver" event involves one delivery and items from multiple orders.

flowchart LR
  O["Order A1"] ---|"contains"| I1["Item i1"]
  O ---|"contains"| I2["Item i2"]
  O ---|"contains"| I3["Item i3"]
  I1 ---|"shipped in"| D1["Delivery d1"]
  I2 ---|"shipped in"| D1
  I3 ---|"shipped in"| D2["Delivery d2"]
  D1 ---|"billed on"| V["Invoice v1"]
  D2 ---|"billed on"| V
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class O hot
  class I1,I2,I3 light
  class D1,D2,V dark

When you are forced to "flatten" the log onto a single case id, three classic errors appear (described by Wil van der Aalst, the father of process mining, back in 2019):

• Convergence: flatten by item and the "Create order" event is replicated three times, inflating every frequency and cost statistic.
• Divergence: flatten by order and "Deliver" appears twice in the same case, looking like a rework loop when it is really two parallel deliveries.
• Deficiency: events not linked to an order (e.g. "Goods receipt", linked only to items and a warehouse) disappear from the analysis entirely.

Object-Centric Process Mining (OCPM) fixes this by dropping the notion of a case: each event links to many objects of many types. The exchange standard for this approach is OCEL 2.0, published by the RWTH Aachen group, with these key points:

• E2O (event-to-object): every event relates to at least one object, and the relationship can carry a "qualifier" describing the role (e.g. item "added", order "created").
• O2O (object-to-object): two objects can be related directly without sharing an event (e.g. item belongs to order).
• Object attributes change over time: price, status and delivery address keep a history — something OCEL 1.0 could not do.
• Three formats: SQLite (relational), XML and JSON, each with an official validation schema.

ocel = pm4py.read_ocel2("o2c.jsonocel")            # or .xmlocel / .sqlite
print(pm4py.ocel_get_object_types(ocel))          # ['order', 'item', 'delivery', 'invoice']

# Object-centric DFG: each object type gets its own lane, no event duplication
ocdfg = pm4py.discover_ocdfg(ocel)
pm4py.view_ocdfg(ocdfg)

# When you need classic algorithms: deliberately flatten on ONE object type
flat_items = pm4py.ocel_flattening(ocel, "item")

5. When LLMs meet process mining: let the model do the right job

The most natural idea is to hand the event log to an LLM and ask "what is wrong with this process?". It is also the most common mistake. Real logs have millions of rows that do not fit in a context window; and even when they do, LLMs are not reliable at computing numbers themselves — they can invent a very plausible-sounding average waiting time. The right approach is a clear division of labor:

The pm4py library implements exactly this philosophy in its pm4py.llm module: instead of sending the raw log, it provides textual abstraction functions — abstract_dfg, abstract_variants, abstract_ocel_ocdfg, abstract_temporal_profile, abstract_petri_net… — each compressing one view of the log into a length-bounded string (max_len). The module also ships connectors for OpenAI, Google and Anthropic, plus utilities such as nlp_to_log_query (turn a natural-language question into a log query) and automated_hypotheses_formulation.

import os
import pm4py

# Compress the log into context-sized text: pm4py computes the numbers, not the LLM
dfg_text = pm4py.llm.abstract_dfg(df, max_len=8000, include_performance=True)
var_text = pm4py.llm.abstract_variants(df, max_len=4000)

prompt = f"""You are a supply-chain operations expert.
Below is a summary of an order-to-cash process (numbers are precomputed, do NOT recompute them):
{dfg_text}
{var_text}
Task: identify the 3 most suspicious bottlenecks, state a root-cause hypothesis for each,
and for each hypothesis propose one concrete check to run on the event log."""

answer = pm4py.llm.anthropic_query(prompt,
                                   api_key=os.environ["ANTHROPIC_API_KEY"],
                                   model="claude-sonnet-5-5")

On what LLMs can actually do here, PM-LLM-Benchmark (Berti, Kourani, van der Aalst) is the first systematic evaluation: most large LLMs handle process mining tasks at a satisfactory level, but very small models meant for edge devices are still inadequate. The authors also warn that using an LLM as the grader introduces bias — a lesson that applies to every evals setup.

6. Agentic architecture: the Engineer computes, the Analyst interprets

The next step is letting agents drive the analysis. The PMAx paper (March 2026, from the same RWTH Aachen group) proposes a two-agent architecture worth borrowing for any "AI data analyst" system:

• The Engineer agent reads log metadata (columns, activity types, time range), writes scripts that use established process mining algorithms, runs them locally, and produces artifacts: models, tables, charts.
• The Analyst agent receives the artifacts — not the raw data — and interprets them into a report for non-technical users.

sequenceDiagram
  participant U as User
  participant A as Analyst agent
  participant E as Engineer agent
  participant R as Internal  - pm4py
  participant L as Event log
  U->>A: Why are central-region orders shipping late this quarter?
  A->>E: Need waiting times by region, variants and bottlenecks
  E->>R: Generate and run analysis script
  R->>L: Read log, data never leaves the infrastructure
  R-->>E: Tables, DFG, charts
  E-->>A: Artifacts plus metadata, no raw data
  A-->>U: Report with causes, evidence, recommendations

What makes this pattern good: numbers are always right because algorithms compute them; sensitive data never leaves your infrastructure; and scripts generated by the Engineer can be stored for review, re-runs and CI. It is a variant of the "the LLM writes the code, the machine runs the code" principle that every serious analytics system should follow.

Packaging process mining as MCP tools

The most pragmatic way for other operational agents (support agents, procurement agents, warehouse orchestration agents) to use process knowledge is to package it as an MCP server. Celonis has taken this route with its "Agent Tools (MCP) asset" — letting agents query the knowledge model, fetch KPIs and process insights, trigger actions in external systems and write decisions back to the platform; authenticated with OAuth 2.0, with a default limit of 500 calls per minute per asset. On an open-source stack, you can build a minimal version yourself:

import pandas as pd
import pm4py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("process-intel")
LOG = pm4py.format_dataframe(pd.read_parquet("o2c.parquet"), case_id="order_id",
                             activity_key="activity", timestamp_key="ts")
CASE, ACT, TS = "case:concept:name", "concept:name", "time:timestamp"

@mcp.tool()
def top_variants(k: int = 5) -> list[dict]:
    """Return the k most frequent variants of the order-to-cash process with
    their case counts. Read-only, contains no personal data."""
    paths = LOG.sort_values(TS).groupby(CASE)[ACT].agg(" -> ".join)
    vc = paths.value_counts().head(k)
    return [{"path": p, "cases": int(n)} for p, n in vc.items()]

@mcp.tool()
def waiting_time(source: str, target: str) -> dict:
    """Waiting time (hours) when activity `target` directly follows `source`
    within the same order: count, median p50 and p90."""
    d = LOG.sort_values([CASE, TS])
    nxt = d.groupby(CASE)[[ACT, TS]].shift(-1)
    m = (d[ACT] == source) & (nxt[ACT] == target)
    if not m.any():
        return {"count": 0}
    h = (nxt.loc[m, TS] - d.loc[m, TS]).dt.total_seconds() / 3600
    return {"count": int(m.sum()), "p50_h": round(h.median(), 1),
            "p90_h": round(h.quantile(0.9), 1)}

if __name__ == "__main__":
    mcp.run()

Note the docstrings: they state clearly what the tool returns, in what units, and whether it is read-only. Agents choose tools based on exactly these words. Prefer tools with business semantics, such as cases_violating(rule) backed by a predefined rule list, over a "run arbitrary SQL" tool — it is safer and makes agents guess wrong less often.

7. From insight to action: don't automate a broken process

The real value of process mining is not a pretty map but a continuous improvement loop. Combined with agents, that loop can close: agents act on process context, and their actions in turn generate new events to mine.

flowchart TB
  M["Mining
event log into the real process"] --> Q["Diagnose
bottlenecks, violations, causes"]
  Q --> R["Redesign
drop waste, change approval rules"]
  R --> AU["Selective automation
rules · RPA · AI agents"]
  AU --> MON["Operational monitoring
KPIs, delay prediction, alerts"]
  MON --> AG["Agents act
with process context via MCP"]
  AG --> WB["Write decisions back
as new events"]
  WB --> M
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class M,WB dark
  class Q,R,MON light
  class AU,AG hot

Each signal from process mining suggests a different kind of intervention. Not every spot needs an AI agent:

8. A new angle: mining the AI agents themselves

An interesting application is emerging: using process mining to understand agent behavior. A production agent produces thousands of traces a day, each with many model calls, tool calls and retries. Observability dashboards let you inspect traces one at a time; process mining shows you the big picture: which paths the agent actually takes, which loops are most expensive, and whether it follows the originally designed plan.

OpenTelemetry's GenAI semantic conventions (currently in Development status) standardize agent span names such as invoke_agent and execute_tool, with attributes like gen_ai.agent.name and gen_ai.tool.name. That makes turning traces into an event log fairly mechanical:

flowchart LR
  T1["invoke_agent
support_agent"] --> T2["chat
planning"]
  T2 --> T3["execute_tool
search_orders"]
  T3 -->|"62%"| T4["execute_tool
get_invoice"]
  T3 -->|"38% · schema error, retry"| T3
  T4 --> T5["chat
draft reply"]
  T5 -->|"21% · blocked by guardrail"| T2
  T5 -->|"79%"| T6(("Return result"))
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  class T3 hot
  class T1,T2,T4,T5 light

spans = pd.read_json("agent_spans.jsonl", lines=True)
spans = spans[spans["name"].str.startswith(("invoke_agent", "execute_tool", "chat"))]

agent_log = pm4py.format_dataframe(
    spans.rename(columns={"trace_id": "case", "name": "activity", "start_time": "ts"}),
    case_id="case", activity_key="activity", timestamp_key="ts")

# The agent's actual paths versus the designed flow
pm4py.view_dfg(*pm4py.discover_dfg(agent_log))
plan_net, im, fm = pm4py.read_pnml("support_agent_plan.pnml")
print(pm4py.fitness_token_based_replay(agent_log, plan_net, im, fm))

One technical caveat: agent traces have nested and parallel spans, so ordering by start time does not always reflect causality. Pick a consistent abstraction level (e.g. only tool-call and model-call spans), or model it object-centrically with object types such as conversation, agent and tool.

9. Pitfalls in real deployments

• Data extraction is most of the effort. Process mining projects typically spend most of their time figuring out which tables hold which events, joining keys across systems, and cleaning. Don't promise a dashboard in week one.
• Timestamps are the biggest trap. Mixed time zones (server in UTC, users in GMT+7), day-level resolution that scrambles the order of same-day events, or batch jobs stamping a hundred events with the same instant. Normalize to UTC and record the reliability of each source.
• Inconsistent activity names. "Appr. SO", "Approve Order" and "APPROVE_ORDER" are the same step. This is where LLMs genuinely help: proposing a mapping table for humans to review.
• Privacy and people. Event logs have a resource field — i.e. employee names. Per-person performance analysis easily turns into surveillance and destroys trust. Pseudonymize, aggregate by team, be transparent with staff about the purpose, and comply with applicable data protection law (GDPR in the EU; in Vietnam, the Personal Data Protection Law effective 1 January 2026).
• Licensing. pm4py is licensed under AGPL-3.0; if you embed it in a closed-source commercial product, look at the separate commercial license offered by its developers.

10. A 90-day adoption roadmap

Conclusion

AI agents make automation cheaper than ever — and precisely because it is cheap, the risk of automating the wrong thing is bigger than ever. Process mining is the "seeing" layer every automation strategy needs first: it tells you how the real process runs, where it waits, where it reworks and where it deviates, based on 100% of the data instead of gut feeling.

The 2026 picture is fairly clear: process mining algorithms handle deterministic computation, OCEL 2.0 describes the multi-object world correctly, LLMs handle question understanding and interpretation, and MCP turns process knowledge into context that operational agents can query. A small step you can take this week: export the audit log of a process you know well to CSV, run the few lines of pm4py above, and count how many variants your "seven-step" process really has.