Everyone wants an agent right now. Founders ask for bots that handle support tickets, marketing teams want AI to write and post content on a schedule, and operations leads want approvals without anyone in the loop.
The appetite is reasonable. Automation saves time when it works. But underneath almost every automation request we get at Purple Brains sits the same gap: nobody has written down the process.
There is a goal, a vague sense of steps, and a wish for the computer to handle the rest. That gap is where automation projects go wrong, and AI has made it easier to ignore.
The Principle: Automation Needs a Process First
A process needs a clear trigger, inputs, steps, decision criteria, outputs, ownership, guardrails, and exception handling before it can be automated.
AI can make a defined process smarter, but it does not remove the need for structure. If a process is well defined, automation makes it faster and more consistent. If a process is vague, automation makes the vagueness move faster and look more official.
AI changes what is possible inside a process step. Instead of a rigid if-this-then-that rule, a model can weigh several signals against criteria you set, letting you automate steps that used to require a person.
But that judgment still has to sit inside a structure. The trigger, the inputs, the decision criteria, the output, and the owner are all still needed. Take any of them away and you do not have an automatable process. You have a wish.
Deciding What to Automate: A Practical Checklist
Before touching any tool, walk through a short set of questions. It is not exhaustive, but it catches most false starts.
-
Define the goal. What outcome are you producing, in one sentence? Not “be more efficient,” but the specific thing that should exist at the end: a scheduled post, an approved refund, or a routed ticket.
-
Identify a repeatable process. Has this happened in roughly the same way at least a handful of times? If every instance is genuinely unique, you are automating chaos, not a process.
-
Confirm a clear trigger. What specific event starts the work? “Someone feels like it” is not a trigger. “A new lead form is submitted” is.
-
Check input quality and availability. Do you have the data needed at the moment the trigger fires, in a usable format?
-
Assess decision rules. Can you write down, even loosely, the criteria a reasonable person uses to decide the next step? If you cannot explain your logic to a new hire, a model cannot use it either.
-
Estimate exceptions. How often does the process deviate from the standard path, and how different are those deviations?
-
Evaluate risk. What happens if the automated output is wrong? Low-stakes mistakes are fine to automate early. High-stakes ones need more scaffolding first. A human should be in the loop whenever the outcome is customer-facing, presents significant risk such as financial risk, or could create a serious problem for the business.
-
Decide whether human judgment is still central. This determines where the human-in-the-loop checkpoint belongs. If the value of the task is the judgment itself, automation should support the person making the call, not replace them.
The Case Study: From Monday Morning to Published Post
To see what “ready to automate” looks like, follow one process we run: taking an article from idea to published social content.
Every stage has a trigger, input, output, decision rule, owner, and approval gate before the next stage starts. Run it against the eight questions above and it clears every one.
The trigger is concrete: a Monday morning routine starts the workflow. Research runs against a set of topics, and the output is five researched article ideas.
The human in the loop is Richard, who decides which idea to write. Nothing moves toward drafting until he picks one. The judgment is the point, and automation should support it, not make the decision.
Each stage then hands off a defined input and output:
-
Selected idea and brief: The input is Richard’s chosen idea. The output is a brief covering the angle, audience, and outline. Richard approves it before drafting starts.
-
Article draft: The input is the approved brief plus the style rules. The output is a full article draft.
-
Feedback and revision: The input is the draft plus Richard’s feedback. The output is a revised draft. The rule is explicit: the draft moves forward only after the feedback has been addressed.
-
Final article decision: The input is the revised draft. The output is the approved final article. Richard decides what belongs in the piece and what gets cut.
-
Cover image: The input is the approved article and its visual direction. The output is a cover image that represents the article’s central idea.
-
Platform-specific social posts: The input is the approved article. The output is a separate post for each platform, adapted to that platform’s format, tone, and limits.
-
Carousel where appropriate: The input is the article and its key points. The output is a structured carousel when the topic is suited to that format.
-
Quality checks: The input is the image and copy assets. The output is a verified set of assets. The checks cover dimensions, layout, logo placement, formatting, links, and factual consistency.
-
Final approval: The input is everything ready to publish. The output is Richard’s sign-off. Nothing publishes without it.
-
Scheduled or published content: The input is the approved asset set. The output is the scheduled or published social content.
Ownership is named at every step. Richard owns the idea choice, the brief, the final article, and the final approval. Automation handles mechanical work such as formatting a caption, laying out a carousel slide, and preparing platform-specific versions.
The guardrail is simple: every stage ends in a gate, and the gates that matter are held by a person. The outcome is customer-facing, carries risk for the business, and a bad publish could create a serious problem.
Exceptions are planned too, and each one routes back to a person. If research comes back thin, the routine surfaces the short list and Richard decides whether to continue. If a draft misses the brief, it goes back for revision. If a generated image fails the checks, it is regenerated or replaced before approval.
No deviation is allowed to disappear silently. Every exception ends at a named owner.
Human-in-the-Loop Is a Design Choice
Treating “a human still has to check this” as a legitimate design decision, and it takes different forms depending on the stakes.
The rule is clear: a human should be in the loop whenever the outcome is customer-facing, presents significant risk such as financial risk, or could create a serious problem for the business.
The intervention might be an approve-or-reject gate, an edit instead of a binary decision, the resolution of a flagged exception, the addition of missing context, or a high-stakes decision the automation should never make alone.
Each intervention needs the same care as the automation itself. What does the person see? What decision are they being asked to make? How much context do they have? What happens after they respond?
Mapping and Building the Automation
Once a process clears the checklist, pin down the trigger, input and output formats, decision rules, guardrails, exceptions, ownership, and human checkpoint. Test it with real examples, including known exceptions, then monitor it after launch because processes can drift.
The Real First Project Is Process Discovery
The most valuable automation work is not usually building the bot. It is mapping what actually happens: agreeing on the trigger, naming the inputs, writing down the decision rules people apply informally, and deciding who owns the outcome.
Founders under pressure to “have an AI strategy” often skip straight to picking a tool. The better first move is slower: draw the process, find the gaps, then decide what is ready to hand to a machine.
The first automation project is usually process discovery and clarification, not bot building.