Agentic Process Mining

Whitepaper · Crismo Research · October 2026

Executive summary

Agentic process mining uses AI agents for the two jobs that limit process mining today: building the event log, and turning analysis into business impact.

Process mining works. Its bottleneck is everything around the algorithms. Practitioners report spending most of a project's effort preparing data before any analysis starts. When the analysis is done, the step from insight to measurable improvement is where many initiatives stall.

We define agentic process mining through two pillars:

1. Process data and agent telemetry. Agents explore source systems and agent traces, and construct an event and attribute log.
2. Business impact. Agents classify the process domain, engineer the KPIs that matter for that process, and present findings in terms of business impact.

Three developments make this possible now. Language models can read database schemas, documentation and code. Agent frameworks are converging on shared tracing standards, which makes agent work observable. And AI agents increasingly perform process steps themselves, so their traces become part of the process that has to be mined.

This paper defines the concept, describes both pillars and how they connect, and sets out the research agenda Crismo Research will use to test it: one study per pillar.

The problem: two gaps around the algorithms

Process mining has mature algorithms for discovery, conformance checking and performance analysis. The value of a project is limited by two gaps, one before the analysis and one after it.

Gap 1: getting to an event log

Academic process mining usually starts with a given event log. Practical process mining starts with a set of systems and tables, and has to create that log first (Springer, 2022).

That step is expensive. In a survey of 289 practitioners, researchers, vendors and end users by the IEEE Task Force on Process Mining, the most common answer for the share of effort spent on data pre-processing was 61% to 80% (Wynn et al., 2022). The work needs people who understand both the source data model and the business process: which table holds the case, which status change is an activity, which timestamp is the right one.

AI agents add a second data source. When an agent handles a step, its run is recorded as a trace of model calls, tool calls and decisions, not as rows in a transaction table. These traces belong in the same log as the system data, or the process view is incomplete.

Gap 2: getting from analysis to impact

A discovered process model is not a business result. Deloitte's 2025 Global Process Mining Survey names translating insights into measurable outcomes as one of the main obstacles to value (Deloitte, 2025).

Closing this gap takes domain knowledge. An analyst has to recognise what kind of process it is, decide which KPIs matter for it (cycle time for order to cash, first-time-right for claims handling, rework for onboarding), compute them correctly, and express the result in money, risk or customer terms. This is consulting work, and it is the reason process mining has stayed an expert discipline.

Definition

Agentic process mining is process mining in which AI agents perform the expert work before and after the analysis: they construct the event and attribute log from systems and agent traces, and they translate the analysis into domain-specific KPIs and business impact.

Five properties follow from this definition.

• The algorithms stay. Agents do not replace discovery or conformance algorithms. They prepare the input and interpret the output, and they call established algorithms to compute results. Numbers come from computation, not from a language model's guess.
• Agents write code, not data. In pillar 1 an agent writes the small, reviewable piece that connects a source: which fields to read, how to protect them, and how to map them into a common event format. A deterministic pipeline runs that code on every sync, so the log does not depend on a model run.
• Privacy is enforced outside the agent. A fixed intake gate keeps only allow-listed fields, pseudonymises identifiers and rejects malformed records before anything is stored. An agent can propose a field. It cannot make the gate keep a name, an owner or free text.
• Agents are both workers and subjects. Agents build the log, and agents that perform process steps appear in it. The same discipline that analyses human work analyses agent work.
• Humans approve. Agents propose mappings, KPIs and conclusions. A process owner or analyst reviews and approves them before they count as fact.

Pillar 1: process data and agent telemetry

Pillar 1 agents turn raw system data and agent traces into an event log and an attribute log that a process mining engine can use.

The agents do what a data engineer and a process analyst do together today:

1. Explore. Read the API documentation, field schema and pipeline definitions of the source (ERP, CRM, ticketing) and identify which objects and fields describe the process. The agent works from schemas and field types, not from personal records.
2. Map. Decide the case notion, which changes count as activities, which timestamp marks each event, and which fields become attributes (amount, region, customer segment). Personal fields such as names, owners and free text are excluded by type.
3. Write the source module. Generate the field allow-list, the intake rules and the mapping into the common event format, as plain code that runs on every sync.
4. Add agent telemetry. Read agent traces and turn agent runs, tool calls and handoffs into task events on the same cases, each with a start, a completion and the agent as resource.
5. Validate. Run the module against sample data and contract tests, check the log for missing timestamps, impossible orderings, orphan events and duplicate cases, and report what it could not resolve.

