How to choose your first AI agent use case

METR's published benchmark file shows Claude Opus 4.6, released on 5 February 2026, completing tasks that take a human around 12 hours — at 50% reliability. Raise the bar to 80% reliability and the same model's horizon collapses to roughly 70 minutes. That ratio explains more failed agent programmes than any architecture decision, and it is why how to choose your first AI agent use case is a scoping problem long before it is an engineering one.

Most first deployments do not fail because the model was not capable enough. They fail because someone selected a process that was too rare, too variable, never measured, or wired directly into something expensive to break. Selection is the control you have.

Why first AI agent deployments fail on selection rather than technology

The reliability gap above is not a quirk of one model. Across METR's current results, the pattern holds for every frontier system in the file: Gemini 3.1 Pro reaches 384 minutes at 50% success but 90 minutes at 80%, and GPT-5.2 reaches 352 minutes at 50% against 66 minutes at 80% (METR-Horizon-v1.1, models released between December 2025 and February 2026). At the reliability an enterprise process actually requires, usable task length is four to ten times shorter than the headline figure.

This has one direct consequence. A first deployment must be built from work that decomposes into short, repeatable steps with a checkable result — not a multi-day chain where one silent error propagates for a week. Choose a process whose unit of work is long and idiosyncratic and you are not testing your vendor; you are testing the least reliable regime the technology currently has.

The governance picture reinforces it. Deloitte's State of AI in the Enterprise (3,235 respondents across 24 countries, published January 2026) found that only 21% of respondents say their organisation has a mature governance model in place for agentic AI. A first use case is therefore also the rehearsal for controls that mostly do not exist yet — another argument for keeping the first one small. It is worth separating this from the folklore about pilot failure rates, which is more often misquoted than measured.

How to choose your first AI agent use case: the four properties that predict success

A viable first use case has four properties. Each maps to a specific failure mode.

• High volume. Without enough instances you cannot detect a change in performance or recover the integration cost, and the pilot ends in an argument about anecdotes.
• Low variance. Instances must resemble each other. Variance is what converts a 12-hour headline capability into a 70-minute practical one, because every unfamiliar edge case is a fresh opportunity to fail confidently.
• A number you already measure. The baseline must exist in your system of record before the agent arrives. A metric invented for the pilot will always flatter the pilot.
• A contained blast radius. Every action reversible, logged, attributable, capped, and stoppable by a named person. The UK's National Cyber Security Centre puts the test plainly in its agentic AI guidance of 15 May 2026: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."

An AI use case prioritisation framework you can run in a workshop

Score each candidate 1–5 against the four criteria, apply the weights, and sum. Done properly, AI agent pilot scoping is ninety minutes with the right six people in the room: the process owner, the person who reports the metric, an engineer who knows the integration, risk, and two people who actually do the work.

Criterion	Weight	Score 1–2	Score 3	Score 4–5
Volume and frequency	25%	Under 200 instances a month, or seasonal spikes only	200–2,000 a month, steady	Over 2,000 a month, every working day
Low variance between instances	30%	Every case materially different; judgement nobody has written down	A documented path covering roughly half of cases	One documented path covers 80%+ of instances; exceptions named and few
A number you already measure	25%	No baseline; success would be described as "faster" or "better"	A number exists but is monthly and nobody trusts it	Metric already in a system of record, reported weekly, owned by a named person
Contained blast radius	20%	Irreversible, or regulator-reportable on a single error	Reversible within a day; internal; small financial exposure	Reversible in minutes, capped exposure, every action logged, documented stop

Thresholds: 4.0 and above, build it. 3.0–3.9, re-scope and re-score — usually by narrowing the slice, not by arguing the score. Below 3.0, reject.

One veto rule. A score of 1 or 2 on blast radius stops the candidate regardless of total. Volume cannot buy back containment, and a high aggregate score on a use case that cannot be unwound is precisely how good rubrics produce bad decisions.

A worked score

Take payment-status enquiries in a retail bank's contact centre. Volume 5 (well over 2,000 a month, daily); variance 4 (one documented path covers most contacts, four named exceptions); baseline 5 (average handling time and first-contact resolution already reported weekly from the telephony platform); blast radius 4 (read-only against core banking, drafts held for release, full audit trail, a stop switch in the ops team's hands).

