An agent is dropped into a refund queue. A customer asks for their money back on an order that shipped late. The agent finds the policy page, sees that the amount sits under the direct approval limit, and approves it. It skips the duplicate check the team runs on any refund from an account with more than one open ticket, because nobody wrote that step down anywhere the agent could read. MIT NANDA research on enterprise GenAI, 2025 found that roughly 95 percent of organizations saw no measurable return from their generative AI initiatives. Plenty of reasons sit behind a number that large. The scene above is the one we keep finding in event logs.
Nothing went wrong with the model. The reasoning was sound the whole way through. Two days later the same customer is refunded twice, because the agent was missing the one thing missing from most agent deployments in a real enterprise process: it did not know how the process actually runs.
Why do AI agents fail on enterprise processes?
AI agents fail on enterprise processes because they are given a list of steps and no picture of the process those steps belong to. They do not know which variants are normal, which exceptions are routine, which decisions carry thresholds, or when to stop and escalate.
The failure looks like competence
So they fill every gap with something plausible, and plausible is not the same as correct. This is what makes it expensive. A model that hallucinates a fact is easy to catch. An agent that completes the process correctly most of the time and invents a reasonable-sounding step for the rest looks like it is working, right up to the point where someone audits the exceptions.
The usual reading of that 95 percent of organizations is that the technology is immature. Our reading, from the event logs we spend our days in, is more specific: the pilots that stalled were mostly asked to operate inside business processes that nobody had described accurately, including the people who owned them.
The models are not the problem
The models are good enough. Reasoning, tool use, and instruction following have all improved faster than most enterprise teams can absorb, and a better model will not fix an agent that has been told the wrong thing about how work gets done. Swapping the model changes the quality of the guess. It does not remove the need to guess.
That is an uncomfortable position for a vendor to take, because the alternative sells more easily. But the pattern is consistent. When you mine a process an agent has been struggling in, what turns up is not a reasoning error. It is the part of the process nobody told the agent about.
What the event log says instead
Every organization has a process document. Most of them were written once, by people reconstructing the process from memory, and then edited whenever someone remembered to. The event log tells a different story: more paths, more exceptions, more rework, and a handful of variants that carry most of the cost. See how process mining reconstructs that picture on our process mining software page.
Give an agent the document and it will execute a process that does not exist.
What an agent is actually missing
An agent needs nine kinds of context to act inside a process without inventing the parts it cannot see: objectives, intents, decision rules, allowable variants, exceptions, policies, skills and tools, escalation rules, and success criteria. Remove any one of them and the agent does not stop. It guesses, confidently, in that dimension.
Here is what each one does, and what breaks without it.
The nine dimensions, and the failure mode of each
Objectives. What the process is for. Without it an agent optimizes the metric in front of it. Close the ticket fast, and the customer opens three more next week.
Intents. What this particular case is trying to achieve. A refund request and a complaint about a refund look almost identical in the text and need different handling.
Decision rules. The thresholds and conditions that govern a choice. In one example process we mined, the refund approval limit was €250, and 1,940 observed refunds showed 96.2 percent falling inside the direct approval limit. An agent without that rule either escalates everything or approves everything.
Allowable variants. Which paths through the process are legitimate. That same example process had 7 valid variants. An agent that has only seen the happy path treats the other six as errors, or invents a seventh.
Exceptions. What routinely goes wrong and what the team does about it. Exceptions are not edge cases in a real process. They are a category of work with its own volume.
Policies. The constraints that are not negotiable, including the ones nobody thinks to mention because everyone internalized them years ago.
Skills and tools. What the agent is permitted to use, and what it must hand to a human or another system.
Escalation rules. When to stop. In the same example process, 214 of 12,000 tickets, or 1.8 percent, were P1, with a median first response of 38 minutes. An agent that cannot recognize a P1 will handle it politely and slowly.
Success criteria. What finished actually means, expressed so it can be checked. First contact resolution in that process ran at 62.4 percent, which is the kind of number an agent should be measured against rather than told to maximize.
Those figures come from an example process, mined to demonstrate the structure, and its full Process Context Graph is published further down this page. They are not a customer result, and the point is not the numbers. It is that every one of them was read out of an event log.
Where the nine dimensions come from
They come from the event log your systems already produce. Process mining reconstructs the real process from that log, and mindzie derives the nine dimensions from that reconstruction. Three fields are enough to start: a case ID, an activity, and a timestamp. One graph, nine dimensions, zero interviews.
This is the part that matters, and it is the part most agent-context stories skip. Context derived from an observed log carries the parts of the process nobody would have volunteered, and it can be regenerated when the process drifts.
What a real Process Context Graph looks like
Here is the graph for that same example process: 12,000 tickets and 96,412 events, carrying 27 distinct activity labels of which 24 are modeled as nodes. The export is version 1.0.0 of its Process Context Graph, and the full report is attached at the end of this post.
The shape of it: 8 phases from intake to closure, those 24 activity nodes, 18 decision rules, 7 allowable variants, 6 hard policies, 5 escalation rules, 15 tools mapped to the phases that use them, and 4 agent guardrails compiled from the policies. That is the whole operating picture of a process, in one file an agent can read.
Two things are worth pulling out.
Every threshold carries the evidence it came from. Each escalation rule has an SLA in hours and the observed behavior behind it:
{
"id": "esc:tier-two-unaccepted-8h",
"severity": "high",
"trigger": "Tier-two escalation not accepted within 8 hours",
"from_phase": "phase:escalation",
"route_to": "Specialist team lead",
"sla_hours": 8,
"evidence": "Median acceptance 5.6 hours; 8.7% of escalations (121 tickets) breached the threshold"
}An agent reading that knows when to escalate, who to escalate to, and that the eight hour threshold sits about two and a half hours above the observed median of 5.6 hours.
The policies compile into checks an agent can run on itself. Four guardrails are derived from the policy set and expressed as boolean invariants that must hold after every transition:
{
"id": "guard:no-large-refund-without-approval",
"label": "No refund above 250 EUR without supervisor approval",
"check": "count(tickets WHERE 'Refund Issued' AND refund_amount > 250 WITHOUT 'Supervisor Approval Granted') = 0"
}An agent can run that check on itself after every transition. If the count is not zero, the action is blocked and the ticket goes to a human.
The graph also answers the question the refund agent at the top of this piece got wrong. Its exception list carries a duplicate-ticket entry: the same customer opening a second ticket on the same product within 24 hours of an open one, merged into the parent, observed on 372 of the 12,000 tickets, or 3.1 percent. Nobody had to remember to mention that rule. It was in the log.
The success criteria are equally specific about where this example process falls short. Two of its eight KPIs sit below target: first contact resolution at 62.4 percent against a 65 percent target, and priority-one response inside four hours at 92.8 percent against 95 percent. An agent pointed at a process like this one knows which two numbers it is supposed to move, and that the other six are already where they should be.
Why zero interviews is the differentiating claim
The question worth asking of any process context, ours included, is where the structure came from. Ours is derived from what the systems recorded, which is why it can include a rare variant nobody thinks to mention, or an approval step a team quietly stopped doing.
How the context reaches the agent
The Process Context Graph is exported as a single machine-readable JSON package and exposed through an MCP server, so an agent can read process context at runtime. That is plumbing, and deliberately unremarkable plumbing. The export is a JSON package rather than a plug-in built for one vendor’s assistant.
If your process data cannot leave the building, the full platform runs inside your firewall with the AI models running locally. That is covered on the on-premises process mining page, and the agent-facing detail sits on AI agents.
Who stays in charge
You do. The graph is generated from your data, and then a human reads it before anything acts on it. Review it. Change it. Approve it. Auto generated does not mean auto trusted, and an agent operating on context nobody has checked is the same failure as an agent operating on no context, with better documentation.
The review itself is concrete: the process owner reads the nine dimensions, corrects the ones the log described in a way that is technically true and practically misleading, and signs off. That review is also the first time many process owners see what their process actually does, which tends to generate its own list of work.
Where to start
Start with one process an agent is already struggling in, and mine it before you tune anything else. Reading the nine dimensions of that one process is how you find out what the agent was never told, and which of the nine it was missing when it acted anyway.
To see the shape of the output on your own data, the Desktop Edition runs process mining locally. The longer argument for why context beats model selection is in from AI pilots to real world impact.
The agent in the refund queue did not need a better model. It needed to know that this customer had two open tickets, that the duplicate check exists, and that the team has been doing it for three years without writing it down.
The full graph
The complete Process Context Graph for that example customer service process is published alongside this post: all 8 phases, 18 decision rules, 6 policies, 5 escalation rules, 15 tools, the 7 allowable variants with their observed rates, and the machine-readable JSON at the end of it. Read it before you build against it, which is the point.
Download the Customer Service Process Context Graph
Questions we get about process context
Most of these arrive in the same order. What the failure actually is, what the context is made of, what data it takes to produce, and where it runs. The short answers are below, and each one matches how the nine dimensions are derived from an observed event log rather than gathered in workshops.
Why do AI agents fail on enterprise processes?
Because they are given documented steps rather than the observed process. Missing objectives, decision rules, variants, exceptions, escalation rules and success criteria are filled in with plausible invention, which produces work that looks correct and is not.
Is this a model problem or a data problem?
Neither, exactly. It is a context problem. The model reasons correctly over the information it has. The gap is between the process as documented and the process as actually executed, which no amount of model quality closes.
What is a Process Context Graph?
Nine dimensions of process context, derived from an observed event log and exported as a single machine-readable JSON package: objectives, intents, decision rules, allowable variants, exceptions, policies, skills and tools, escalation rules, and success criteria.
What data do I need to get started?
Three fields from an existing system: case ID, activity, and timestamp. Those three are the minimum a process mining run needs.
Do I have to send process data to the cloud?
No. The full platform can run inside your firewall with the AI models running locally, and the Desktop Edition performs process mining on your own machine.
What format does the process context arrive in?
A single machine-readable JSON package covering all nine dimensions, exposed through an MCP server so an agent can read it at runtime.
