How do you document an AI agent's process?

Map the process step by step, mark who does each step and at what depth, and tie every rule to its source document. Write down the unwritten rules staff apply. Then walk real past cases through the document to prove it is complete, and put it under version control. For an agent, the process document is part of its instructions.

Why does documentation matter more with an agent?

Because staff fill gaps and agents do not. A procedure that says "check the customer's identity" works for a person who knows which checks the team actually runs. An agent reading the same line has to guess. Every gap in the document becomes either a refusal, an escalation, or an error.

The document also becomes evidence. When someone asks why the agent did what it did, the answer runs through the process document, the rule it applied, and the source that rule came from.

What should the document contain?

The rules section usually takes the longest, because many rules have never been written down.

What are the steps, and who does each?

1. Process owner and team: map the current process. Walk through it with the people who do it. Evidence: the current-state map.
2. Subject experts: surface the unwritten rules. Sit with experienced staff as they work real cases and ask why at each decision. Evidence: a rule list, each rule with an example case.
3. Subject experts: link each rule to a source. Policy, procedure, contract term, regulation. Rules with no source get one, or get removed. Evidence: the source register.
4. Process owner: decide what the agent does. Mark each step agent or person, and set the depth for agent steps. Evidence: the future-state map.
5. Process owner and risk: write hand-over and exception rules. Evidence: the hand-over section, approved by risk.
6. Agent operations lead: test the document. Walk twenty or thirty past cases through it on paper. Every case the document cannot handle reveals a gap. Evidence: the walk-through log.
7. Process owner: approve and version. Evidence: the approved version with change history.

Step 4 is often where the process changes. Doing a process with an agent is a chance to remove steps that existed only to move information between people; see how to redesign a process for AI agents.

What does this look like in practice?

Take a pensions administrator documenting how it handles requests to transfer a member's pension to another scheme. The written procedure is four pages. Sitting with two experienced administrators surfaces eleven rules that are not in it, including that requests from certain receiving schemes need an extra check, and that members over a certain age get a specific risk warning letter.

Each rule is traced to a source: two to regulatory guidance the firm follows, five to internal policy, four to a past incident review. One rule turns out to have no current source; the team checked something that a system change had made redundant years ago. It is dropped.

The walk-through of thirty past cases finds one more gap: transfers where the member has died and the request comes from executors. That becomes a hand-over rule. The agent drafts the checks at depth 2, and administrators decide.

How do you keep the document current?

Treat it like code. Changes go through change control, are approved by the process owner, and trigger re-testing of the agent before they take effect. A rule change in the source policy should prompt a review of every process document that cites it. If the document and the agent's actual behaviour drift apart, the document is no longer evidence of anything.

Choosing where to start is covered in which process to give an AI agent first, and the stages that follow in deploying an AI agent: train, shadow, certify, widen.