How to Map One Workflow Before You Add an AI Agent

> RAI Systems Guide: This factory-produced, graphics-first guide is a separate Richardson Applied AI content category. It is not an episode of Holden Richardson's manually filmed and edited Agentic AI, Practically course.

To map a workflow before adding an AI agent, follow one real case from the event that starts it to the evidence that proves it is finished. Record the trigger, authoritative inputs, actual steps, decisions, exceptions, handoffs, accountable owner, output, and observed cost. Only then choose one bounded part for the agent to perform.

The map does not need to be beautiful. It needs to be true. A whiteboard, a shared document, or a sheet of paper can expose more useful operating detail than a polished automation diagram built from assumptions.

The most common planning mistake is drawing the workflow the way it should work. That skips the copy-and-paste steps, the quiet judgment calls, the waiting, the missing information, and the person who rescues every unusual case. Those are exactly the details an AI agent will encounter.

Start with one current workflow, not an AI use case

Name the work in operational terms: “prepare the weekly production exception report,” “assemble a supplier quote packet,” or “turn an approved service request into a scheduled job.” Avoid broad labels such as “use AI in operations” or “build a sales agent.”

Set one observable start and one observable finish. If the start is “a request arrives,” identify where it arrives and what counts as a request. If the finish is “the report is complete,” name the file, database state, delivery, or read-back that proves completion.

This current-state-first approach is consistent with the U.S. EPA's value-stream mapping guidance, which begins by walking the existing flow from beginning to end before designing and implementing a future state. A simple office workflow is not automatically a full value-stream map, but the discipline transfers: observe the work before redesigning it.

If the process boundary is still hard to name, use the more detailed guide to picking a first AI project before you continue.

Put these 10 fields on the map

Use one row or card for each step and capture the fields below. Do not hide information just because it makes the diagram less tidy.

NIST's AI Risk Management Framework Map playbook asks organizations to document an AI system's intended purpose, context, users, impacts, assumptions, limitations, and operating requirements. It also emphasizes clear human roles and the capabilities that require human oversight. Your workflow map is smaller than an AI risk program, but it should give an implementation team enough context to answer those questions for this particular job.

Draw reality in five simple symbols

You do not need specialized notation for a first map. Five symbols are enough:

• Start or finish: a rounded box for the trigger and verified end state.
• Task: a box for an action performed by a person or system.
• Decision: a diamond for a question with named branches.
• Handoff: an arrow that crosses a person, team, system, or medium.
• Exception: a side path showing what happens when the normal case breaks.

If the workflow later becomes complex, the Object Management Group's Business Process Model and Notation provides a standard graphical language designed to be understandable to business users and precise enough for technical implementation. Do not make formal notation the price of starting. Consistent plain language is more valuable than incorrect formalism.

Build the map with the people who perform the work. Ask them to narrate a recent normal case and a recent difficult case while the relevant systems or artifacts are open. “What happens next?” reveals the visible sequence. “How do you know?” reveals source authority and judgment. “What happens when that is missing?” reveals the real exception path.

Record waiting, checking, and rework as steps

Many maps include only productive-looking actions. That erases much of the current cost.

Record when someone waits for information, checks another person's work, re-enters the same data, searches across systems, corrects a prior output, or follows up because the handoff was not acknowledged. These steps may be candidates for better information flow, clearer ownership, or a different process—not necessarily for an AI agent.

Digital.gov's mapping guidance recommends treating a map as a living document and adding measures such as time or money spent at and between steps. That distinction matters. Ten minutes of active work followed by two days of waiting is not a two-day labor expense, but it may be a serious throughput problem.

For each representative case, record:

• active minutes by person or role;
• elapsed time from trigger to verified finish;
• waiting time at each handoff;
• number and type of corrections;
• direct software, service, or transaction fees; and
• whether the case was normal, exceptional, or incomplete.

Observe several cases when the process varies. Use a range rather than forcing a misleading average.

Calculate the current cost before predicting savings

Use the measured current state to create a baseline:

monthly current cost = monthly cases × (active minutes per case ÷ 60) × loaded hourly rate + direct fees + expected rework cost

If case types differ, calculate them separately. A standard request and an exception may have entirely different labor and review patterns. Keep elapsed time beside the cost calculation rather than folding all waiting into paid labor.

