What does process mapping for AI actually mean?

Process mapping for AI means describing how a real piece of work moves from a clear starting event to an accepted result. The map shows what information arrives, who or what acts on it, which decisions are made, where work waits and what happens when something goes wrong. It gives you a basis for deciding which steps to remove, improve, automate or support with an agent.

At CSM, we use flow path analysis to examine those connections. A diagram is useful when it helps people agree how work should move. It becomes an implementation specification only when the handovers, permissions, checks and exception routes are precise enough to build and test.

Begin with a recognisable unit of work: one quotation, one invoice exception or one article. “Improve marketing with AI” is too broad to test. “Reduce the time required to produce an approved, evidence-backed article” gives a process owner something concrete to investigate.

Why should leadership set the direction first?

Leadership needs to choose the outcome, name the accountable owner and make time available for the work. An agent can produce more drafts without improving decisions, reducing delays or helping customers. Agree what a better business result looks like before choosing a tool.

Set boundaries at the same time. What may the system read? What may it prepare or change? Who can approve an external commitment? What would a costly mistake look like? A named reviewer also needs the time, evidence and authority to challenge an output. Assigning responsibility without providing those conditions creates a weak control.

For a publishing process, the outcome might be useful answers to recurring buyer questions, produced consistently with less editorial effort. The owner should agree how that usefulness will be assessed. Article volume is an activity measure; it cannot establish commercial value on its own.

How do you discover the process people really use?

Ask someone to open a recently completed job and walk through the actual emails, documents and systems. Record what happened rather than what the procedure says should have happened. Look for copying between tools, searching for current information, informal approvals and colleagues who resolve ambiguities from memory.

Then repeat the exercise with another person and an awkward example. One smooth job will not reveal a missing document, conflicting instruction or unavailable approver. Differences between people may expose a useful improvement, an essential exception or an inconsistency that needs resolving.

Ask what “checked” means. A reviewer may be checking factual accuracy, source freshness, customer relevance and permission to publish. Those checks need distinct criteria. A single box labelled “review” hides the judgement that makes the process dependable.

What should you capture at every stage?

For each step, record the input, action, output, owner and condition for moving on. Include the system used, relevant permissions, expected working time, waiting time and the route for incomplete or rejected work. You should be able to explain why the next person can safely use the output.

For example, an editorial handover might require a versioned draft, its approved brief, supporting sources, image rights and a list of unresolved claims. The editor returns an approved version or specific revision requests. If required evidence is missing, the work returns for clarification before it reaches publication.

Record decisions as well as tasks. “Send to the manager” is incomplete. What decision must the manager make? Which evidence accompanies it? What happens if they reject it or do not respond? An arrow should carry enough context to prevent the next stage from repeating the investigation.

How do you find the bottleneck before adding AI?

Measure active working time separately from elapsed waiting time. Ten minutes of editing followed by two days awaiting approval is principally a queue problem. Faster drafting may add work to that queue without reducing the time to publication.

Look for repeated entry, avoidable approvals, unclear acceptance criteria and rework caused by missing information. Remove unnecessary steps and clarify decisions before automating them. If one reviewer can properly assess three drafts, producing twenty drafts does not create capacity to publish twenty good articles.

Use a baseline from representative work. Track how often exceptions occur, how long they take and why work returns to an earlier stage. Treat early estimates as estimates. Use the pilot to establish whether the proposed change improves the complete process, including the human review burden.

When should you use a person, a fixed rule or an AI agent?

Use a fixed rule when the decision is explicit and repeatable, such as checking that required fields are present or routing an approved item to the correct queue. Use an agent when interpreting variable information or preparing a response adds value. Keep people responsible for consequential judgement and exceptions outside the agreed boundaries.

Anthropic distinguishes workflows with predefined paths from agents that direct their actions dynamically. Its guidance recommends starting with the simplest approach that meets the need. A business process can combine both: an agent prepares a draft, while ordinary software enforces approval before publication. Read Anthropic’s explanation.

Giving an agent more tools or autonomy is a design choice that needs justification. The process owner should be able to explain which uncertainty the agent resolves and why a simpler rule or existing software feature is insufficient.

What does the blog-publishing example look like?

