Insights
Where AI belongs in a growing operations stack
Toni Atunrase
Where AI belongs in a growing operations stack
A practical framework for deciding whether a workflow needs automation, a better process, or a human decision layer before adding AI.
Every founder I work with eventually asks some version of the same question: "Should this be AI?"
It's usually the wrong question. Not because AI isn't useful — it's because "should this be AI" skips two steps that determine whether AI will actually help or just add another layer of complexity to something that was already broken.
The real question has three parts, in order:
- Is this a process problem?
- Is this a repetition problem?
- Is this a judgment problem?
Get the order wrong and you end up automating chaos, which just means you now produce chaos faster.
Start with the process, not the tool
If a workflow is inconsistent, undocumented, or lives entirely in someone's head, AI is not the fix. It's premature. You cannot automate a decision your team can't yet explain to a new hire.
I see this constantly with growing businesses: revenue is healthy, the team is capable, and the operations underneath are held together by tribal knowledge. The instinct is to reach for AI because it feels like progress. But layering AI onto an undefined process just automates the inconsistency — now it happens at scale, and it's harder to trace back to a root cause.
The test: if you can't write the current process down in ten clear steps, you don't have an AI problem. You have a documentation problem, and it needs to be solved first, by a human, before any tool touches it.
Then look for repetition
Once a process is actually defined, the next question is whether it's repetitive enough to be worth automating. This is where most of the real, boring, high-leverage AI wins live — not in flashy use cases, but in the volume work nobody wants to keep doing by hand.
Signs a workflow belongs here:
- It happens the same way, dozens or hundreds of times a month
- The inputs vary, but the logic doesn't
- A trained person could do it correctly, but doing it correctly a hundred times a week is where the fatigue and errors creep in
Customer intake, first-response triage, scheduling, follow-up sequences, data entry between systems that don't talk to each other — this is the layer where automation earns its keep quietly and consistently. It's rarely glamorous. It's also usually where the ROI is clearest, because you can measure hours reclaimed and errors reduced directly.
This is also the layer most consultants oversell and undersize. Automation here should feel unremarkable once it's running. If it's not, the process underneath it still wasn't solid.
Protect the judgment layer
The third category is the one businesses get wrong most often in both directions: either they try to automate judgment that shouldn't be automated, or they leave a human doing repetitive work that was never actually a judgment call to begin with.
Judgment work looks like:
- Decisions with real consequences that shift based on relationship, context, or nuance a system can't fully see
- Situations where the "right" answer depends on values, not just data
- Anything where being wrong is expensive in a way that's hard to reverse
This is where a human decision layer stays — not because AI can't produce an output, but because the cost of a confidently wrong output is higher than the cost of a slower right one. Client negotiations, hiring decisions, pricing exceptions, anything touching reputation or trust — these stay human, with AI in a supporting role at most: surfacing information, drafting options, flagging patterns. Not deciding.
The businesses that get this right treat judgment as a layer to be protected, not automated away. The ones that get it wrong usually find out through a client complaint, not a dashboard.
Putting the framework to work
In practice, most operations stacks are a mix of all three, tangled together. A single customer journey might touch an undefined process, a repetitive task, and a judgment call within the same ten minutes. The work isn't picking one category for the whole business — it's mapping each workflow individually and being honest about which bucket it's actually in.
A short version of how I run this with clients:
- List the workflow's actual steps, as they happen today, not as they're supposed to happen.
- Flag the step where a decision changes based on context — that's your judgment layer. Ring-fence it.
- Look at what remains. If it's inconsistent, fix the process first. If it's consistent and repetitive, that's your automation candidate.
- Build the automation to hand off cleanly to the human layer, not replace it — the two should feel like one workflow, not a tool and a person working around each other.
This ordering matters because it's the difference between AI that compounds your operation's strengths and AI that just moves the mess around faster. I build these systems for a living, and the businesses that get the most value from AI aren't the ones with the most automation — they're the ones who were disciplined about deciding where it didn't belong.
If you're not sure which bucket a workflow falls into, that uncertainty is usually the tell that it hasn't been mapped yet. That's the starting point, before any tool gets chosen.