Overview

Every operations leader we talk to is under pressure to "do something with AI agents." Very few are short on ideas. Most have a list of ten, twenty, sometimes fifty candidate processes that could theoretically be automated. The problem is rarely a shortage of ideas. It's a shortage of judgment about which ideas are actually worth building first.

Pick the wrong use case and you get a technically impressive demo that never survives contact with production, a maintenance burden nobody budgeted for, or worse, a quietly abandoned pilot that makes the next AI proposal harder to get approved. Pick the right one and you get a case for expansion that funds the next three projects.

We use a simple three-filter test to separate the two outcomes before a single line of code gets written.

The Three-Filter Test: Volume, Variance, Verifiability

A candidate process clears the bar for a first AI agent build only if it scores well on all three of the following, not just one or two.

• Volume: does this happen often enough that automating it actually moves a metric? A process that runs twice a month isn't worth agent infrastructure, no matter how annoying it is. A process that runs two hundred times a day is worth serious investment even if each instance is only moderately painful.
• Variance: is the work varied enough that simple rules-based automation keeps breaking, but structured enough that a model can learn the pattern? Pure rote, identical-every-time tasks are often cheaper to solve with plain scripting. Pure judgment calls with no learnable pattern aren't ready for an agent yet. The sweet spot is in between: enough variation that if-then logic keeps failing, enough structure that historical examples actually teach a model something.
• Verifiability: can you tell, cheaply and quickly, whether the agent got a given instance right or wrong? If verifying the output takes as long as doing the task manually, you haven't saved anyone time, you've just moved the work. If you can spot-check or auto-validate outputs at low cost, you can run the agent at scale with confidence and catch drift before it does damage.

Processes that fail volume aren't worth the build cost. Processes that fail variance either don't need an agent or aren't ready for one. Processes that fail verifiability are dangerous to automate regardless of how good the model looks in testing, because you won't know when it starts quietly getting things wrong.

Where This Filter Catches Teams Off Guard

The most common mistake we see is choosing a use case because it's the most visible or most complained-about process, not because it clears the three filters. A process that's painful to a handful of senior people but happens rarely will generate enthusiasm in a planning meeting and then stall in development, because there's no volume to justify the investment and not enough historical examples to train against.

The second most common mistake is choosing a process with high volume and high variance but low verifiability, usually something involving nuanced judgment calls like tone-sensitive customer communication or ambiguous classification decisions. These look automatable because they're repetitive, but without a fast way to check correctness, teams end up manually reviewing every output anyway, which defeats the purpose.

A Worked Example

Consider two candidate processes at a typical mid-size operations team: reviewing inbound support tickets to route them to the right department, and drafting personalized win-back emails for churned customers.

Ticket routing usually scores well on all three filters. It happens constantly (volume), the language and context vary enough that static keyword rules keep failing (variance), and you can verify correctness quickly by checking whether the ticket landed with the right team, often automatically from downstream data (verifiability). This is a strong first build.

Win-back email drafting looks appealing but often fails verifiability in practice. Volume might be there, variance is certainly there, but judging whether a given email draft is "good" requires a human to actually read and evaluate tone, and there's no fast proxy signal for correctness until weeks later when you see whether the customer returned. That doesn't mean it's a bad candidate forever, it means it belongs later in the roadmap, after you have infrastructure and confidence from an earlier win.

Why This Matters

The organizations that build durable AI agent programs, not just impressive demos, are the ones that treat use case selection as seriously as they treat the engineering itself. A mediocre model applied to the right process will outperform a brilliant model applied to the wrong one, because the right process gives you enough signal, fast enough, to actually improve the system over time.

Start with something that clears all three filters, even if it feels less ambitious than the process everyone complains about in meetings. The credibility and infrastructure you build from a clean first win is what makes the harder, higher-variance, lower-verifiability processes tractable later.