Use As Little AI As Possible: A Framework That Works

Here's the plot twist nobody saw coming: the most successful AI automation agency deliberately uses as little AI as possible.

Dave Ebbelaar runs an AI agency, markets himself as an AI expert, and charges clients to implement AI solutions. But when he actually builds automations, he avoids AI whenever he can get away with a simple if-else statement instead. And this counterintuitive approach is exactly why his projects actually work.

"Even though we market ourselves as an AI agency, we usually like to use as little AI as possible," Ebbelaar explains. The reason? Large language models are non-deterministic—powerful but unpredictable. A simple router or conditional rule does the same thing every single time. An LLM might surprise you.

This philosophy anchors a seven-step framework that Ebbelaar's agency uses to take clients from vague automation dreams to functioning systems. The framework matters because most businesses approach AI backwards—they lead with the sexiest solution instead of the actual problem.

Start Where Nobody's Watching

The first mistake companies make is wanting to automate their most visible, customer-facing processes. Put an AI chatbot on the website! Let AI handle customer service! This sounds impressive in a pitch deck and terrifying in practice.

Ebbelaar's framework starts with discovery, but not the kind where you nod along to whatever the client says they want. Real discovery means asking what people complain about, where manual errors keep happening, what tasks make employees want to throw their computers out windows.

"We've even had projects where we kind of like shadowed people for a day where we just like were on in the office like just walking around asking people like hey what are you doing," he says. Watching someone's actual screen reveals the quiet desperation of moving data between Google Sheets and Notion fourteen times a day.

These internal, low-stakes processes are where you start. Not because they're the most important, but because when AI inevitably does something weird, it fails in front of your team instead of your customers.

The Backlog Is Your Battle Plan

Discovery produces a backlog—a list of every automation idea anyone mentions. Then comes prioritization, which is where most frameworks get religious about ROI calculations.

Ebbelaar's approach considers three factors: impact, complexity, and what he calls "low-hanging fruit." Sometimes a task affects two people and saves five minutes a day—terrible ROI. But if you can automate it in five minutes with a no-code tool? Do it anyway. Quick wins build momentum and credibility.

The business case calculation looks at both time savings and error reduction. A process might not consume many hours, but if manual mistakes cost money or damage trust, that's your impact metric.

"What are people complaining about? What is the process where you say I don't like to do that? Where are people making mistakes?" Those complaints are gold because they point to actual pain, not theoretical efficiency gains.

Map What Actually Happens

Step three is where things get uncomfortable: mapping the as-is process. Not the process as it exists in the employee handbook, but what people actually do.

Ebbelaar recommends literally drawing it out—whiteboard, Figma, whatever works. The exercise reveals that documented processes are fiction. Real workflows include side pathways, exceptions, and workarounds that exist only in people's heads.

This matters because you cannot automate what you don't understand. And non-technical stakeholders often assume AI can just "figure it out" the way a human would. It can't. You need separate pathways for different data types and edge cases.

For anyone selling automation services, Ebbelaar suggests treating these first four steps—discovery through mapping the future state—as a standalone audit you can sell separately. There are too many unknowns to quote a full project price before you've done this work.

The Prototype Tells the Truth

After mapping what exists and designing what should exist, you build a prototype. Not the full system—a proof of concept that demonstrates the core functionality.

This is where you learn whether your assumptions hold up against real data. That elegant automation you designed might encounter data formats you didn't anticipate, or edge cases that represent 30% of actual volume.

The gap between 70% automation and 100% automation is enormous. "We don't get to 100% immediately. Usually, you start at 70, 80," Ebbelaar notes. That remaining 20-30% often requires as much work as the first 70%.

Safeguards Keep AI from Embarrassing You

Step six adds the unglamorous but critical layer: safeguards and controls. Because AI will eventually do something unexpected, and you need systems that catch problems before they reach customers or corrupt your data.

This might mean human review steps for high-stakes decisions, confidence thresholds that route uncertain cases to manual review, or fallback processes when AI components fail. Boring? Yes. Necessary? Absolutely.

The final step is launch and metrics—not vanity metrics about how much AI you deployed, but actual impact measurements. Did errors decrease? Did response time improve? Are employees actually using this, or working around it?

What This Actually Means

Ebbelaar's framework works because it refuses to treat AI as magic. It's a tool with specific capabilities and limitations, useful in particular contexts, and often inferior to simpler alternatives.

The companies that succeed with automation are the ones that start small, start internal, and start with the boring stuff. They build credibility through quick wins before tackling complex customer-facing systems. They map reality before designing solutions. They prototype before building. They add safeguards before launching.

And yes, they use as little AI as possible—which paradoxically makes their AI implementations more successful.

The question isn't whether your business should use AI. The question is whether you're willing to do the unsexy work of understanding your processes well enough to know where AI actually helps, and where a simple rule does the job better.

— Zara Chen, Tech & Politics Correspondent