Process context for AI agents

Give your AI agents a grounded understanding of how your business runs

Process context is what an AI agent needs before it touches a real workflow: the steps, hand offs, decision rules, exceptions, time limits and success criteria of the process it works in. mindzie mines that context from your own system data and publishes it as the Process Context Graph, one validated JSON document your agents can load in a single call or query through the mindzie MCP server.

mindzie Process Context Graph built from an event log, giving AI agents, copilots and automations process context such as success criteria, variants, decisions, exceptions, policies and roles

Why process context matters

AI agents without process context guess

Agents and copilots need to know your steps, SLAs, approval paths and exceptions. Without that context they produce plausible answers that break real workflows, and the clean up lands back on your team.

Comparison of a documented process with one clean path and the real process from the event log with rework, a skipped step, an exception and wait times, showing why AI agents need process context

Documentation describes the intended process

SOPs, slide decks and workshop notes describe how work should run. Agents that learn from them miss the variants, rework and delays that happen every day.

Real processes have hidden paths

A process that looks simple in a diagram can run through dozens of variants. An agent needs the main path, the allowed variations and the exception paths before it can act safely.

Rules and time limits live in the data

Which branch a case takes, which steps must come first and which time limits most cases meet are visible in your event log. Process context makes them explicit for the agent.

Static context goes stale

Processes change. When context is rebuilt from fresh data, a new version is published and earlier versions stay unchanged, so you always know which context an agent was given.

The Process Context Graph

One JSON document that describes how a process actually runs

The Process Context Graph is mindzie's machine readable description of a process, built from the project's event log. It covers cases, start and end conditions, steps, hand offs, paths, decision points and the rules that explain them, failures, timing and roles. Every claim carries its own evidence, so an agent knows how much data each statement rests on.

Anatomy of the mindzie Process Context Graph JSON: purpose and success, flow and paths, decisions and rules, exceptions, policies and roles, objects and open questions, with evidence levels on every claim

Evidence on every claim

Each statement records the cases it rests on, its share and a strength label: counted, strong, moderate, weak or hypothesis.

A fixed, versioned schema

Every graph follows the mindzie.process-context-graph schema, version 1.0, published as a JSON Schema file your code can validate against.

Validated before it publishes

A graph that fails validation is never published, and the reason names the failing part. Every part is always present, and no value is null.

It describes, it never decides

The graph recommends nothing and grants no permissions. It tells an agent how the process runs so people stay in charge of what the agent may do.

How mindzie builds it

From raw system data to agent ready context

mindzie derives process context from the observed event log, not from interviews, and analyzes every case rather than a sample.

Four steps from system data to agent ready process context: connect data with Data Designer, discover the process with process mining, compare with a BPMN 2.0 model, publish the Process Context Graph

Connect your data

Data Designer, the ETL layer

Data Designer is the ETL and data transformation layer of the mindzie platform. It connects to your systems and builds the event log the graph is mined from.

  • Prebuilt connectors for SAP, Oracle, Dynamics 365, ServiceNow, NetSuite, Salesforce and Snowflake
  • Any ODBC compliant source, CSV exports and XES event logs
  • Only three fields are required: case ID, activity and timestamp
  • AI assistants help define them, with SQL and Python for full control

Learn about Data Designer →

Discover the real process

Process Mining and Task Mining

Automated process discovery reveals how work really runs across every case, then compares it with the approved process.

  • Every variant, rework loop and bottleneck from the observed event log
  • Conformance checking against a BPMN 2.0 model shows where execution departs from design
  • Task Mining adds the desktop work that never touches a system

Explore Process Mining →

Publish the graph

The Process Context Graph report

Run the Process Context Graph report from the Reports screen, or ask your own agent to start it. The report publishes automatically when the job completes.

  • Built as an AI job inside the project, using the project’s AI credits
  • About 45 minutes for 1.6 million events and about 250,000 cases
  • People review the same content as a report with a process map, decision tables and evidence
  • Each run publishes a new version and earlier versions stay unchanged

What is inside

Everything an agent needs to know before it acts

Each graph is organized into parts. Some are computed directly by code and repeat exactly on the same data. Others are interpretations, such as what a case means or where stages begin, and the report labels which is which.

Purpose and success

What one case represents, what the process is for, the tests for a successful case and every way a case can end, with the share of cases for each.

Flow and paths

Stages and their activities, every step and hand off with median and slow case waits, the main path, allowed variations and exception paths.

Decisions and rules

Each split point with its branches and the if then rules that explain it, plus ordering rules that almost always hold.

Exceptions and escalations

Repeats, skips, out of order steps, rare activities and failed endings, and the steps that appear mainly after long waits or failed attempts.

Policies and roles