The point is not to produce a perfect finance model. It is to prevent a tool demo from becoming an unsupported ROI claim. After a pilot, compare the new workflow with the same measures and include the maintenance, human review, failure recovery, and provider costs required to keep it working.

GAO's AI Accountability Framework organizes its practices around governance, data, performance, and monitoring. Its audience includes federal agencies and other entities, so it is not a private-company compliance checklist. The practical lesson still travels: define the goal, identify the responsible people and inputs, decide what performance means, and monitor the result.

Map the exception path before the happy path is automated

The normal case is usually the easiest part to demonstrate and the least informative part to design around.

For every decision, ask what happens when the expected answer is unavailable. Useful exception categories include:

• required information is missing;
• two authoritative-looking sources conflict;
• the input is unreadable or in a new format;
• a value exceeds a policy or approval threshold;
• the same request appears twice;
• a downstream system is unavailable;
• the output cannot be verified; and
• the action has already partly happened, so a retry could duplicate it.

Then record the current response: stop, ask the owner, route to a specialist, use a fallback source, repair the input, or reverse the partial action. “A person handles it” is incomplete. Name the role, the decision, the evidence they need, and what resumes afterward.

This is also where the map begins to separate a useful agent from a fragile prompt. An agent needs to know not only what to do, but when the evidence is insufficient to continue.

Separate permission from authority

Technical access answers what a system can do. Business authority answers what it is allowed to decide or cause.

Mark each proposed agent action as one of these levels:

1. Read: retrieve and organize information without changing a source. 2. Draft: prepare a proposed output for review. 3. Recommend: compare evidence and explain a suggested decision. 4. Change internal state: update a record through a reversible, logged path. 5. Act externally: send, publish, spend, commit, delete, or make another difficult-to-reverse change.

Do not assign one approval rule to every workflow. NIST's Generative AI Profile notes that different applications and contexts may require different oversight and human-AI configurations, including additional review, tracking, documentation, or management attention.

For a first pilot, start with the narrowest level that can produce a useful, checkable result. Read-only analysis or a draft often reveals the quality of the inputs and exceptions without exposing the organization to an irreversible action.

The production AI agent checklist covers the additional identity, access, retry, monitoring, recovery, and lifecycle controls required before an agent touches real work more broadly.

Turn the map into a one-page implementation brief

Once the current state is credible, write a bounded future-state hypothesis. Keep it to one page:

• Agent job: the exact contribution the agent will make.
• Allowed inputs: the sources and fields it may use.
• Output: the draft, recommendation, or state change it may produce.
• Success checks: what a knowledgeable person or deterministic test can verify.
• Stop conditions: missing evidence, conflicts, thresholds, provider failures, or unsupported cases.
• Human boundary: the decisions and actions that remain with a named role.
• Recovery: how to resume, retry safely, or reverse a partial result.
• Pilot measures: the current baseline and the measures to compare after operation.

Consider a fictional supplier-quote intake, for illustration. A request arrives by email with a drawing. Today, an estimator checks completeness, looks up the customer and part, requests missing information, assembles a comparison, and sends the final response after an owner review.

The opening agent job should not be “handle quotes.” A bounded job could be: gather the permitted inputs into a draft packet, flag missing or conflicting fields, and stop for estimator review. The output is the packet and exception list. The done evidence is the saved packet, source links, and successful read-back. Commercial judgment and external sending remain with the named owner.

That brief can seed the operating context described in building the company brain and first workflow together. Real tests will reveal which vocabulary, source rules, examples, and exceptions deserve a maintained home.

Decide whether an agent belongs in the workflow at all

A completed map does not obligate you to automate.

The best next change may be removing a duplicate approval, fixing a system field, standardizing an input, clarifying ownership, or changing a handoff. If the workflow has no reliable inputs, no accountable owner, and no checkable output, an agent will inherit that ambiguity rather than cure it.

If an agent does belong, implement one loop at a time. The EPA's value-stream guidance recommends staged implementation with measurable goals and checkpoints because changing one part can affect the whole flow. Run representative normal and exception cases, compare the result with the baseline, and make an explicit continue, revise, hold, or stop decision.

The finished map should leave you with a better process decision even if the answer is “not yet.” That is the standard: understand the work well enough to choose the right intervention, then give an AI agent only the job, context, and authority it can actually support.

If you want help turning one difficult workflow into a measured, decision-ready implementation brief, start a free fit conversation.