AI Can Run Your Processes.
But Only If They're Written Down.

Ask someone on your operations team how they handle a specific recurring task — onboarding a new vendor, processing a refund request, escalating a support ticket. They'll tell you. Clearly, confidently, in about two minutes.

Then ask them to write it down.

What comes back is usually a half-page of vague steps with phrases like “check with Sarah” and “use your judgment here.” The actual process — the one that runs every day — is living in their head, assembled from three years of trial and error and institutional memory.

That's fine when a human is doing it. It's a dead end when you want AI to do it.

AI agents don't read minds

AI agents can now execute complex, multi-step workflows with almost no latency. They can read emails, query databases, make API calls, write summaries, and route outputs — autonomously, around the clock. The technology is genuinely capable.

But every task you hand to an AI agent needs to be specified. Not at a high level. In detail. What triggers it. What data it needs. What decisions it makes, and on what criteria. What happens when something is ambiguous. What the output looks like and where it goes.

If you can't answer those questions in writing before you build, you're not ready to automate. You'll build something that handles the easy cases fine and falls apart on anything edge-case — which is exactly where errors are expensive.

The documentation gap is the automation gap

Most operations teams vastly underestimate how undocumented their processes are. Not because they're disorganized — but because documentation has never mattered before. When the same three people always handle something, tribal knowledge works fine. Knowledge transfer happens through sitting next to someone for a week, not through written specs.

AI changes this completely. You can't sit an AI agent next to someone for a week. It needs the spec.

This is why so many AI automation projects underdeliver. The technology works. The documentation doesn't exist. So the automation handles 70% of cases well and silently mishandles the other 30% — which is often worse than no automation at all.

What good process documentation actually looks like

It doesn't need to be long. It needs to be complete. For any process you want to automate, get answers to these five things before you write a single line of code:

Trigger: What causes this process to start? An email arriving? A form submission? A calendar event? A time of day? Be exact.

Inputs: What data does the process need to run? Where does each piece come from? What happens if a piece is missing?

Decision rules:Where does the process branch? Write the actual rule — not “use your judgment,” but “if X, do Y; if Z, do W; if neither, escalate to [person].”

Output: What does done look like? Where does the output go, in what format, and who (if anyone) gets notified?

Exceptions: What are the top three ways this goes wrong, and what happens when it does?

If you can answer all five for a process, you can build a reliable automation around it. If you get stuck on any of them, that's the work to do first.

A side benefit you didn't expect

Here's something that comes up constantly: the act of documenting a process for automation surfaces problems in the process itself.

When you try to write down every step and every decision rule, you find steps that only exist because of a workaround from three years ago. You find decisions that “use your judgment” in ways that are actually inconsistent across team members. You find handoffs that slow things down for no real reason.

Before you automate anything, you clean it up. The automation you build is faster because the process underneath it is better.

This is one reason we tell clients not to automate anything they haven't documented first — not just because AI needs the spec, but because documentation forces clarity that makes the whole operation tighter.

Where to start this week

Pick one process. The one that runs the most often, or costs the most time. Sit down with the person who owns it and walk through it step by step. You write it down while they talk — don't ask them to write it, they'll underspecify. Ask why at every step. Push until every decision has an explicit rule.

By the end of an hour, you'll either have a solid spec for automation — or you'll have found the holes that need to be fixed first. Either outcome is valuable.

Document it. Then build. In that order.