What your event logs reveal before you deploy AI agents on your processes
85% of organizations want to become an agentic enterprise within three years, and 76% admit their current processes are holding them back. Both figures come from the same survey, the 2026 Process Optimization Report from Celonis, conducted by independent research firm Insight Avenue across 1,649 leaders at companies with more than $500m in revenue. Two caveats before using it: the vendor sells precisely the remedy its research calls for, and fieldwork ran in June and July 2025 for a February 2026 publication. The same diagnosis exists outside any commercial interest. Wil van der Aalst, professor at RWTH Aachen and one of the founders of the process mining discipline, puts it plainly in an executive briefing published by MIT Technology Review Insights on July 2, 2026: "If you have no idea what is really going on in your processes, it's very naive to think that you can somehow solve your most important problems with AI agents." He was already arguing this in a 2025 academic keynote, under a title an entire industry has since repurposed as a sales line: No AI Without PI.
The conclusion usually drawn is that you should mine your processes before putting an agent on them. That is correct, and it is not enough. An event log describes what your systems recorded, not what your teams did. The approval obtained over email because the official tool is too slow, the correction spreadsheet finance maintains alongside the supplier master, the unofficial shortcut a regional manager uses to keep a customer promise: none of that writes a line into the ERP. Those variants do not show up in the mined model, and they are exactly the ones an agent will break on. A process mining exercise therefore produces a map that is reliable about what it covers and silent about the rest, and that silence reads as a clean process. The risk is not knowing nothing. It is walking away with confidence in the wrong place.
The July 23 article on the agentic risk governance framework dealt with authorization: is this agent allowed to act, and how far. The question that comes before it is different and less comfortable: does this process deserve to be accelerated. What follows is a five-question reading grid for the event log, and more importantly what to do about the gaps that grid leaves open.

Why this became structural in 2026
The market moved before most technical leadership did. On May 12, 2026, Celonis launched its Context Model, positioned as an operational context layer to feed agents, and announced the same day it was acquiring Ikigai Labs to add simulation and forecasting, along with exclusive rights to MIT-owned patents. Integration between that layer and Microsoft Agent 365 has been in private preview since May 1, 2026. In the other direction, Salesforce absorbed mining specialist Apromore into Agentforce. Orchestration vendors are adding analytics, miners are buying execution, and the line between them is disappearing.
Kai Waehner, an independent analyst who discloses his conflicts of interest at the end of his own piece, breaks that convergence into three distinct functions in his July 22, 2026 landscape: mining reads the event logs ERP, CRM and ticketing systems already produce and reconstructs how work really runs; orchestration governs what happens next and enforces the rules; a decision gate checks every automated action against thresholds and constraints before it has consequences. He flags the most common mistake, which is treating process intelligence as one thing. Mining without orchestration sees problems it cannot fix, orchestration without mining automates a process nobody verified, and neither one can tell an agent what it is allowed to do.
His most useful observation is about the step projects skip. Introducing an agent is not the same as embedding AI into an existing process, because a process built for human execution is rarely the right foundation for an autonomous one. Filippo Catalano, Chief Information and Digital Officer at Mondelez International, says the same thing from inside a live deployment, quoted in the Celonis release: trusted agents only hold at scale if they act on the reality of how processes run across every market and system, not on how they were designed in theory.
What the log contains, and what it says nothing about
A properly built event log reveals three things no modeling workshop will ever produce. First, the real variant distribution: how many distinct paths a single process takes, and what share of cases the dominant path covers. Second, the rework loops, those activities that repeat inside a single case and signal a correction, a chase-up or a missing field. Third, the conformance gaps, cases that bypass a documented control without anyone having decided to.
What it does not contain is trickier. Work that happens outside the systems of record leaves no trace, and that is where the workarounds live. Task mining, which observes desktop activity rather than application transactions, exists precisely to cover that blind spot, and the two disciplines are now converging into a single process intelligence category. The practical consequence: a multi-day gap between two recorded activities, with nothing in between, is not idle time. It is work you cannot see.
The log also does not tell you why. It shows that a small handful of people handle most of the atypical cases; it does not show how they decide. That tacit knowledge is what an agent will have to reproduce or escalate, and it is the one part of the file you can only get by talking to the people involved. Kihara Kimachia, in an analysis published on July 29, 2026, sums up the cost of ignoring it: handing a dysfunctional process to an agent does not cure the dysfunction, it scales it at speed.
Five questions to ask the log before the first line of code
Start with variant concentration. Measure the share of cases covered by the three most frequent paths, and write down the threshold below which you consider you do not have a process but a family of processes. The threshold is yours, it depends on sector and criticality; what matters is that it is set before you see the result, not after.
Next, find the rework loops and identify who triggers them. A loop that recurs in 15% of cases and always lands on the same team is a symptom of bad upstream data, not slow execution. An agent placed on top of it will simply run the loop faster.
Look at who handles the exception tail. List by name the people who resolve off-path cases, then spend an hour with each of them. What you learn there appears on no dashboard, and it determines which decisions an agent can make alone.
Hunt the blind segments. Find the transitions where the time gap is large and no activity was recorded, quantify them, and never treat them as residual delay. Every blind segment is a part of the process your agent will cross without instruction.
Finish with conformance. Pull the cases that bypass a documented control, a validation, an approval threshold, a segregation of duties. If an agent inherits that path, you have not automated a process, you have industrialized a control failure.