The time limits most cases meet, with the share meeting each, and who performs which activity when the log records it.

Objects, assumptions and open questions

Object types and relations for object centric logs, the assumptions behind the analysis and the open questions worth investigating.

Connect your own agent

Load process context into your agent in one call

Your own coding agent, such as Claude Code or Codex, connects to a mindzie project with one line and requests the latest Process Context Graph whenever it starts work on a process.

A coding agent connects to a mindzie project with a project key and fetches the Process Context Graph JSON with the mz command line tool

Set up with one line

Paste one line into Claude Code or Codex and the agent installs the mz tool and connects it to your project. The tool needs only Python 3.9 or newer.

Keys scoped to one project

Each project key opens that one project and nothing else. Keys are entered in a local setup page, never in the chat, and a revoked key is refused within seconds.

Fetch without spending AI credits

Fetching the graph reads the newest published report and uses no AI. Agents are told to ask before starting any job that spends AI credits.

Your agent never touches project files

The outside agent only sends requests and the project responds. Reading published reports is separate from jobs that change the project.

The mindzie MCP server

Let AI agents query process context through MCP

The mindzie Model Context Protocol (MCP) server lets approved AI agents and tools ask mindzie process questions without direct access to every enterprise system. An agent can ask about approval rules, time limits, case status or exception paths and get answers grounded in the Process Context Graph and your process data, not static documentation. Access is scoped per agent, and queries can be logged for review.

Example of an AI agent querying the mindzie MCP server about a stalled invoice and receiving an answer grounded in process context: policies, variants, exceptions, decisions and evidence

1. A case stalls

A supplier invoice in procure to pay has been waiting for approval far longer than usual, and an AI agent is asked to help.

2. The agent asks mindzie

Through the MCP server, the agent asks whether this wait is normal, which time limit applies and whether the case is on an exception path.

3. mindzie answers with context

The answer draws on the Process Context Graph: the time limit most cases meet, the main path, the decision rules at this step and known exception paths, each with its evidence.

4. The agent acts on the real process

The agent routes the case to the right owner with the reason attached, and the query is logged so your team can review what the agent was told.

Your data, your rules

Process context that stays under your control

The same platform and the same features with every deployment model. mindzie is SOC 2 Type II certified, with controls aligned to ISO 27001 and continuously monitored through Drata.

mindzie Cloud Edition, On Premises Edition inside your firewall with local AI models, and Desktop Edition with no cloud upload, SOC 2 Type II certified

Cloud Edition

Fully managed by mindzie

Run process intelligence and the Process Context Graph in the mindzie cloud, with no infrastructure to manage.

On Premises Edition

Inside your firewall

The full platform runs inside your own network, with AI models running locally and your chosen language model.

Desktop Edition

Local process mining

Full process mining on your own machine with no cloud upload. Start with the free Desktop Edition.

Frequently asked questions

What is process context for AI agents?

Process context is a grounded description of how a business process actually runs: its steps, hand offs, decision rules, allowed variants, exceptions, time limits, roles and success criteria. AI agents load it before they work on the process, so their actions follow the real workflow instead of a simplified diagram. mindzie derives it from the observed event log rather than from interviews.

It is a single JSON document, built from a project’s event log, that describes how a process runs. It follows the versioned mindzie.process-context-graph schema, and every claim carries evidence and a strength label.

There are two ways. Agents can query process context through the mindzie MCP server, or your own coding agent, such as Claude Code or Codex, can connect to a mindzie project with a project key and fetch the newest published graph in one call.

Yes. The mindzie MCP server lets approved AI agents and tools request process context, such as approval rules, time limits, case status and exception paths, without direct access to every enterprise system. Each agent’s access is scoped to what it needs, and queries can be logged so AI decisions stay explainable. See how it works with the automated actions engine on the AI agents page.

An event log with at least three fields: case ID, activity and timestamp. Data Designer connects to SAP, Oracle, Dynamics 365, ServiceNow, NetSuite, Salesforce, Snowflake and any ODBC compliant source, or loads CSV exports and XES event logs.

The Process Context Graph report runs as an AI job inside the project. On a log of about 1.6 million events and about 250,000 cases it takes about 45 minutes, so plan for up to an hour at that size. Once published, fetching the graph is immediate and uses no AI.

Every claim records how many cases it rests on and a strength label, from counted to hypothesis. Each graph is validated against the published schema before it publishes, and people can review the same content as a report with a process map, decision tables and the evidence beside each statement.

Yes. The On Premises Edition runs the full platform inside your firewall, with AI models running locally and your chosen language model.

Yes. mindzie is a process intelligence platform with three modules that work together: Process Mining, Task Mining and Business Process Modeling. Together they create the context layer that humans, AI agents and systems need to drive operational excellence.