Automating a workflow isn't one decision. The same task — routing incoming support requests, say — can run on fixed rules, on a model, with a person confirming the result, or stay manual until someone can say what "right" looks like. Asking "should we use AI?" skips that choice, and skipping it can leave a workflow with an engine it doesn't need, or without a checkpoint it does.
We build automation, including AI-assisted systems, so we have an interest in you automating something. That's a reason to be careful about how. The framework below is built so it can end at "use plain rules," "keep a person in the loop," or "not yet."
What each part is good for
Rules. A rules-based flow gives the same output for the same input, so you can test it against the rule and trace a wrong result back to it. It fits work where inputs arrive in a defined shape and the mapping is explicit — a subscription event becoming a record, an order becoming a row. Where the mapping is already exact, a model can't improve on it; it only adds something else to check.
AI. A model earns its place when writing the rule is impractical — free text, scanned documents, requests that need summarizing, classifying or drafting. What it adds is the ability to handle that variety; what it costs is that its output isn't guaranteed to be the same for the same input, the way a rule's is. That's manageable when someone can tell a good result from a bad one and a miss is affordable, which is why the first question and the checkpoint question matter for AI in particular.
A checkpoint. A person confirms before the action is final. It works on either engine, and it isn't automatically a stepping stone: it can stay for as long as a wrong output stays costly. It only helps if the reviewer can actually judge the output — a checkpoint nobody can evaluate is a formality.
Not yet. Manual isn't a failure state. Doing a process by hand can be how you find out what it actually is, and automating one that isn't settled just makes the confusion move faster. "Not yet" means map it first, then ask the questions again.
What our own work does and doesn't show
Six automation projects in our portfolio, including our own operations stack, list no AI or model anywhere in their records. What they list is rules-shaped work:
That shows where our own work has been rules-shaped. It doesn't show that AI wouldn't have helped in any of them, and we don't have a documented example of the AI-assisted or checkpoint shapes to show here, so we won't pretend to. Floating Stone Ranch comes closest to the "not yet" logic: its record starts from manual spreadsheets and paper, describes the schema first with the automation layered on top, and lists process mapping and data modeling among the deliverables. That illustrates the order — structure before automation — not proof that the process was unsettled when we began.
What would change the answer
None of the answers is permanent. A few things should send you back to the questions:
- A rules-based flow keeps needing new special cases. The work may be more interpretive than it looked.
- The inputs change shape. A flow that was exact can stop being exact when a form, a vendor or a file format changes.
- A wrong output starts to cost more. The flow that updated an internal sheet now sends customer emails or moves money. The engine didn't change; the checkpoint answer did.
- You start logging what reviewers change. That gives you evidence about whether a checkpoint is earning its place — a decision to make from the log, not from confidence.
