AI-native workflows

The process map every AI-native redesign starts with

Christopher Kliebenstein · July 9, 2026

The first time we tried to make one of our own workflows AI-native, we already had a process map. It was two years old, drawn for a Six Sigma cleanup, and it was no help. It gave us the sequence of steps and nothing else. It never said which of those steps were judgment calls, where the exceptions actually happened, or who owned the data each handoff depended on. We had mapped the wrong thing, and the pilot went nowhere until we redrew it.

What an AI-native redesign needs from a process map, why an old Six Sigma or value-stream map falls short, and what happens to the pilot when you skip the second map.

Short answer: Before an AI-native redesign, map the process the way employees actually run it today, then add the four things a standard map skips: which steps follow fixed rules, which need judgment, where the exceptions live, and who owns the data behind each handoff. Skipping that second map is why most generative AI pilots stall before they move the P&L.

What does a process map for an AI-native redesign need to capture?

It captures four things a Lean or Six Sigma map never had to: which steps run on fixed rules, which need a judgment call, where the exceptions actually happen, and who owns the data behind each handoff. A model can own a rule. It cannot own a judgment nobody labeled as one, and it cannot pull data that no person is accountable for keeping clean.

What the AI-native map addsWhy the redesign needs it
Rule versus judgment, step by stepTells you which steps an agent can own outright and which stay with a person.
Where the exceptions liveThe exception path is where most pilots break.
Who owns the data behind each handoffAn agent is only as useful as the data it can reach. Unowned data stalls it.
The decision rights at each handoffNames who can approve, override, or escalate once the step runs at machine speed.

Your existing map almost certainly documents the happy path: the clean version where the invoice matches, the customer fits the segment, and nothing gets kicked back. Real work does not run on the happy path. It runs on the exceptions, and the exceptions are exactly what a bolted-on agent hits first and fails on.

Why do most AI pilots stall before they scale?

They stall because AI got wrapped around a workflow nobody redrew. MIT's Project NANDA found that roughly 95% of organizations' generative AI pilots deliver no measurable P&L impact, and only about 5% extract significant value, and BCG found companies that reshape the underlying workflow capture 30 to 50% of the gain against 10 to 20% for bolting AI onto the old process. We covered that split in full in why AI pilots stall before they scale. The map is the specific fix: it is how you find out, before you scale anything, which steps are rules and which are judgment.

Does mapping the process first actually change the outcome?

Yes, and there is now a controlled experiment that isolates it. Researchers from INSEAD and Harvard Business School ran a field experiment across 515 high-growth startups. Firms prompted to map where AI could reorganize their production process discovered 44% more AI use cases, completed 12% more tasks, were 18% more likely to acquire paying customers, and generated about 1.9 times the revenue of equally resourced peers who used AI only to speed up individual tasks. The authors call the failure to do this "the mapping problem."

Read the population honestly: these are startups, not incumbents, so the exact multiples travel best to a business that can still reshape how it works. The direction is the part that generalizes. The teams that stepped back to map the whole process before applying AI out-earned the teams that aimed AI at whatever task was in front of them, holding resources equal. Same tools, same budget, different starting move.

If this is the part you came for, we write about how operators actually rebuild these workflows. Get the next piece.

What does a Six Sigma or value-stream map leave out?

The steps, in the right order, and little of what an agent needs to run them. A value-stream or Six Sigma process map is built to show flow, waste, and cycle time, which is the right tool for taking friction out of a human process. It was never asked to record which steps are rule-based, which are judgment, where decision rights sit, or who is accountable for the data at each handoff.

That extra layer is drawn more by the practitioners building agentic workflows than by any settled standard, so treat it as working practice rather than a finished playbook. The pattern holds up across the operators describing it. Reporting on Celonis makes the same case: you have to understand and operationalize how the process really runs before AI can return anything on it. An old map optimized for human flow gives an agent the sequence and hides the four things it needs to act.

What is the difference between process mapping and process mining?

A process map is what you draw. Process mining is what the system logs actually did. The two disagree more often than teams expect, and the gap is where pilots quietly break. Van der Aalst and colleagues found that even well-documented, structured processes are far more complex and variable in reality than the documented version suggests, and that the real underlying process has to be understood before deciding what to automate.

Mining reads the event logs from the systems the work already runs on and reconstructs the process as it truly executed, exceptions and rework and all. Mapping, done well, adds the human knowledge the logs miss: why a step exists, when a person overrides it, which handoff is really a judgment call. You want both. The mining keeps the map honest, and the map explains what the mining cannot see.

Who should build the map, and who owns it?

