AI agent use cases: where they work and where they don't

Most lists of AI agent use cases are wish lists — every task an agent could conceivably touch, presented as if it works today. The useful version is narrower and honest: what agents are genuinely good at now, what they quietly fail, and the single property that predicts which bucket a task lands in.

The property that decides

Before the list, the rule that generates it. Agents work well when a task has all three of these:

• Clear success criteria — you can tell whether it worked.
• Reversible or gateable actions — mistakes are undoable, or stop for a human.
• Judgement over structured tools — the hard part is deciding, not perceiving.

Tasks with all three are ready now. Tasks missing one are where the failures live. Keep that in mind as you read — it’s more durable than any list, because the models keep improving and the property doesn’t move.

Where agents work today

Triage and routing. Sorting inbound email, tickets and requests by what they need. Clear criteria, reversible actions, pure judgement. This is the most reliable category and the worked example is worth reading in full.

Research and synthesis. Pulling from many sources into one answer. Reads are safe by nature, so the whole task is gateable trivially — the agent gathers, you decide what to do with it.

Scheduling coordination. Finding a slot across calendars and timezones, drafting the invite for you to send. The judgement is real; the one risky step — the send — is easy to gate.

Drafting. Replies, summaries, first passes at documents. The agent produces, a human approves. The reversibility is built in because nothing leaves without you.

Data movement between tools. Copying a decision from one system to another — a resolved ticket updating a CRM. When the systems have APIs, this is reliable, and where it’s fully deterministic it’s arguably better left to a workflow than an agent.

The pattern across all five: the agent does the judgement-heavy middle, and the irreversible end stays with a human or a gate.

Where they quietly fail

These are the ones that demo well and disappoint in production, which makes them more dangerous than the tasks that obviously don’t work.

Anything with no ground truth. “Is this the right strategic decision?” has no checkable answer, so the agent can’t know if it succeeded — and neither can your tests. Confident, unverifiable output is the worst failure mode because nothing flags it.

High-stakes irreversible actions with no gate. Moving money, deleting production data, sending to large lists. Not because an agent can’t perform them, but because “usually right” is the wrong bar when the downside is unrecoverable. These need a human on the irreversible step, always.

Tasks requiring real-world perception. If success depends on reading a screenshot, a scanned PDF or a photo, you’ve added a perception problem on top of the reasoning one, and perception is where confident-but-wrong is most common.

Long-horizon work with compounding errors. A fifty-step task where each step is 98% reliable finishes correctly around a third of the time. Break these into checkpointed stages with verification between them, or they degrade silently.

The honest middle

Between clearly-works and clearly-fails sits a large band of works with a human in the loop — which is most real deployments and not a failure.

Customer support that drafts and escalates rather than auto-resolving. Code changes an agent writes and a human reviews. Financial categorisation an agent proposes and a person confirms. In each, the agent removes the tedious 80% and a human owns the 20% that carries the risk. That division is the product, not a limitation of it.

How to evaluate a use case

Three questions, in order:

1. Can I tell if it worked? No clear answer means you can’t trust it and can’t test it. Stop here.
2. What’s the worst irreversible action, and can I gate it? If the worst case is unrecoverable and ungateable, don’t automate it end to end.
3. Is the hard part judgement or perception? Judgement over APIs is the sweet spot; perception of the messy world is where reliability drops.

A use case that passes all three is ready. One that fails the first isn’t an engineering problem you can solve with a better model — it’s a task that doesn’t fit the tool, and no amount of capability changes that.

See also: what an AI agent is and break-it-yourself in the demo.