Operations AI agent · Process mining
Process Mining AI Agent
Replay what the systems already recorded — the order steps ran in, the queues they sat in, the loops they repeated — as an aggregate model, with individual attribution a separate consulted step.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named sponsor
- Aggregate first
- After launch
- Agent Care
What this agent does
Models the process, not the person
In
- 01
Event logs are read out of ERP, ticketing, CRM and workflow systems, and each row is about a person.
- 02
A trace is built from those rows, and the aggregate model is what the agent publishes by default.
Reason
- 03
A log rich enough to model work is objectively suitable for monitoring it, which is the § 87(1)(6) test.
- 04
An indicator derived per employee, not the raw scanner log, is what CNIL held unlawful in SAN-2023-021.
- 05
A score a manager draws strongly on is itself the decision, and a human deciding later does not cure it.
Decide
- 06
A workflow is planned, and § 90(1) no. 3 attaches there, before any device is introduced at all.
- 07
An emotion inferred from a work pattern crosses Article 5(1)(f), which no configuration makes remediable.
Out
- 08
An event log goes live inside this agent, and Article 26(7) has the employer inform workers first.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Reading, joining and modelling belong to the agent. A named process sponsor releases the model, and any view that names a person waits on that sponsor and on consultation.
Example workflow
One process, log to release
- 1Event log receivedERP, ticketing, CRM or workflow-engine export
- 2Cases assembledThe events, the order they ran in, the waits between them and the systems they came out of
- 3Aggregate model builtThe paths, the waits, the rework loops and confidence
- 4Controls appliedScope checks, cohort-size checks, attribution checks and model confidence
No human action required
Stages 1 to 4 run unaided, and nobody is named at any of them — the agent is modelling, and the sponsor lane opens at the attribution gate.
Goes to the named sponsor to release.
Adds an employment counsel read first.
Sponsor review
The model is held with its scope, its cohort sizes and the logs it was built from.
Release · Narrow scope · Send to employment counsel
Released — by the named sponsor
- 6Process and improvement records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedScope stability, cohort sizes, sponsor corrections and what review found
Corrections
Every sponsor correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Attributing a trace to a named employee.
- Judging whether a person performed well.
- Putting the agent into service unconsulted.
- Ranking teams or individuals against each other.
Automation boundary
Agent acts unaided
- ✓Build the aggregate process model from the logs.
- ✓Report where work waits, loops back and hands over.
- ✓Hold individual attribution behind a separate and recorded request.
- ✓Flag any view that would identify a person and route it to consultation.
Attributable views are released inside the agreed boundaries, never ahead of the sponsor.
- Deciding what the works council is told.
- Using a process model in a disciplinary case.
- Setting who counts as an identifiable actor.
- Changes to attribution, retention or access rules.
Example output
One process model, annotated
This serves an operations team that will answer to a works council: in the Netherlands a decision taken without consent is void if nullity is invoked, and Austria conditions validity on consent.
Process model · single process
Illustrative example- Process
- Purchase to pay, one region
- Recorded as
- Aggregate model, no actor named
- Cohort
- Scope, consulted
- Source of record
- Event logs, 3 August 2026
- Confidence
- Held unreleased
- Held for
- The process sponsor, by name
As received
Built from the event logs those systems already keep, and it reaches no further than those events.
What the record holds
- Event logs
- Consulted scope
- Cohort sizes
Why no name here
Naming an individual is a step the sponsor takes, after consultation.
What the score decides
Below the configured threshold a model picks up a counsel read before the sponsor sees it.
Action
ReleaseNarrow scopeSend to employment counselValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every event log
From the system that recorded it
Where the model is used
A works agreement governs whether this may be deployed, not whether what it produced may later be used: BAG 2 AZR 296/22 holds that the works parties cannot create an exclusionary rule.
The log is about people
Article 5(1)(c) does not reach ordinary productivity analytics: limb (i) wants detriment in a context unrelated to the one the data came out of.
What was checked, and not found
No US federal statute restricts an employer reading its own systems, and notice there is state law: New York, Connecticut and Delaware. Nothing in this landscape is certified, filed or attested, while a DPIA here is mandatory rather than discretionary.
Build an evidence trail
The trace, the consultation record behind it and the sponsor who authorised it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
ERP and finance systems
- SAP
- Oracle
- Dynamics
- Order, invoice and payment events
Ticketing and service desks
- ServiceNow
- Jira
- Zendesk
- Ticket, queue and handover events
CRM and case systems
- Salesforce
- Dynamics 365
- Opportunity and case events
Agent
Process mining
- Reads the logs
- Builds the model
- Holds for the sponsor
Workflow and BPM engines
- Camunda
- Pega
- Appian
- Task, timer and escalation events
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six screens between the log and a named person
Six screens stacked deep, the last the closest. What reaches you is set out in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a view may stand
- L3
- Leaves the release to a named sponsor
- L4 – L5
- Keep the trace and the consultation behind it
- L6
- Stops at the aggregate model when signals degrade
How Nestack evaluates it
Evaluate the whole reconstruction — not only the model that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the model an operations team reads
- E1Final-output evaluationDid the model reflect the events the logs actually hold?
- E2Step-level evaluationDid the agent read the right systems, the right period and the consulted scope?
- E3Tool evaluationDid it read and write the correct process and the correct case?
- E4Confidence calibrationDo low-confidence traces actually attract more sponsor corrections?
- E5Slice evaluationHow does performance change across specific processes?
- E6Business outcomeHow many models needed a correction before the sponsor released?
Floor — the decision the company answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed at the stage the log first shows it.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- MU-03
Partial log read
The log read covers only part of the case.
Stage gathers
The systems, the logs, the cases and the actors
02 · Reasoning
2 modes
- MU-04
Model asserted, not mined
A path appears with no events under it.
- MU-06
Cohort narrows to one actor
A group view resolves to a single person.
Stage proposes
The traces, the model and the attribution risk
03 · Tool / write
2 modes
- MU-02
Attributed view passed forward
A named view moves on without consultation.
- MU-05
Trace bound to wrong case
Events are joined into the wrong case.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- MU-01
Released, consultation unrecorded
The model shows release but not the consultation.
Stage returns
The model a sponsor releases and a board reads
05 · Change / Version
1 mode
- MU-07
Silent scope drift
A model widens to fields nobody consulted on.
Stage tracks
Model, prompt, scope rules and access rules
- Sev-1 · a person named without consultation
- Sev-2 · a wrong path reaches the review
- Sev-3 · log degrades, model held back
Affected slices
Cross-system traces absorb the reviews
A process-level attribution figure can read clean while cross-system case traces carry most of the reviews. Nestack reports the review rate by process, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Cross-system case traces | 9.9% | 3.7× | Review | |
| Manual rework loops | 7.1% | 2.6× | Review | |
| Shared service queues | 4.4% | 1.6× | Watch | |
| Single-system processes | 1.8% | 0.7× | Normal |
Bar: review-rate lift vs. single-system baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What an unconsulted rollout costs
A loop ends when the unconsulted deployment is a standing case. That suite is what the next model published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Review rate rises on cross-system case traces.
- 02
Diagnose
The per-analyst handling-time chart nobody had told the works council about is worked backwards until one cause is left standing.
- 03
Improve
A change goes out numbered, and the traces that forced it travel with it.
- 04
Verify
Each touched trace case is run again, and one red holds it back.
- 05
Learn
It stays as a standing test, and the consultation rules travel with it.
Learn → Detect
The return edge. The next model is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, model assembly, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Attribution-boundary and consultation-scope work.Week 1
- 02ERP, ticketing, CRM and workflow sources.Week 1, Week 2
- 03Event-to-case and actor-identifiability mapping.Week 1, Week 2
- 04Event-log ingestion.Week 2
- 05Case, activity and timestamp binding.Week 2, Week 3
- 06Cohort scoring and review routing.Week 3
- 07Sponsor release workflow.Week 3, Week 4
- 08Process and improvement integration.Week 5
- 09Trace and consultation cases.Week 4, Week 5
- 10Guardrails and disclosure controls.Week 4
- 11Event-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne process, one region | ProductionProduction process workflow | AdvancedMultiple processes / jurisdictions |
|---|---|---|---|
| Introduced at Pilot | |||
| Model assembly from your logs | ✓ | ✓ | ✓ |
| Named sponsor release | ✓ | ✓ | ✓ |
| Event-log baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by process | — | ✓ | ✓ |
| Sponsor review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Event-source integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-system event correlation | — | — | ✓ |
| Cross-process model packs | — | — | ✓ |
| Large event volumes | — | — | ✓ |
| Multi-jurisdiction consultation controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, event volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your processes and the systems that log them
→Scope capture and attribution-boundary definition
Week 102Representative event-log exports
→Log binding, case logic and the model baseline
Week 203Your works council contacts and consultation calendar
→Consultation mapping, scope binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→ERP, ticketing, CRM and workflow source assessment, then integration setup
Week 205Traces you would not want disclosed
→Consultation cases and the evaluation run
Week 406What no process model may establish
→Cohort scoring, review routing, guardrails and release controls
Week 307A named sponsor who releases the model
→Release to the named sponsor, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Read the bands as measurements, not decoration. Two share week five because that is when they overlap.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Process discovery, consultation mapping and the automation boundary
W2Event-source integration and the event-log baseline
W3Model assembly, attribution logic and release controls
W4Evaluation suite, consultation cases and failure-mode testing
W5Improvement-system integration, pilot processes and targeted corrections
W6One discovery round run under the process sponsor, then Agent Care handover
- Reading the band
- Each band runs the weeks its own work is named for, and the fifth carries two because the work does.
- At the end of W6
- Once the consultation record validates, Agent Care picks the agent up.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Operations AI agent
Build a process mining agent around the consultation your last dashboard never had.
Show us one process and the systems its events come out of. Does a works agreement make the monitoring lawful? It does not — C-65/23 leaves a court reviewing necessity in full — and co-determination binds today, while the AI Act high-risk duties wait until 2 December 2027.
- Typical delivery
- 4–6 weeks
- Deployment
- Your event logs
- Named sponsor
- Aggregate first
- After launch
- Agent Care available
Nestack Agents · Process mining
AGT-OP-06 · Agent Care available after launch