Workflow Discovery for AI Automation: Map the Process Before You Build the Agent

A regional services firm we worked with had a clean process document for invoice approvals. Two pages, a tidy flowchart, four decision points. When we sat next to the person who actually ran it, the real process had eleven decision points, three undocumented exceptions that came up weekly, and a rule that any invoice from one specific vendor always went to the controller because of a contract dispute from 2024. None of that was written down anywhere. It lived in one person's head.

That gap is where most AI automation projects die. Not in the model, not in the prompt, not in the integration. They die because the team built an agent for the process on paper instead of the process in the building. This is the first piece in our governed AI workflow series, and it starts where every real implementation should start: with discovery, not with the model.

The Map Is Not the Territory

There is an old engineering instinct to jump straight to the solution. A COO says "automate our intake," and within a week someone is demoing an agent that handles the happy path beautifully. The demo wins the meeting. Then it meets production and falls apart on the cases that actually matter.

The reason is simple. Every mature business process has two versions. There is the documented process, which is what the SOP says and what gets shown to auditors. Then there is the enacted process, which is what people actually do, including all the workarounds, side-channels, and judgment calls that accumulated over years of the work being real.

Researchers in the field of process mining have measured this gap directly. When you reconstruct a process from event logs rather than from interviews, the actual process is routinely two to three times more complex than the documented one. Celonis, which built a business on this discovery, describes the core insight bluntly: organizations do not know how their own processes run. The data shows variants the leadership has never seen.

For AI automation this matters more than it does for traditional software. A deterministic script either matches the spec or it does not. An AI agent inherits whatever logic you give it and then improvises in the gaps. If your discovery missed the 2024 vendor dispute, the agent will confidently route that invoice the wrong way and produce a clean audit trail showing it did exactly what you told it to.

The takeaway: discovery is not a documentation exercise you do for compliance. It is the requirements gathering that determines whether the agent works at all.

Shadow the Operator Before You Write a Spec

The single highest-leverage activity in discovery is sitting next to the person who does the work and watching them do it. Not interviewing them in a conference room. Watching the actual screens, the actual clicks, the actual moments where they pause.

When you interview someone about their job, they describe the version they think they should be doing. When you watch them, you see the version that gets the work out the door. The difference is the whole game. A claims processor will tell you "I check the policy number and approve or deny." What you see is that they cross-reference three systems, recognize a fraud pattern by the shape of the claim, and route anything from a specific zip code to a senior reviewer because of a memo from last spring.

Anthropic's guide to building effective agents makes a related point from the engineering side: the most common failure is building agentic complexity where a simple, well-understood workflow would do. You cannot tell which you need until you have watched the work. Shadowing tells you whether the process is genuinely dynamic (needs an agent that decides) or mostly deterministic with a few hard cases (needs a workflow with escalation). We dig into that distinction in agents vs workflows, and discovery is how you actually settle the question for a given process instead of guessing.

Practical structure for a shadowing session:

• Watch first, ask later. Spend the first hour silent. Note every pause, every alt-tab, every "let me just check something."
• Capture the pauses. Where someone hesitates is where judgment lives. That is the most valuable data in the room.
• Ask "what would make you stop?" The conditions that make an experienced operator escalate are the guardrails your agent needs.
• Get the war stories. "Tell me about the worst one you ever had" surfaces the rare-but-catastrophic cases that never make it into an SOP.

A senior operator's instinct for "this one is wrong" is the product of thousands of repetitions. That instinct is the asset you are trying to encode. You cannot encode it if you never see it fire.

Map the Inputs, Outputs, and Handoffs

Once you have watched the work, the discovery output is a structured record of four things: what comes in, what goes out, where the work changes hands, and what triggers each transition. This is unglamorous and it is where the value is.

Inputs. Catalog every input the process consumes and how reliable each one is. An email attachment that is sometimes a PDF and sometimes a photo of a printout is a different automation problem than a structured API payload. Garbage-in tolerance is a design decision you can only make once you know how much garbage actually comes in.

Outputs. Define what "done" means and who consumes the result. A drafted reply that a human sends is a very different risk profile than a payment that posts automatically. The output's blast radius sets the governance bar.

Handoffs. Every point where work passes between people, systems, or teams is a point of failure and a point of measurement. Handoffs are where delay accumulates and where context gets lost. They are also the natural seams where you can insert an agent without rebuilding the whole process. A study of operational processes consistently shows that wait time at handoffs, not work time, dominates total cycle time. Automating a handoff is often higher ROI than automating the work itself.

A simple table format works well as the discovery artifact:

The discipline here is that if you cannot fill in every cell, you have found a gap in your understanding, not a gap in the process. The process handles it somehow. You just have not learned how yet.

Find Where Judgment Actually Lives

This is the section that separates discovery done well from discovery done as theater. For most business processes, 80 to 85 percent of the volume follows a predictable path. The remaining 15 to 20 percent is where the experienced human earns their salary. Your job in discovery is to find that boundary precisely and write down what happens on the far side of it.

We call the output an exception map. For each exception, you capture the trigger that surfaces it, the judgment the human applies, the information they pull in to make the call, and the action they take. This map is the most important deliverable of the entire discovery phase, because it defines exactly where the agent should hand control back to a person.

McKinsey's research on agentic AI in the enterprise lands on the same point from the strategy side: the value of agents shows up when companies redesign the workflow around human-agent collaboration, not when they drop an agent onto an unexamined process. The redesign requires knowing which decisions stay human. PwC's 2026 AI predictions frame this as the shift from AI pilots to governed deployment, where the constraint is no longer model capability but organizational readiness to define oversight.

There is a counter-intuitive insight buried here. The processes that look most automatable on the surface (high volume, repetitive) are often the ones with the most concentrated judgment in the exceptions. A loan adjudicator approves 90 percent of applications in seconds. The 10 percent they decline or escalate is the entire reason the role exists, and it is precisely where automating naively does the most damage. The volume is not the prize. The judgment in the tail is the thing you must respect.

A clean exception map also tells you when to walk away. If discovery reveals that a process is mostly judgment with a thin automatable shell, the honest answer is to not build an agent for it yet. We make that argument in detail in when not to build an agent, and discovery is what gives you the evidence to say it out loud to a stakeholder who already wants the demo.

Turn Discovery Into a Governed Build

Discovery is not finished when you understand the process. It is finished when you have converted that understanding into the controls that make automation safe to ship. For a midmarket operator or a PE operating partner, this is the difference between a durable margin improvement and a fragile demo that breaks the month after the consultant leaves.

Gartner's work on AI governance frames the requirement directly: ungoverned AI is the leading reason enterprise deployments stall after the pilot. Governance is not a brake on automation. It is the thing that lets you scale it without taking on risk you cannot see.

From the discovery artifacts, you derive four governance components:

• Decision ownership. Every automated decision needs a named human owner who is accountable for outcomes. The exception map tells you who that is for each branch.
• Approval paths. The output blast radius from your input-output map sets the bar. Low-risk outputs run autonomously. High-risk outputs route through a human approval step before they take effect.
• Audit trails. Every agent decision logs its inputs, its reasoning, and its action. For a PE-backed company facing eventual diligence, this is not optional. Third Bridge's work on AI in private equity diligence shows that buyers now probe how automated decisions are governed, not just whether automation exists.
• Uncertainty fallback. The conditions you captured in shadowing ("what would make you stop?") become the agent's escalation triggers. When confidence is low or an exception pattern matches, the agent hands off to the human owner.

This is where orchestration platforms enter the picture, not before. Tools like UiPath's agentic automation, Appian, and the open-source LangGraph framework for workflows and agents all give you ways to wire human approval steps and audit logging into the execution path. But the tool is downstream. It implements the governance your discovery defined. Picking the platform first is how teams end up with a powerful orchestrator running an unexamined process at scale, which is the worst of both worlds.

The handoff from discovery to a production system is its own discipline, and the controls you define here are what carry the build through that transition. We cover that path in prototype to production, and the operating model that keeps it healthy afterward in the operating model after launch.

How OpenNash Can Help

Discovery is the part of AI automation that does not demo well and matters most, which is exactly why it gets skipped. OpenNash starts every engagement here. We shadow your operators, build the process record and exception map, and define the governance - ownership, approvals, audit trails, and fallbacks - before we scope a single agent.

The build that follows targets the real process, with the human judgment preserved where it belongs and the deterministic work automated where it is safe. You own the result: the process documentation, the workflow definitions, and the running system, with full handoff and CI/CD integration.

If you are a COO, VP of Operations, CFO, or PE operating partner weighing automation, the right first move is not a tool selection. It is a map. Book a call to map one of your workflows and see where the judgment actually lives before anyone builds anything.

The firm with the invoice process eventually got their automation. It works because we found the 2024 vendor dispute in week one, wrote it into the exception map, and built the agent to escalate that vendor every time. Nobody had to remember it anymore. The knowledge moved from one person's head into a governed system that the whole team can see, and that is the entire point.