That gives (5 × 0.25) + (4 × 0.30) + (5 × 0.25) + (4 × 0.20) = 1.25 + 1.20 + 1.25 + 0.80 = 4.50. Build it.

Now score mortgage affordability assessment at the same bank. Volume 3, variance 1, baseline 3, blast radius 1 — total 2.00, and vetoed anyway. Same institution, same technology, same week. One is a first deployment; the other is a second-year project.

Which process to automate with AI agents: worked candidates across five sectors

• Banking. Strong: payment-status and transaction-dispute triage, standing-order amendments, KYC document completeness checks. Weak first: credit decisioning, suitability advice, sanctions adjudication.
• Healthcare. Strong: appointment rescheduling and waiting-list validation, prior-authorisation document assembly, coding-query triage. Weak first: anything touching clinical triage or diagnosis.
• Retail. Strong: order-status and delivery-exception handling, returns eligibility, supplier invoice-to-purchase-order matching. Weak first: dynamic pricing and markdown decisions.
• Telecom. Strong: plan and add-on changes on a fixed catalogue, first-line billing dispute triage, fault-ticket enrichment before dispatch. Weak first: network configuration changes and outage remediation.
• HR. Strong: policy and benefits enquiries against a maintained handbook, onboarding task orchestration, absence and payroll query triage. Weak first: CV screening and shortlisting, and anything feeding performance or termination decisions.

The pattern across all five is identical: high-frequency, well-documented, reversible work sitting immediately next to the consequential decision, not on top of it.

Use cases that make terrible first AI agent projects — and exactly why

• Anything a regulator adjudicates on a single error. Credit decisions, clinical triage, suitability advice. Fails the veto outright.
• The "AI assistant for everything". Unbounded scope, no baseline, no definition of done. Maximum variance by construction.
• Fraud and AML alert adjudication. Volume scores 5, which is exactly the trap. Catastrophic blast radius and an adversary who adapts to your agent.
• Processes that live in three people's heads. Undocumented means unevaluable: you cannot grade output against a standard nobody has written.
• Multi-day, many-handoff workflows. Directly contradicted by the METR reliability data above. One silent error propagates for a week before anyone sees it.
• Net-new processes that do not exist yet. No volume history, no baseline, no comparison. You will be measuring the agent against a guess.
• Anything whose only metric is satisfaction or "time saved". Both are reconstructable after the fact to suit whichever conclusion the room prefers.

What a 90-day first AI agent deployment should actually produce

Ninety days is enough for a defensible decision, not for a transformation. Structure it in four blocks, consistent with the NCSC's advice to "deploy agentic AI incrementally, starting with tightly bounded pilots using clearly defined tasks, and build confidence in the system before you expand the scope."

• Days 0–15 — instrument the baseline. Capture the number from the client's own system of record, signed off by whoever owns it. Nothing from a vendor dashboard.
• Days 16–45 — shadow mode. The agent proposes, a human decides, no customer sees output. This produces your real accuracy rate against human decisions on live traffic.
• Days 46–75 — supervised live on a capped slice. A named percentage of volume, a spend or exposure cap, and a stop that one person can pull without a change request.
• Days 76–90 — the decision. Expand, re-scope or stop, against the number agreed on day one.

The deliverables at day 90 should be: the pre-deployment baseline; the proportion of volume completed end to end with no human touch; the escalation rate and the reversal rate (deflection alone is not a result); a containment specification stating what the agent may touch, what it may not, and who stops it; a fully loaded cost per completed outcome; and a written expand/re-scope/stop recommendation. Price that cost per outcome honestly — the review, maintenance and retry lines are what decides year two, and they are routinely missing from a day-90 business case.

If a first deployment cannot produce those six artefacts in ninety days, the use case was the problem, not the timeline.

Braivex deploys agents into the systems clients already run, and prices on outcomes rather than seats — which makes use case selection our problem as much as yours. If you want a second opinion on the candidates on your shortlist, or the rubric above run against them properly, get in touch.