A cross-functional team from the departments the process actually crosses, led by people from each function the work touches, with a named owner for the whole thing. Davenport and Redman, writing in Harvard Business Review, are direct about the sequence: any AI-driven process redesign should start by establishing clear process ownership and mapping the workflow as it is actually performed.

The reason is the handoffs. A process that crosses four functions has four different versions of the truth about how it runs, and the exceptions almost always live in the seams between them. A map drawn by one team documents that team's slice and misses the seams, which is precisely where an agent will stall. Someone has to own the whole thing end to end, or no one owns the parts that break.

What does the exec actually fund?

Fund the second map before the model. The decision on the table is small and unglamorous: pay for a cross-functional team to map the real process, label its rules and judgment calls, find its exceptions, and assign data ownership at every handoff, before anyone writes a check for the agent that runs inside it.

Most organizations have not done this. Deloitte's survey of 3,235 business and IT leaders across 24 countries found that only about 30% report redesigning key processes around AI, while roughly 37% are still using AI at a surface level with little or no change to their existing processes. That 37% is the group buying tools and keeping the old workflow. The map is the cheapest line item in an AI budget and the one that decides whether the rest of it returns anything. Fund it first, or fund a faster version of a process nobody drew.

Frequently asked questions

Why do most generative AI pilots fail to scale? Most fail because AI was added to an existing workflow instead of a redesigned one. MIT's Project NANDA found roughly 95% of generative AI pilots deliver no measurable P&L impact. The model performs in the demo, then meets exceptions, handoffs, and data nobody mapped. The stall is a process problem, so a better model does not fix it.

What is the difference between process mapping and process mining? A process map is drawn by people to show how work should run. Process mining reconstructs how it actually ran from system event logs. Van der Aalst's research shows real processes are more complex and variable than their documentation. Use both: mining exposes the real path, mapping adds the human context the logs cannot capture.

What should a process map include before you build an AI agent into a workflow? Every step as employees actually run it, plus four additions: which steps follow fixed rules, which need judgment, where the exceptions occur, and who owns the data behind each handoff. Add the decision rights at each handoff. Those are the details that tell you which steps an agent can own and where a person stays in the loop.

How is process mapping for AI different from Six Sigma or value-stream mapping? A value-stream or Six Sigma map is built to show flow, waste, and cycle time. An AI-native map has to record more: which steps are rule-based versus judgment, where exceptions occur, who owns the data, and the decision rights at each handoff. This is emerging practice among teams building agentic workflows rather than a fixed standard, but the added detail is what an agent needs to act.

What is workflow redesign in the context of AI? Redrawing how work runs so an agent owns its routine, rule-based steps end to end and people keep the judgment, then rebuilding the handoffs around that split. BCG found reshaping the workflow captures 30 to 50% gains against 10 to 20% for bolting AI onto the old process. The map is the input to the redesign; the redesign is where the return comes from.

Before you fund your next AI pilot

Map the real process first. We write about how operators rebuild workflows to be AI-native, the same decisions we make on our own. Join the newsletter to get the next piece when it is out.

Sources

  1. MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (2025), via Fortune. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
  2. McKinsey, "The State of AI in 2025: Agents, Innovation, and Transformation" (2025). https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
  3. BCG, "From Potential to Profit: Closing the AI Impact Gap" (January 2025). https://www.bcg.com/publications/2025/closing-the-ai-impact-gap
  4. Kim, Kim, and Koning, INSEAD and Harvard Business School working paper (2026), field experiment across 515 high-growth startups. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6513481
  5. Davenport and Redman, "How to Marry Process Management and AI," Harvard Business Review (January-February 2025). https://hbr.org/2025/01/how-to-marry-process-management-and-ai
  6. Deloitte, "The State of AI in the Enterprise" (2026 edition, 3,235 leaders across 24 countries). https://www.deloitte.com/global/en/issues/generative-ai/state-of-ai-in-enterprise.html
  7. Van der Aalst et al., "Process Mining and RPA: How To Pick Your Automation Battles" (2021-2022). https://www.researchgate.net/publication/357933625_Process_Mining_and_RPA_How_To_Pick_Your_Automation_Battles
  8. iSixSigma, "Value Stream Map vs Process Map: What's the Difference?" and diginomica reporting on Celonis. https://www.isixsigma.com/business-process-management-bpm/value-stream-map-vs-process-map-whats-the-difference/ and https://diginomica.com/celonis-makes-compelling-case-freeing-process-operationalize-ai-returns

By Christopher Kliebenstein. We build and run AI-native workflows for operators who need them working in production.