You have chosen the first process for your AI agent. The next step is usually skipped: writing down what the process actually is. Teams jump to tools and demos, and discover in the pilot that nobody agrees on what a "finished" case looks like, that half of the work lives in one person's head, and that the exceptions are most of the volume.
This article is for the manager or process owner who has to hand a process to a supplier or an internal team. It assumes you have already chosen the process. The aim is a single page that lets someone else build, test and review the agent without guessing.
1. Describe what happens, not what the manual says
Start by watching the work. Sit with two or three people who do the process, ideally on different days, and follow real cases from start to finish. Written procedures are usually tidier than reality: they leave out the spreadsheet someone keeps on the side, the colleague who is always asked about difficult cases, and the step that is skipped when the queue is long.
Value stream mapping, a method from lean practice, is built on the same idea: you map the flow as it is observed, including waiting and rework, before you try to improve it (Lean Enterprise Institute). You do not need a formal diagram. A numbered list of steps is enough, as long as every step is something you saw.
For each step, write:
- What triggers it (an email, a form, a status change, a time of day).
- What the person does, in one sentence with a verb.
- What they look at to decide, such as a document, a screen or a rule of thumb.
- What comes out and who receives it.
If a notation helps your team, BPMN is a widely used standard for process diagrams (OMG BPMN 2.0). It is optional; a clear list beats a diagram nobody maintains.
2. Collect the exceptions on purpose
The standard path is the easy part. Ask the people doing the work: "What makes you stop and ask somebody?" and "What was the last case that went wrong?" Write down each answer as an exception with three fields: how you recognise it, what happens next, and who decides.
Typical exceptions are missing information, a customer with a special agreement, an unusually large amount, a case that touches legal or personal data, and a request that looks like a normal one but is not. Estimate roughly how often each occurs. If exceptions are, say, a third of the volume, an agent that handles only the standard path will save less than you hoped, and you should know that before you start.
For each exception, decide one of three outcomes: the agent handles it, the agent prepares it and a person decides, or the agent hands it over at once. This is the basis for the approval and escalation design described in human approval and audit trails.
3. Name the owner and the definition of correct
Every process needs one person who can answer: "Is this result right?" Not a committee, and not the person who builds the agent. The owner approves the description, sets the quality bar, accepts or rejects the pilot results, and is the contact when something goes wrong.
Ask the owner to write three to five examples of a good result and three to five of a bad one, using real cases with personal data removed. These examples become the first test set. Without them, "the agent works" will mean whatever the most recent demo showed.
4. List the data and systems
Make a short table of everything the process reads or writes:
- Source or system (mailbox, CRM, shared drive, ERP, paper form).
- What is taken from it and what is written back.
- Who may see it today, and whether the agent should have the same access or less.
- Quality in plain words: complete, often out of date, or entered by hand with errors.
This table tells you early whether the process is feasible. Knowledge that exists only in conversations or in a person's memory has to be written down first, and data that is unreliable has to be cleaned or excluded. If personal data is involved, your records of processing are a natural starting point; GDPR Article 30 describes what such records contain (GDPR Art. 30). The access side is covered in identity and least privilege for agents and the retention side in data handling and retention.
5. Write the decision rules in plain language
Many steps rely on judgement that people have never put into words: "we usually refund if it is under this amount", "this customer gets a call, not an email". Ask the owner to state each rule as an if-then sentence, and mark which ones are firm policy and which are habit. Rules that the team cannot agree on are a finding, not an obstacle. Resolve them with the owner before the agent inherits the ambiguity.
Where a rule cannot be written down, say so. That step stays with a person, or the agent only proposes and the person decides.
6. Record the baseline
While you are describing the process, take the numbers you will need later: how many cases per week, how long a case takes from start to finish, how much hands-on time it needs, and how often it is corrected. Even rough figures from a sample of two weeks are useful. They are the baseline for measuring whether the agent saves work, and without them every later claim of improvement is an opinion.
7. Put it on one page and test it
Combine the parts into one page with these headings: purpose and trigger, owner, steps, exceptions with outcomes, data and systems, decision rules, baseline, and what "done" means. If it grows beyond a page, the process is probably two processes; split it.
Then test the page. Give it to someone who does not work in the process and ask them to explain it back and to handle two sample cases from it. Every place where they hesitate is a place where a supplier or a model would guess. Fix those places, then share the page with the vendor or the build team. The same page later becomes the core of the runbook in handing an agent to a new team.
8. Questions to ask before you hand it over
- Was the description made by watching real cases, and not only from a manual?
- Are the exceptions listed, with a rough frequency and a decided outcome for each?
- Is there one named owner who accepts or rejects the results?
- Do we have examples of good and bad results to use as tests?
- Are all data sources and access rights written down?
- Are the decision rules written, and do the owner and the team agree on them?
- Is the baseline recorded?
A short checklist
- Observe two or three people on real cases and write the steps as they happen.
- Collect exceptions and decide who handles each one.
- Name the owner and gather examples of good and bad results.
- Table the data, systems and access.
- Write the decision rules as if-then sentences.
- Record the baseline numbers.
- Fit it on one page and let an outsider test it.
The work takes a few days, and it feels like delay. In practice it is where most of the pilot's uncertainty gets removed, while changes are still cheap. An agent built on a clear page is easier to build, easier to test and easier to explain when someone asks why it did what it did.
