Process Mapping for AI Automation: Map the Work Before the Agent

Process mapping for AI automation means writing down how a piece of work actually happens before any agent is configured: the steps, who owns each one, what can go wrong and who approves what. The map shows which steps are routine enough to delegate, which need a human decision, and what information an agent needs to act. Without it, you automate your assumptions about the work instead of the work itself.

Key takeaways

• Map the work as it is done today, not as the handbook describes it. The gap between the two is where agents fail.
• Record the same few things for every step: trigger, input, action, owner, decision rule and approval. Give exceptions their own attention.
• Interview the people who do the work, then replay a real case from start to finish.
• Mark each step as delegate, draft for review, or keep human. That marking becomes the agent's role boundary.
• Name an owner for the map itself, because the process will change and the agent's behavior must follow it.

Why map the process before configuring an agent?

An agent is good at following a defined role and poor at guessing one. When a company hands over a process that lives in people's heads, the agent receives a tidy description that leaves out the phone call someone always makes, the customer who is handled differently, and the approval that happens by habit rather than policy. The agent then does what the description says, and the business finds the missing parts one incident at a time.

Mapping changes the order of the work. You decide what the role is first, then choose the memory, tools and permissions that fit it. Anthropic's engineering guidance on building effective agents makes a similar point: start with the simplest structure that solves the problem and add complexity only when the task demands it. You cannot judge what the task demands until you have seen the task written down.

A map also gives you a baseline. If nobody recorded how the work was done and what a good result looks like, nobody can tell later whether the agent improved anything or only moved the effort somewhere else. If you have not yet chosen which process to map, start with a first workflow small enough to prove. A narrow process is faster to map and easier to check.

What should a process map capture?

A map for automation is more detailed than a flowchart for a slide. It needs to answer the questions an agent cannot answer by itself. For each step, write down:

• Trigger: what starts the work (an email, a form, a date, a message) and how it reaches the team.
• Inputs: the documents, data fields and context needed, and where each one lives.
• Action: what is done, in plain verbs.
• Owner: the named role accountable for the step. A role, not a department.
• Decision rule: how the person chooses between outcomes, written as a rule if one exists and marked as judgment if not.
• Approval: who must say yes before the step is final, and what they see when they decide.
• Output: what exists when the step is done and where it is stored.
• Exceptions: what breaks the normal path and where it goes.
• Systems touched: which tools are read and which are written to, so access can be sized later.

The decision rule line deserves extra care. Many steps that look mechanical contain a quiet judgment, such as whether a request is urgent or whether a customer deserves an exception. If the person cannot state the rule, the agent cannot follow it. That step stays with a human, or it becomes a draft that a human confirms.

How do you run the mapping exercise?

The exercise needs a few people and a few focused sessions, not a long project. A shared document is enough. Diagrams can come later if they help.

• Set the boundary. Pick one start event and one end event, for example from a supplier invoice arriving to a payment being scheduled. Anything outside those two points is out of scope for now.
• Interview two or three people who do the work, separately. Ask each to narrate the last real case, not the ideal one. Separate interviews reveal differences that a group meeting hides.
• Replay a recent case from the actual messages, files and system records. Note every tool opened and every person contacted.
• Write the normal path in plain verbs, one step per line, with trigger, input and owner.
• Add the exceptions. For each step ask what happens when the input is missing, wrong, late or contested.
• Mark the approvals. Note where someone signs off explicitly and where approval happens by silence or habit.
• Classify each step as delegate, draft for review, or keep human.
• Walk the map back to the people who do the work and correct it. Then name who owns the map.

Two cautions. First, do not map from the policy document alone. Policies describe intent, and the people doing the work describe practice. Second, do not let the map grow to cover the whole department. A map that cannot be reviewed in one sitting will not be maintained.

How do you surface exceptions and unwritten rules?

Exceptions are where the real process hides. People rarely volunteer them because, to the person doing the work, they are simply part of the job. Direct questions work better than a request to describe the process:

• What do you do when the request arrives incomplete?
• Which customers, suppliers or cases do you handle differently, and why?
• When did this last go wrong, and what did you change afterward?
• What do you check that is not written anywhere?
• Who do you ask when you are unsure, and how long do you wait?
• What would you never let someone else do without telling you?

