Writing a workflow down well enough that AI can actually run it

Why the write-up is the actual deliverable

When a client asks me to automate something, my first instinct used to be to open whatever tool we'd settled on and start building. I don't do that anymore. The build is the easy part. The hard part is getting the underlying workflow out of someone's head and onto paper in a form precise enough that a system with no judgment can run it correctly on the tenth try and the ten thousandth try.

In one build I did for a small trusts and estates practice, the partner described their intake process to me in about four minutes, confidently, like it was obvious. It took us three sessions and about eleven pages to actually document it, because every 'usually' hid a decision point, every 'we just check' hid a rule nobody had written down, and every 'the paralegal handles that' hid three different paralegals doing three different things depending on who trained them.

That gap between the four-minute verbal version and the eleven-page written version is exactly where automation projects fail. Not because the AI is bad at the task, but because nobody actually specified the task. If you skip this step and go straight to prompting a tool, you end up automating the four-minute version, which is to say, you automate the parts people remember to mention and silently drop the parts they don't.

The test I actually apply

I ask one question of any workflow write-up before I'll build against it: could someone who has never set foot in this practice, and who has no legal judgment of their own, follow this document and produce the correct output, including handling the exceptions correctly, on the first try. If the honest answer is no, the document isn't done, no matter how long it is.

This is a higher bar than most internal SOPs clear. A normal SOP assumes the reader already knows the domain and is filling in gaps with common sense. A workflow meant to drive automation has no reader with common sense on the other end. It has a system that will do exactly, and only, what the document says, including doing the wrong thing exactly and consistently if that's what the document says.

How I structure the document itself

1. 1. Name the trigger

   What exact event starts this workflow. Not 'when a new matter comes in,' which is vague, but the specific artifact or action, such as 'when a signed engagement letter is received and logged in the matter system.' If you can't name a concrete trigger, you probably have two workflows tangled into one.

2. 2. List every input and where it comes from

   Every document, data point, or piece of information the workflow consumes, and its source. I've had clients tell me a step 'just needs the client's information' and then discover during build that it actually needs six specific fields pulled from three different systems, two of which nobody had mentioned.

3. 3. Map the decision points explicitly

   Every place where the process branches, write the condition and both outcomes. 'If the matter value exceeds a threshold, route to senior review, otherwise proceed' is a real rule. 'Bigger matters get more attention' is not, because a machine can't act on it.

4. 4. Define the exception path before the happy path

   I've flipped this order deliberately. If you design the smooth case first, the exceptions get bolted on as an afterthought and usually get it wrong. Ask what happens when a document is missing, when a deadline conflicts with another matter, when the client doesn't respond. Write those answers down as rules, not as 'use judgment,' because the system has none.

5. 5. Name the exit criteria and the human checkpoint

   Where does this workflow definitively end, and at what point, if any, does it have to stop and wait for a lawyer to look at it. I put this in writing as a hard rule, for example 'any output touching a filing deadline requires attorney sign-off before it leaves the system,' rather than trusting that everyone will remember to check.

Where these documents usually fall apart

• Conflating what should happen with what currently happens. Document reality first, improve it as a separate, deliberate step. Don't let the automation quietly encode a workaround nobody actually endorses.
• Assuming shared vocabulary. 'Reviewed' means something different to a paralegal doing a first pass and a partner doing a final sign-off. Define terms the first time they appear.
• Skipping frequency and volume. A workflow that runs twice a month and one that runs two hundred times a day have different tolerances for a wrong turn, and the document should say which one this is.
• Leaving out who owns the workflow going forward. Someone has to be named as the person who updates this document when the underlying practice changes, or it goes stale within a quarter.

Turning the document into something a system can run

Once the workflow document is solid, the actual build tends to go fast, which is the opposite of what most people expect. Under the MATTER Method I use with clients, this documentation step is deliberately the slow one and the build is deliberately the fast one, because a precise specification collapses most of the ambiguity that otherwise gets discovered, expensively, during testing.

I usually build the first version as a computed module: a narrow, auditable piece of automation that handles exactly the steps the document specifies, with the human checkpoints built in as hard stops rather than suggestions. I resist the urge to make it 'smarter' than the document, because a system that improvises beyond its specification is a system nobody can predict, and prediction is the entire point of having a workflow in the first place.

The document doesn't get thrown away once the build ships either. I keep it as the source of truth, and any change to the actual process starts with an edit to the document, then a corresponding change to the build. Treat it like you'd treat a form contract: version it, date it, and know exactly which version is live.