How to Document a Workflow So an AI Agent Can Actually Run It

When an automation project stalls, the cause is rarely the model. It is that nobody can state precisely what the process is. A procedure that reads "review the invoice and enter it into the accounting system" is perfectly clear to an experienced bookkeeper and almost useless to an agent, because every hard decision is hidden inside the word review.

Good news: writing this down is not a technical task. Anyone who does the job can do it, and the document is worth having whether or not you automate.

Start from a real example, not a summary

Open an actual recent case - a specific email, a specific invoice - and narrate what you do with it, click by click. Summaries skip exactly the details that matter. "I check whether it's a new vendor" becomes, on inspection, "I search the vendor list by tax ID, and if there's no match I search again by name because the tax ID is sometimes missing."

Do this for one clean case first, then for the two most recent awkward ones.

Write the decisions as rules, not as judgement

Every point where a person decides something needs to become a rule with an explicit default. The useful test: could a competent new hire, on their first day and with no context, reach the same answer as you? If not, the rule is underspecified.

Turn each decision into three parts:

• The condition - what specifically is true about this case?
• The action - what happens when it is true?
• The fallback - what happens when you cannot tell?

That third part is the one teams skip, and it is the most important. An agent with no defined fallback will improvise, and improvisation is precisely what you do not want automated. In almost every workflow the correct fallback is "stop and hand this to a person."

Name the exact systems and fields

An agent has to touch real software, so vague references have to become specific ones. Not "put it in the CRM" but "create a Deal in HubSpot, set Stage to Qualified, set Amount from the quote total." Not "email the client" but "reply on the existing thread from the shared inbox, keeping the original subject line."

Where a value gets copied between systems, write down both the source and the destination field. This is also where you will notice that two systems disagree about what a "customer" is - a problem worth catching now rather than after go-live.

Mark what must never be automatic

Write an explicit list of actions the agent may never take on its own. Typical entries include issuing refunds, sending a first contact to a new client, changing payment details, deleting records, and anything involving a legal or medical decision.

Being specific here is what makes the rest safe to automate. A tightly bounded agent that escalates ten percent of cases is far more valuable than a permissive one that handles everything and occasionally does something you have to apologise for.

Note how you would know it went wrong

Finally, write down what a bad outcome looks like and how it would surface today. If the honest answer is "the client would tell us," that is a signal to add a check before automating, not after.

A workable format

You do not need special software. A single page per workflow, in this shape, is enough to brief either a new hire or an engineer:

1. Trigger - what starts this process, and where does it arrive?
2. Inputs - what information is needed, and where does each piece come from?
3. Steps - the click-by-click sequence for the normal case.
4. Decision rules - condition, action, and fallback for each judgement call.
5. Never automate - the explicit stop list.
6. Done - how you know the case is finished and correct.

Teams that write this page before starting almost always deploy faster, because the ambiguity gets settled once, in a document, instead of repeatedly in the middle of a build.