Agentic Flow Mining: Discovering How Agents Actually Work

For: process-intelligence leads, enterprise architects and observability teams. The decision: how to know whether agents follow the process you think they follow.

Every run looked fine on its own

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Imagine an identity team that has handed routine access requests to an agent. A request arrives, the agent looks up the role catalogue, classifies the risk, asks the manager for approval, provisions the entitlement in the directory and confirms it worked. Over one quarter it handles 40,000 requests.

The dashboards are green. Error rates are low, latency is stable and nearly every run ends with the same status: access granted, approval reference recorded. Pick any single run and you will find an approval step in its history.

Then someone mines the quarter’s events as a process rather than as a pile of traces. Most runs follow the designed path. But 3 per cent of them, 1,200 requests, follow a variant in which the entitlement was provisioned first and the approval arrived afterwards. In 1,164 of those, the manager later approved. In the other 36, the manager rejected a request whose access was already live.

No single trace was wrong. The order was.

Traces and dashboards answer a different question

Distributed tracing tells you which component called which, how long each step took and where an exception was thrown. Whether a sequence of successful steps added up to an acceptable business process is a separate question, and a span tree doesn’t ask it.

Agent evaluation has the opposite gap. It usually scores one run, often by its final output. Here the final output was correct 40,000 times. What was wrong lived in the population: a repeatable path, a few per cent of the time, that broke a rule no per-run check was looking for. An agent chooses its path, so a model release, a new tool or a change in incoming requests can shift which paths it takes without any code being deployed.

Agentic Flow Mining treats agent runs as a process to be discovered and checked

Agentic Flow Mining (AFM) is a discipline proposed in the book: extending process mining and observability to discover, check and improve how agents, tools, humans and policies actually executed. It is the author’s framework, not an established standard.

Its foundation is well established. Process mining, developed most fully by van der Aalst (2016), uses the event logs that operational systems already keep to discover how work really flowed and compare it with a reference model. Object-centric event logs, specified in OCEL 2.0 (Berti et al., 2024), let one event relate to several typed objects at once rather than forcing everything under a single case identifier.

AFM applies that lineage to digital actors that carry authority. Its question shifts from “was the answer good?” to “did the path stay inside what the enterprise permits, on adequate evidence, towards a measurable outcome?” It checks paths against invariants rather than insisting on one correct route. An agent that takes an unusual but valid path is fine. One that commits before its approval is not.

AFM is not alone in this direction. Vu and colleagues, all at SAP (one also at Umeå University), published Agent Behavior Mining in June 2026; the book acknowledges it as the closest published neighbour. They offer an event data model extending the XES standard with agent attributes, a synthetic multi-agent order-to-cash demonstration, and an exploratory study with 18 practitioners. Yang and colleagues (September 2026) write an agenda paper with no experiments, arguing that process mining should support governed action through event-object representations, action evidence packages, governance contracts and benchmarks where acting, deferring, asking and refusing may each be right.

AFM’s added emphasis is that invariants are written around authority and evidence at the Commit Boundary, and that mining checks that design rather than substituting for it. As I read them, neither paper evaluates an authority-aware conformance check across several systems on logs that are incomplete, delayed or out of order. That is a gap in what has been tested, not a criticism of either paper.

Six steps from event data to a fixed process

1. Write the invariants before you mine. State what must hold on every path. For access requests: provisioning of an entitlement for a person must be preceded by a granted approval for that same person, entitlement and request, from someone entitled to approve it.
2. Emit events with business meaning. Name the activity, the actor and version, the policy decision and the objects involved. Record references and digests, not raw payloads or reasoning text.
3. Keep the objects, not just the case. Relate each event to the request, identity, entitlement, approver, agent version and tool. Flattening to a request ID hides patterns that cut across requests.
4. Discover variants, then check them three ways. Structural checks for the fixed segments, declarative checks for the invariants and statistical checks for drift in how often each variant occurs.
5. Check the data before you believe it. Before calling 1,200 runs a breach, rule out clock skew between the approval service and the directory. Here the team confirmed the order from the directory’s own commit sequence.
6. Fix the component, then keep watching. Locate the cause, move the rule onto the enforcement path, turn the invariant into a standing monitor and remediate the affected cases.

