The hard part of agent work is not building the agent. It is choosing which workflow to point it at, and most of the expensive mistakes are made in that choice rather than in the code.
Teams tend to pick the workflow that is most annoying. That is a reasonable human instinct and a poor selection criterion — the most annoying workflow is often annoying precisely because it is full of judgement calls, exceptions, and undocumented context, which is exactly what makes it a bad first candidate.
Four properties do a better job of separating the good candidates from the ones that will consume a quarter and return nothing.
1. It runs often enough for the maths to work
A workflow that runs twice a month is rarely worth automating first, however painful each instance is. The build cost is roughly the same whether it runs twice a month or two hundred times a day, so frequency is what turns a fixed cost into a return.
The useful figure is not hours saved per run. It is hours saved per run multiplied by runs per month, set against the build and the ongoing cost of operating it. Workflows that clear that bar tend to be unglamorous: intake triage, status responses, reconciliation, first-pass document review.
2. The decision boundary can be written down
An agent needs to know what it is allowed to decide. If you cannot state the boundary in a sentence a new hire would understand, the agent cannot hold it either.
"Approve refunds under the stated limit where the order shows as delivered and the customer has no prior refund this quarter" is a boundary. "Use your judgement on refunds" is not. The second one is not a harder engineering problem; it is an unfinished policy decision, and building an agent will not finish it for you.
This is the property that most often disqualifies an appealing candidate, and finding that out during selection is much cheaper than finding it out during build.
3. Being wrong is recoverable
Ask what happens on the worst plausible bad output, then ask how long it takes to notice and how long to undo. A drafted reply that a person sends is recoverable. A payment released, a record deleted, a message already delivered to a customer is not.
Irrecoverable actions are not off limits forever — plenty end up automated. They should not be the first thing you automate, because your first agent is also how your organization learns what these systems get wrong, and you want that lesson to be cheap.
A useful filter
For your first workflow, prefer one where the agent proposes and a human commits. You keep the throughput gain and you learn the failure modes without paying for them.
4. Somebody can tell quickly whether the output is right
This is the property teams forget, and the one that determines whether you can improve the system after it ships.
If checking the agent takes nearly as long as doing the work, you have moved effort rather than removed it — and you have no practical way to evaluate a change, because every evaluation run is as expensive as the original task. Workflows with a fast correctness check compound: you can run evaluations, try a different approach, and know within an hour whether it was better.
Where a fast check does not exist naturally, it can sometimes be manufactured — a required citation, a structured field that must match a source system, a confidence threshold that routes anything uncertain to a person. If none of that is possible, treat it as a signal about sequencing rather than a problem to solve later.
What this rules out, and why that is fine
Applied honestly, these four properties disqualify most of the exciting ideas on a first pass. The workflow everyone wants to automate is usually high-judgement, low-frequency, hard to check and expensive to get wrong.
That is worth saying plainly rather than working around, because the alternative — starting with the exciting one — is how organizations end up concluding that agents do not work, when what actually happened is that they picked the hardest possible problem as their first.
A practical way to run the selection
List the candidate workflows. For each, write four short answers: how often it runs, what the agent is allowed to decide, what the worst recoverable outcome is, and how someone checks the result. Do not score them out of ten; the sentences are more useful than the numbers, because a vague sentence is itself the finding.
Two or three candidates will look obviously stronger than the rest. Start there, instrument before you change anything, and let the first one teach you what your second scoping conversation should ask about.
The candidate that looks perfect and is not
One shape comes up in almost every scoping conversation: the inbox. Every enquiry, from every channel, triaged and answered automatically. It scores well on frequency and the pain is obvious, which is why it gets proposed first.
It usually fails on the other three properties at once. The decision boundary is wide open, because "answer the customer" covers a refund request and a legal complaint equally. Being wrong is not recoverable, because the reply has already left. And checking is slow, because verifying a reply means reading the whole thread anyway.
The version that works splits it: classify and route automatically, draft the reply, let a person send. Same workflow, most of the throughput, and the three failing properties become passing ones. Narrowing the scope is usually a better move than making the agent smarter.
Where Focus20 fits
This selection work is what the audit produces: a prioritized set of workflows with an ROI estimate against each and a 90-day sequence. We build the ones that clear the bar, with the guardrails and evaluation in place from the start rather than retrofitted.