The output is a source module and the log it produces. The module's field list doubles as the mapping document: it states in plain language what is read, what each field becomes and why. This is what a human approves. Once approved, the module runs unattended, and the log can be rebuilt from stored data whenever a mapping changes, without calling the source again.

Why agent telemetry is its own problem

Agent traces are becoming structured. OpenTelemetry's semantic conventions for generative AI define standard spans for agent invocation, model calls and tool execution (OpenTelemetry), though they are still in development status.

The hard part is correlation. A trace records a session or a run, not an invoice or a customer case. To mine agent work as part of a business process, the agent has to link each run to the business object it worked on. This is the same case-identification problem as in system data, with less structure to work from.

Pillar 2: business impact

Pillar 2 agents turn a log and its analysis into the answer a business owner needs: what this process costs, where it loses value, and what fixing it is worth.

The agents work in three steps:

1. Classify the domain. Recognise what kind of process the log describes (order to cash, procure to pay, claims handling, customer onboarding) and which variant of it, using the activities, attributes and any existing process model.
2. Engineer the KPIs. Select the KPIs that matter for that domain, define each one precisely against the log (start and end events, filters, units), and compute it with established tools. A KPI definition is a small piece of logic, and it is versioned and reviewable like code.
3. Present the impact. Rank findings by business effect and express them in the owner's terms: hours, euros, error rates, customer wait time. Each finding links back to the cases and events behind it.

The value of this pillar is the domain judgement, not the arithmetic. Computing a cycle time is easy. Knowing that the cycle time which matters in claims handling runs from first notice to payment, not from case creation to closure, is the expertise that makes process mining an expert discipline today.

The figures themselves come from a shared, deterministic KPI library, not from the agent. The agent chooses and defines the KPIs, and the library computes them. Because the same library serves the dashboard, the stored process attributes and the AI assistant, the figures cannot disagree between them. Where a domain has no library entry yet, the agent drafts one, and it is reviewed like any other code change.

The output is a KPI set with definitions, the computed values, and an impact summary. A process owner approves the KPI definitions before the numbers are reported.

How the pillars connect

Pillar 1 produces the log that pillar 2 interprets, and an established process mining engine sits between them doing the computation.

People approve at two points: the mapping decisions behind the log, and the KPI definitions behind the reported numbers. Everything else runs without manual work.

When an approved BPMN model of the process exists, it serves as context for both pillars. Pillar 1 uses it to name activities consistently, and pillar 2 uses it to compare what happens in practice with what was approved.

The loop closes as agents take over process steps. Their runs appear in the agent traces, pillar 1 adds them to the log, and pillar 2 measures their effect alongside the human steps.

Reference implementation

Crismo's process mining prototype already splits the work the way this paper proposes: everything specific to a source sits in one small module, and everything after it is the same for every source.

Data passes through three layers. Bronze holds what one source said, after an intake gate has removed personal fields and replaced identifiers with pseudonyms. Silver holds the same facts in one event format for every source: events linked to objects, attributes over time, and process definitions. Gold holds one row per case and process, with its path and traits such as outcome, moved back, skipped or reopened. Each layer is derived from the one before by a single rule, so silver and gold can be rebuilt from stored data without calling the source.

This split decides where agents belong. Adding a source means writing its module: a field manifest, intake rules and a mapping into silver. That is pillar 1's job. Everything from silver onwards, including the KPI library pillar 2 draws on, is source-neutral and runs without a model. Silver's event format already provides for task events with a start, a completion and a resource, which is the shape agent telemetry needs.

The prototype runs on synthetic data for two CRM systems, with the source modules written by hand. Study A tests whether an agent can write them.

Positioning and related work

The term agentic process mining is already in use, so this paper defines a specific version of it: agents for the work before and after the analysis, with system data and agent traces in one log.