The last question is especially useful. The answer usually points to a hidden approval or a risk the team already manages informally. Write it down as a boundary, not as a footnote.

For every exception, record two things: how it is recognized, and who receives it. An agent that cannot recognize an exception will treat it as a normal case. An agent that recognizes it but has nowhere to send it will stall or improvise. The way an escalation should arrive is its own design task, covered in sending the decision to a human, not the mess.

An illustrative scenario: supplier invoices

This scenario is illustrative, not a real case. A small wholesale company wants an agent to help with supplier invoices. The written procedure has five steps: receive the invoice, enter it, match it to a purchase order, get approval, schedule payment.

The mapping sessions find more. Invoices arrive through a shared inbox, through a supplier portal, and occasionally in a site manager's personal messages. The bookkeeper compares bank details with the previous invoice by eye, a check that appears in no document. Invoices from one subcontractor are approved by the project lead, not by finance. Credit notes are sometimes filed as invoices, and the team corrects them at month end.

After classification, the map looks like this:

• Delegate: reading fields from the document and matching them to the purchase order, with every match shown alongside its source.
• Draft for review: proposing the account coding, and flagging any change in bank details for a person to check.
• Keep human: approving payment, changing supplier records, and anything involving the subcontractor exception.
• Fix first: the personal-message channel and the credit note habit. Neither is an agent problem. They are process problems the map made visible.

The map did not make the agent bigger. It made the role smaller and more precise, and it showed two problems that would have undermined any tool. A fuller walkthrough of this kind of workflow is in AI invoice intake with human approval.

How do you turn the map into agent boundaries?

Once the map is reviewed, use it as a decision guide for each step:

• Delegate when the input is clear, a written rule exists, the result is easy to reverse and the cost of a mistake is low.
• Draft for review when the step needs judgment but a person can approve quickly from evidence the agent supplies, such as the source document and the rule applied.
• Keep human when the result is hard to reverse, moves money, affects a person's employment or legal position, or depends on a relationship.
• Pause and fix the process when nobody can say who owns the step or what the rule is.

The classification then sets the technical design. Each delegated or drafted step implies the access it needs and no more. Each approval defines a checkpoint and what the approver sees. Each exception defines a route. Owners from the map become the people named in a RACI for company AI agents, so responsibility is settled before the first run, not after the first mistake. OWASP's authorization guidance supports the same habit of granting only the permissions a task requires and checking them on every request.

Finally, write one success criterion that someone can observe. It can be as plain as whether reviewers accept the drafts without rewriting them, or whether the exception queue contains only real exceptions. Decide it from the map, before the agent runs, so that nobody adjusts the target afterward.

How does Be Human use the map in a managed engagement?

Be Human treats the process map as the input to the first engagement. From it, the work defines one useful role, the memory and tools that role needs, the approval boundaries and an observable success criterion. Managed operations then keep the map and the agent aligned: monitoring, recurring evaluations, integration maintenance and permission review continue, and when the process changes, the map is updated first and the agent's configuration follows with controlled changes. The service is remote and available in English and Portuguese.

Frequently asked questions

How detailed does a process map need to be? It needs to be detailed enough that a new colleague could do the work without asking someone for the unwritten parts. If a step still depends on someone saying that you just know, keep digging until the rule or the judgment is written down. Stop when further detail would not change a decision about delegation, approval or access.

Who should be in the room when we map the process? Include the people who do the work today, the person who approves its results, and someone who can change the process if the map reveals a problem. Managers alone tend to describe the policy. Practitioners describe what happens, and both views are needed to see the difference.

Should we fix the process before automating it? Fix the parts the map shows to be unowned, contradictory or unsafe, such as a channel nobody monitors or an approval nobody has authority for. You do not need a perfect process, but you do need a stable one with named owners. Automating a confused process makes the confusion faster and harder to see.

How often should the map be updated? Review it whenever the process, a tool or an approver changes, and on a regular schedule even when nothing seems to have changed. Practice drifts quietly, and an agent configured from an old map will keep following the old process. Give the map a named owner so that the review has someone responsible for it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.