AI Workflow Discovery: How to Find the Right First Automation
ENGINEERING#Workflow Discovery#AI Automation#Process Mapping

AI Workflow Discovery: How to Find the Right First Automation

2026.10.19
4 MIN READ
Matt Gunnin

The hardest part of AI automation is choosing what to automate. Discovery done well turns a vague ambition into one workflow with an owner, a boundary, and a test.

Ask a leadership team where AI should help and you will get a long list: customer support, sales research, reporting, onboarding, finance operations. Every item is plausible. None of them is ready to build. Workflow discovery is the step that turns that list into one candidate you can scope, test, and own.

It is less about AI than about seeing the work clearly. The model is the easy part to change later; a poorly chosen workflow is not.

01 Map the work as it is actually done

Start by describing the current process the way the team performs it, not the way the procedure document says it should run. Lean practitioners have long used value stream mapping for this: drawing every step in the flow of materials and information, so waste and handoffs become visible. The same discipline applies to knowledge work.

For each step, capture:

  • the trigger: what starts the work, such as an email, a form, or a scheduled report;
  • the inputs: which documents, systems, and people it depends on;
  • the action: what a person actually does, including copying, checking, and deciding;
  • the output: what is produced and who receives it; and
  • the owner: who answers for the result.

Sit with the people who do the work. The most important details, such as the spreadsheet nobody mentions or the check one person always runs, rarely appear in a written process.

02 Collect the exceptions, not just the happy path

A workflow is defined by its exceptions. The duplicate request, the missing field, the client who always sends a different format, the approval that depends on context: these are where automation succeeds or fails.

Ask for one ordinary example and at least one difficult one. Record how each exception is handled today and who decides. If nobody can explain how an exception is resolved, that is a finding in its own right, and usually a reason to fix the process before automating it.

03 Score candidates on value, feasibility, and risk

Once a few workflows are mapped, compare them on the same terms. A simple scoring pass is enough:

  • Frequency and effort. How often does it happen, and how much manual work does each instance take?
  • Data access. Do the inputs live in systems you can reach with the right permissions?
  • Reviewability. Can a person check the output before it has consequences?
  • Consequence of error. Is a mistake recoverable, or does it reach a client, a regulator, or money?
  • Ownership. Is there a named person who wants this improved and will judge the result?

The NIST AI Risk Management Framework starts with mapping context: understanding the setting, the people affected, and the potential impacts before measuring or managing risk. Scoring candidates on consequence and reviewability is a practical form of that step.

Signs of a strong first candidate

  • It recurs weekly or more and follows a describable sequence.
  • Inputs are in systems the team can grant access to.
  • A person already reviews the output before it matters.
  • Mistakes are recoverable and easy to spot.
  • One named owner wants it improved and can judge success.

04 Choose the smallest useful automation

The best first automation is rarely the whole workflow. It is usually one bounded step: preparing a draft, extracting fields into a tracker, detecting duplicates, or flagging the cases a person should look at first. Everything else stays manual until that step has earned trust.

Anthropic's guidance on building agents makes the same recommendation from the technical side: start with the simplest approach that solves the problem, and add autonomy only when it clearly improves the result. A narrow first step is easier to test, easier to explain, and easier to undo.

05 Turn the winner into a testable brief

Discovery ends with a brief that someone can build against and someone else can check. It should state the trigger and finish condition, the accountable owner, the current steps, the proposed automated step, what stays manual, how exceptions and permission boundaries are handled, and a handful of acceptance tests drawn from the real examples.

Our workflow discovery prompt produces a first draft of exactly that brief from a description, an ordinary example, and an exception. It keeps observed facts separate from proposed improvements and labels unknowns rather than inventing them. Pair it with the agent acceptance tests prompt to build the test set.

06 From discovery to a pilot

A good discovery output is the input to a pilot. Our guide to scoping an AI automation pilot picks up from here: proving the riskiest path first, deciding where people stay in the loop, and agreeing how success is measured. If the work is document-heavy and proposal-driven, where AI belongs in an RFP response shows the same method applied to bids.

This is how our AI automation engagements begin: map the real workflow, choose the smallest useful step, and write the brief and tests before building anything.

Choose the workflow carefully and the automation becomes ordinary engineering.

Published: 2026.10.19

Article complete

Keep reading