In the example, the object-centric view did the diagnostic work. The 1,200 runs clustered on a bulk-provisioning tool introduced mid-quarter, which accepted an approval request reference where it should have required a granted decision. The defect was in a tool contract, not the model. The fix was to make the action gateway verify a granted, matching approval before provisioning, the runtime mediation the design had assumed. The 36 rejected-but-live entitlements were revoked and reviewed.

Mining fails when it replaces enforcement or trusts bad data

• Mining as the control. AFM discovers and evidences. It doesn’t prevent. If a monthly report is all that stands between an agent and an unapproved change, the report is documenting breaches.
• Mistaking variety for defect. Agents are meant to adapt. Flagging every rare path buries the few that break an invariant.
• Poor event quality. Missing events, reused identifiers and clock skew can invent violations or hide real ones.
• Blaming the model by default. The cause is often a tool contract, a retrieval gap or a policy placement.

The open question is whether a mined path can justify a finding

The next research step is not to draw a richer dashboard. It is to ask: Can an object-centric account of agent, tool, approval and system-of-record events distinguish an unauthorised effect from a permitted alternative path when traces are incomplete, delayed or out of order?

Consider why this is hard. The mined log shows an approval event stamped three minutes after the provisioning event. That could mean the order really was reversed. It could mean the approval service’s events reached the log late. It could mean the approval was recorded against a different request. A case-centric conformance check treats all three alike. A check that follows the request, person, entitlement and approver objects, and compares the directory’s own commit sequence with the approval’s identity, may be able to tell them apart or may report that it cannot.

A serious study would compare AFM-style authority and evidence checks with ordinary span inspection, output-only agent evaluation and established process-conformance methods. OpenTelemetry’s generative-AI conventions, still in development, suit the trace baseline; OCEL 2.0 can represent the request, person, entitlement, decision and effect as related objects. Neither proves by itself that an approval covered the exact effect.

It would need independently labelled runs: benign route changes, prohibited tool effects, approvals for the wrong object, stale policy, retries after unknown outcomes, missing events and clock skew. It would report detected prohibited effects, false accusations against legitimate paths, unresolved cases, time to a defensible finding and instrumentation cost. A miner should be allowed to say unknown when the evidence cannot establish the order; counting that as a clean pass would hide the hardest cases.

This is a proposed research programme. No study has been run, and nothing here is a finding about how often agents break their invariants. A negative result, where the new checks add nothing over existing ones, would be just as useful.

Each role has a distinct part in making flows visible

Executives decide which invariants the organisation holds itself to, and that agent review rests on observed flows rather than design diagrams.

Architects design a canonical event vocabulary every runtime emits, the object model behind it, and the path from a finding to the component that owns the fix. They decide what is recorded by reference, so telemetry doesn’t become a data store of its own.

Engineers implement and test invariants as executable conformance rules, event-quality checks and release comparisons that look at variant distributions as well as output scores. The loop measures from Loop Engineering are natural inputs.

Three kinds of conformance, applied to access requests

Key takeaways: the path is the evidence

• A trace can show that every step succeeded while the sequence of steps broke a rule the enterprise depends on.
• Agentic Flow Mining extends established process mining to agents, and checks their paths against invariants rather than against one fixed route.
• Object-centric event data keeps the relationships among requests, identities, entitlements, tools and agent versions that a single case identifier would erase.
• Mining discovers and evidences problems, but the fix belongs on the enforcement path at the Commit Boundary.

Sources and further reading

• The Contextual Agentic Enterprise, Chapter 12.
• van der Aalst, W. M. P., Process Mining: Data Science in Action (Springer, 2nd edn, 2016).
• Berti, A. et al. (2024) “OCEL 2.0 Specification”, arXiv:2403.01975. The standard’s website now serves a later revision, so check the version you use.
• Liß, L., Adams, J. N. and van der Aalst, W. M. P. (2023) “Object-Centric Alignments”, arXiv:2305.05113.
• Vu, H. et al. (2026) “Agent Behavior Mining: Generative AI Agent Governance in Business Processes”, arXiv:2606.20669.
• Yang, Y. et al. (2026) “From Event Logs to Governed Action: A BlueSky Agenda for Agentic Process Mining”, arXiv:2609.07984.
• OpenTelemetry semantic conventions for generative AI, repository read on 15 October 2026; the conventions were marked Development.

The book sets out the full discipline

The book develops AFM in depth: the event model, security-relevant paths that only show up as sequences, and the diagnostic classes that route a finding to the right fix. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.