From the mined model to observing the agent in production
In the field, the teams that got past pilot did not use the mined model to choose which process to automate. They used it to decide which steps had to stay deterministic. Routing, cost thresholds, permissions and transactional validations came out of the agent's scope and stayed as code, while probabilistic reasoning was reserved for the genuinely ambiguous steps. That is the difference between a pilot that finishes and a pilot that stalls.
The mined model then has three successive uses worth separating. It works as a scoping document, drawing the line between what the agent handles and what it escalates. It works as an evaluation set, because real variants observed in the log make better test cases than any hand-written scenario. And it works as a conformance baseline in production, since the trajectories the agent produces are themselves event logs and can be compared against the expected model.
That last point connects directly to the trajectory evaluation described in the July 5 article on harness engineering in practice. An agent in production drifts, not because the model changes but because the process changes around it. Regularly comparing observed trajectories against the model you mined at the start is the only mechanism that catches that drift before an internal control does.
One technical point decides how much room you keep three years out. Object-centric process mining capability is offered today by several vendors on their own internal model, but OCEL 2.0 is the standard that actually makes the data portable between tools. So the procurement question is not whether the product does object-centric process mining. It is whether it exports to OCEL 2.0.
What to start this week
Pick the process where an agent is already on your roadmap and pull its raw event log before anything else. If you cannot pull it, that is already the outcome of the exercise: you do not have the observability needed to scope an agent on that process.
Write down your variant concentration threshold before you look at the numbers, and document the decision. A threshold set after reading the result is not a criterion, it is a justification.
Identify the three to five people who handle exceptions on that process and block an hour with each of them this week. This is the part of the audit that cannot be automated, and the part that most often changes the scope you had planned.
Take the delegation grid from the July 9 article on what 300 tech leaders reveal about their agent roadmap and apply it step by step to the model you just mined, rather than to the process as documented. The two rarely give the same answer.
Conclusion
The 2026 consensus says map your processes before you put an agent on them, and that consensus happens to suit the vendors selling the mapping. It is still correct. What needs adding is less comfortable: the event log is reliable within its scope and silent outside it, and that silence looks like a healthy process. Teams that treat the mined model as a starting point to complete with interviews, a test set and a production conformance baseline get something useful out of it. Teams that treat it as a validation get permission to be wrong faster.
Sources: As of July 2026
- [Primary] Achieving operational excellence with AI β MIT Technology Review Insights (in association with TP) β July 2, 2026 β https://www.technologyreview.com/2026/07/02/1140045/achieving-operational-excellence-with-ai/
- [Primary] No AI Without PI! Object-Centric Process Mining as the Enabler for Generative, Predictive, and Prescriptive Artificial Intelligence β Wil M. P. van der Aalst, RWTH Aachen (INFUS 2025 keynote) β July 31, 2025 β https://arxiv.org/abs/2508.00116
- [Primary] The Enterprise AI Reality Check: High Ambitions Meet Operational Barriers (2026 Process Optimization Report, fieldwork by Insight Avenue, 1,649 interviews) β Celonis β February 4, 2026 β https://www.celonis.com/news/press/the-enterprise-ai-reality-check-high-ambitions-meet-operational-barriers
- [Primary] Celonis Launches the Context Model to Eliminate Enterprise AI's Operational Blind Spots, Agrees to Acquire AI Decision Intelligence Leader Ikigai Labs β Celonis β May 12, 2026 β https://www.celonis.com/news/press/celonis-launches-the-context-model-to-eliminate-enterprise-ais-operational-blind-spots-agrees-to-acquire-ai-decision-intelligence-leader-ikigai-labs
- [Secondary] Process Intelligence Landscape 2026: Mining, Orchestration, and the Agentic AI Shift β Kai Waehner β July 22, 2026 β https://www.kai-waehner.de/blog/2026/07/22/process-intelligence-landscape-2026-mining-orchestration-and-the-agentic-ai-shift/
- [Secondary] Process mining's next job is to stop AI agents automating broken work β Kihara Kimachia, TechFinitive β July 29, 2026 β https://www.techfinitive.com/features/process-minings-next-job-is-to-stop-ai-agents-automating-broken-work/
Comments ()