AI Workflow Automation Should Start With Process Discovery

Ask three experienced employees to document the same recurring process and you will often get three different diagrams. Watch them perform it and the gap gets wider: one checks a CRM note that is missing from the procedure, another messages finance when a threshold is close, and the third knows that a green status in one system can be stale for an hour.

That gap is where AI workflow automation fails. The demo follows the happy path written in a slide deck. Production encounters the work people actually do.

The first useful job for AI is often not executing the process. It is helping the company see the process clearly enough to improve and test it. The adoption path should be deliberate: observe, document, recommend, draft, act with approval, then grant limited autonomy.

The Process in the Procedure Is Not the Process in Production

Standard operating procedures describe intended work. Event logs show what systems recorded. Interviews capture what people remember. None provides a complete view by itself.

Real work contains hidden branches:

• An operator checks an unofficial spreadsheet because the system of record updates overnight.
• A support lead treats a refund differently when a fraud marker and a renewal are both present.
• Finance accepts a small mismatch from one vendor but escalates the same amount for another.
• An employee copies data between systems because the integration drops one field.
• A reviewer knows that "complete" means a record, an attachment, and a matching status elsewhere.

These are not edge details. They define whether the workflow succeeds.

The WONDERBREAD benchmark studied 2,928 workflow demonstrations across 598 workflows and six business-process tasks. GPT-4 recalled about 88 percent of demonstrated steps when given the task intent, keyframes, and action trace, yet scored below 0.3 F1 on fine-grained trajectory validation. The authors also noted that documentation can consume 60 percent of a typical process-optimization project.

The tested models were much better at drafting documentation than judging whether a workflow was completed correctly. WONDERBREAD used four WebArena websites rather than confidential enterprise systems, so its scores are not a forecast for any particular company. They do support the order of operations: document the work before asking a model to validate or execute it. Documentation is how the team discovers what needs to be true.

Process mining and task mining provide complementary evidence. Process mining reconstructs flows from system event logs. Task mining observes user interactions across applications. Microsoft's process-mining overview describes using event data to visualize processes and find inefficiencies, while UiPath's task-mining documentation focuses on employee desktop activities and task variants. Interviews and screen recordings add the reasons behind those actions.

Use all four lenses:

A credible process map reconciles these sources instead of picking the neatest one.

Observe 15 to 30 Cases Before Designing the Agent

Begin with one workflow, a named business owner, and a clear start and end. "Automate finance" is not a workflow. "Resolve invoice quantity mismatches after receipt" is.

Select 15 to 30 cases across:

• Two or more strong operators.
• The normal path.
• Common exceptions.
• A high-value or high-risk case.
• A case that bounced between teams.
• A known failure or rework event.
• Different customers, regions, or product lines where rules differ.

Record the work with permission and a defined retention policy. Capture screen actions, system events, inputs, outputs, messages, waiting time, and the operator's explanation at decision points. Mask sensitive values when full content is unnecessary.

Do not ask the operator to narrate every click in real time. That changes how people work and overloads attention. Observe the run, then replay key moments: Why did you open that note? Why was this case different? What would have made you stop? How did you know the task was finished?

Convert each demonstration into a structured record:

Then compare cases. Where did operators diverge? Some differences reflect expertise worth encoding. Some are harmless preferences. Some expose a broken process that should be fixed before any model touches it.

The Process Mining Manifesto distinguishes discovery, conformance checking, and enhancement. That sequence is useful here. Discover the actual flow, compare it with intended policy, then improve it. Automating first only makes the current defects run faster.

Our human rollout playbook explains how to involve operators without turning discovery into a handoff from the business to an isolated AI team.

Turn Tacit Judgment Into Decision Tables and Assertions

A flowchart says what happens next. An automation-ready specification also says why, with which authority, against which data, and how completion is proved.

Take a customer refund. A weak requirement says, "Check eligibility and issue the refund." A usable decision table exposes the real rule:

Build tables around the decisions that changed the observed path. For each branch, capture:

• Required facts and authoritative source.
• Allowed values and data-freshness limit.
• Policy rule and version.
• Actor and permission scope.
• Action, side effects, and reversibility.
• Evidence required for review.
• Expected downstream state.
• Timeout, retry, and escalation behavior.

Completion assertions deserve special attention. Models readily produce plausible "done" messages after a tool call. The system must check the result. A ticket resolution might require a public reply, a disposition code, no open follow-up, and a customer-visible state. An invoice clearance might require matched totals, a posted ERP status, and linked evidence.

Assertions can be deterministic, reviewed, or mixed:

• Deterministic: record exists, values match, status changed, required fields are populated.
• Policy-based: action falls within a current threshold and the actor is authorized.
• Human-reviewed: explanation is appropriate, exception rationale is sufficient, customer communication is acceptable.
• Time-based: no downstream rejection or reopened case within a defined window.