PMAx is the closest work. It uses an engineer agent to run established algorithms on a log and an analyst agent to interpret the results, keeping computation separate from interpretation (Antonov et al., 2026). We share that principle. The difference is scope: PMAx starts after the log exists, and pillar 1 starts before it.

The event-to-action agenda argues that process mining should move from retrospective insight to accountable action, and that agentic BPM, object-centric event standards and LLM-assisted mining are maturing separately (Yang et al., 2026). Agentic process mining as defined here is one concrete combination of those strands.

Enterprise process intelligence platforms already use agents to discover source data, generate data models and compose analyses with predefined KPIs, and some mine agent activity. This confirms the concept works in practice. Their agents speed up deployments led by vendor experts, and results are reported as customer case examples.

This paper differs on three points. The process owner runs it, with approval at two defined points. The accuracy of both pillars is measured in pre-registered studies and published in full. And an approved BPMN model serves as the reference for both pillars, as described in the previous section.

Research agenda

Crismo Research will test each pillar in its own pre-registered study and publish the results whether they support the concept or not.

Study A: agentic event log construction

Question. Can LLM agents, given access to source systems and agent traces, construct an event and attribute log that matches a reference log in case identification, activity mapping, timestamps and attributes?

Design. Crismo's hand-built source modules for two CRM systems serve as the reference. For each source, an agent receives the API documentation and field schema, without seeing the reference module, and writes its own. Both modules run on the same synthetic dataset, and the resulting logs are compared field by field, as are the process models discovered from them. A second part adds agent traces and tests whether the agent links each run to the right business case. Synthetic data keeps the results publishable in full.

Measures. Accuracy of case identification, precision and recall of activity mapping, share of correct timestamps, attribute coverage, and agreement between the two discovered models.

Study B: business impact agents

Question. Can LLM agents, given an event log, identify the process domain and produce KPIs and an impact summary that domain experts rate as correct and useful?

Design. Agents receive logs from known process domains. Experts define a reference KPI set for each domain in advance. In a blind comparison, experts rate the agents' impact summaries against summaries written by human analysts from the same log.

Measures. Accuracy of domain classification, overlap between the agent's KPI set and the expert set, correctness of each KPI definition, and expert ratings of the impact summaries.

Open questions both studies inform

• How much human review is needed before an agent-built log or KPI set can be trusted?
• Where do agents fail, and do they report their own uncertainty correctly?
• What does one log or one impact analysis cost in model usage, compared with expert days?

Only openly licensed data will be used in published results. Datasets are chosen at each study's feasibility step.

Conclusion

Process mining's algorithms are not what holds it back. The expert work around them is: building the log before the analysis, and turning the analysis into impact after it.

Agentic process mining assigns that work to agents, with people approving the results. If the two studies confirm what this paper argues, process mining stops being a project that needs months of data preparation and specialist interpretation. It becomes something a process owner can run on their own systems, including the parts of the process that agents now perform.

We will publish the results of both studies as they arrive, and update this paper with them.

References

• Antonov, A., Kourani, H., Berti, A., Park, G., van der Aalst, W. (2026). PMAx: An Agentic Framework for AI-Driven Process Mining. Preprint, EMMSAD 2026 tool demonstration.
• Celonis (2026). From data to tangible value in hours: Celonis uses agentic AI to accelerate business transformation. Blog post.
• Celonis (2025). Bloomfilter unveils Agent Miner app to observe and govern agents. Press release.
• Deloitte (2025). Global Process Mining Survey 2025: Delivering Value with Process Mining.
• OpenTelemetry. Semantic Conventions for GenAI agent and framework spans. Development status.
• ServiceNow (2026). Drive high-performance production agentic workflows with Process Mining. Session description.
• Process mining best practices for event log creation (2022). Springer.
• Wynn, M. T., Lebherz, J., van der Aalst, W., Accorsi, R., Di Ciccio, C., Jayarathna, L., Verbeek, H. M. W. (2022). Rethinking the Input for Process Mining: Insights from the XES Survey and Workshop. Process Mining Workshops, LNBIP 433.
• Yang, Y., Wu, Z., Chu, Y., Chen, Z., Xu, Z., Wen, Q. (2026). From Event Logs to Governed Action: A BlueSky Agenda for Agentic Process Mining. Preprint.