The Flow Studio example in the video starts with an agreed brief: audience, question, purpose, evidence requirements and approver. Research produces an outline and evidence record. Writing receives both, together with the writing playbook, and produces a draft. Editorial review checks the claims and quality and identifies unresolved questions.

Next, the system prepares a CMS draft. A person inspects the exact preview, including the headline, images, links and metadata. Publication requires a valid approval for that version. A separate check confirms that the intended page is live and that its important elements work. Only then is the job marked complete.

Each stage needs an explicit completion condition. Research is not complete because an outline exists if the supporting evidence is missing. Publication is not complete because a request was sent if the live page cannot be verified. These distinctions make the workflow useful to the next person.

The example illustrates a design approach, not a guarantee that every business needs separate research, writing and editorial agents. Combine or simplify stages where that makes the process easier to maintain without losing necessary checks.

What belongs in an agent playbook?

A playbook defines the task, required inputs, expected output and acceptance criteria. Include approved examples with an explanation of why they work, boundaries on claims and actions, and a clear escalation route. Keep the instructions specific enough that a reviewer can identify whether the output meets them.

For a writing stage, useful rules include answering the agreed customer question, attaching evidence to material factual claims, distinguishing examples from actual results and flagging unsupported benefits. The handover should retain source references so an editor can inspect the evidence rather than reconstruct the research.

Capture the reason behind corrections. “This benefit is unsupported; remove it or request evidence” can become a repeatable check. The process owner should approve whether a correction is general enough for the playbook or applies only to that project. Version the change and rerun representative examples. Updating instructions or reference material does not itself train the underlying model.

How do you make approval a real control?

Approval must be enforced by the system performing the action. A prompt saying “ask permission first” and a diagram containing an approval box are not equivalent to an enforced publishing restriction. Bind approval to the exact content version and record who approved it. Material changes should invalidate that approval until the changed version is reviewed.

Limit access to the tools, records and actions the task needs. OWASP’s excessive-agency guidance recommends limiting functionality and permissions and requiring human approval for high-impact actions. For publishing, this means the publishing operation itself checks authorisation before it executes. Read OWASP’s guidance.

The reviewer needs visibility of the sources, uncertainty and proposed action. Agree who maintains access, who can pause the workflow and where the action history is recorded. These are implementation responsibilities to resolve and test, not outcomes that a process drawing proves.

What happens when the normal route fails?

Define the exception routes before launch. Missing evidence should request clarification. Failed checks should return specific reasons for revision. Repeated failure needs an agreed stopping point and a named person to intervene. A rejected article can be closed or rebriefed; it should not loop indefinitely.

No response from the approver means the item remains pending. A publishing timeout needs investigation before a retry because the first request may have succeeded. Check for an existing publication or use a unique operation reference to avoid duplicates. If the wrong version is live, notify the website owner and follow an agreed recovery procedure.

Test these scenarios deliberately: unavailable approver, changed content after approval, expired access, missing sources and a failed connection. A convincing demonstration of the normal route is only one part of readiness for daily use.

How should you pilot and measure the workflow?

Start with an assisted pilot in which agents prepare work and people control consequential actions. The video suggests three representative articles as an initial exercise. That is a practical starting point for this example, not a statistically sufficient test or a universal release threshold. Broader, riskier and more variable processes need more coverage.

Compare human editing time, approval waiting time, first-pass acceptance, repeat errors, tool costs and maintenance effort against the current process. Count the time required to supervise and correct the system. Assess commercial contribution separately using measures appropriate to the purpose, such as whether the content answers sales questions or supports useful enquiries.

Agree the conditions for expanding, revising or stopping the pilot before seeing the results. Keep a process owner responsible after launch. Recheck representative cases when models, instructions, connected systems or business rules change, because a previously acceptable result may no longer be dependable.

How would CSM help your team get started?

We start with a leader’s priority, then map real work with the people doing it. Together, we identify which steps can be simplified, what information needs an owner and where people, ordinary automation and agents each belong. The first scope should make responsibilities, access, testing and success measures explicit.

Our role as a fractional team is to support your internal knowledge with implementation capability. The aim is a workflow your people can inspect, correct and maintain, with clear human responsibility. Bring one recurring piece of work, a recent example and the person who knows where it gets stuck. That is enough to begin a useful discovery conversation.

For the broader foundations, explore how to build an AI Commercial Brain.