This work often reveals that part of the process should be conventional software. Exact thresholds, permissions, calculations, and state checks belong in code. Use the model for interpreting messy input, drafting, classification, and planning where language flexibility helps.

Use an Autonomy Ladder, Not a Launch Date

Teams often label a workflow "manual" or "automated." That binary hides safer intermediate stages.

Promotion should happen per step, not for the workflow as a whole. An agent may autonomously retrieve records and compare fields, draft an exception note, and require a controller to approve the financial action. That is useful automation without pretending the role has disappeared.

Set gates before the pilot begins:

1. Documentation gate: operators agree that normal paths and frequent exceptions are represented.
2. Recommendation gate: the agent chooses the accepted next step on a held-out case set.
3. Draft gate: reviewers make few material corrections and the evidence is complete.
4. Action gate: permissions, idempotency, validation, verification, and rollback work under test.
5. Autonomy gate: production acceptance, incident, escalation, cost, and drift metrics remain within limits.

Use shadow mode on real work before any write access. Compare the proposed steps with what operators actually did and with the final business state. Add disagreements to the evaluation set. The weekly loop in our edge-case review guide turns those findings into tests and controlled changes.

The counter-intuitive move is to automate documentation and assistance first, even when the stated goal is autonomy. This creates immediate value by reducing training time and search effort, and it produces the process data needed for safer action later.

Decide What to Automate, Fix, or Leave Human-Led

Not every observed step deserves automation. Some are waste. Some exist because two systems do not integrate. Some contain judgment that is cheap and valuable when performed by a person.

Score each candidate step on seven factors. The broader enterprise task-automation matrix applies the same logic when comparing work across teams rather than steps inside one process.

Place the step in one of four lanes:

• Fix the process: remove duplicate entry, repair the integration, or make the source authoritative.
• Automate with code: apply stable calculations, validations, routing rules, and API transfers.
• Use AI with controls: interpret documents, classify cases, draft content, or plan bounded work.
• Keep human-led: retain negotiation, accountability, sensitive judgment, and poorly specified exceptions.

This prevents a common failure: using an agent to imitate an operator's workaround when the right investment is a small integration or policy decision.

Measure the baseline before changing the process. Capture monthly volume, touch time, wait time, rework, error cost, backlog, escalation, and accepted outcomes. After launch, report accepted work, cycle time, review minutes, correction rate, incidents, and full operating cost. Our guide on stability gates before the next workflow provides practical expansion criteria.

Process-discovery tools can accelerate capture and analysis, but they do not own the meaning of the work. The business owner must decide which variation is correct, which evidence proves completion, and which risks require approval. The NIST AI Risk Management Framework reinforces that risk management should be continuous across design, development, deployment, and use. For workflow automation, that means the map and eval set must change when the operation changes.

A 30-Day Process-Discovery Sprint

A focused sprint should produce operating artifacts, not a transformation deck.

Week 1: Scope and baseline. Name the start, end, owner, users, systems, volume, current cost, and accepted outcome. Secure observation consent and data-handling rules. Choose representative operators and cases.

Week 2: Observe and reconstruct. Record cases, collect system events, interview operators after key decisions, and map variants. Separate work time from waiting time. Mark every unofficial source and manual handoff.

Week 3: Specify and challenge. Convert decisions into tables and completion assertions. Walk the map with operators, system owners, security, and compliance. Test known exceptions and identify which steps need process repair, deterministic code, AI assistance, approval, or continued human ownership.

Week 4: Prototype in shadow mode. Let the system document or recommend against new cases without acting. Compare it with operator decisions and downstream results. Deliver the first held-out eval set, risk register, instrumented baseline, and staged automation plan.

The sprint is complete when the team can answer:

• What exact event starts and ends the workflow?
• Which sources are authoritative at each decision?
• Where do capable operators disagree, and who resolves it?
• Which states prove successful completion?
• Which actions are reversible and narrowly permissioned?
• Which exceptions trigger escalation?
• Which business metric must improve before expansion?

If those answers remain vague, the right next step is more discovery or process repair. Autonomy would only conceal the uncertainty inside a model.

How OpenNash Can Help

OpenNash works beside the operators who know the job. We observe representative cases, reconcile procedures with system evidence, map decisions and exceptions, and turn completion criteria into an evaluation set the business owns.

Then we separate the workflow into process fixes, deterministic code, AI-assisted steps, approval gates, and bounded actions. We build the tools, traces, evals, rollback, and review loop needed to move up the autonomy ladder one step at a time. The client keeps the code, process artifacts, tests, and operating knowledge.

A process-mining platform is a strong choice when event logs are mature and the main need is visibility across a standard system. Custom work is a better fit when the process crosses unofficial tools, company-specific rules, and several permission boundaries. If nobody owns the accepted outcome, appoint that owner before buying either.

Book a call to map this to one workflow. Bring three recent cases: a normal one, an exception, and one that required rework.