Most companies do not struggle to find AI agent ideas. They struggle to pick one. A workshop produces thirty candidates, each with an enthusiastic sponsor, and the choice is made by whoever argues best. The result is often a first agent that is either too trivial to teach anything or too risky to survive its first mistake.
This article is for the manager who has to choose the first process. It is deliberately narrow. It does not cover how to run the pilot itself, how to measure the benefit, or how to build the controls. For those, see staged rollout and rollback criteria, measuring whether agents really save work, and human approval and audit trails. The question here comes earlier: of everything you could automate, what should go first?
Why the first choice matters more than the second
The first agent is not only a piece of automation. It is the first time your company learns how an agent behaves in your systems, with your data, under your reviewers. It also decides whether the next request for budget is easy or hard. A first deployment that visibly goes wrong, even a small way, tends to freeze the programme for months. A first deployment that works but touches nothing important teaches little.
So the goal of the first choice is a process that is useful enough to matter, bounded enough to control, and reversible enough to forgive mistakes.
Four questions that separate good candidates from bad ones
Take each candidate and answer four questions in plain language. Avoid scoring systems with decimals; a rough low, medium, or high is enough.
1. Is the value real and owned?
Value means a recurring task that people already do, that takes noticeable time, and that someone is accountable for. Ask who owns the process today and whether that person wants the help. A process with a willing owner who understands the work will produce better instructions, better test cases, and faster feedback than one chosen because it looks good on a slide.
Be wary of value that only exists in aggregate. "Everyone spends ten minutes a day on this" sounds large, but it is hard to capture and hard to measure. A task with a clear unit of work, such as a ticket, an invoice, or a report section, is easier to evaluate later.
2. What is the cost of a wrong action?
Agents differ from chat assistants because they act. They update records, send messages, and trigger other systems. So the useful question is not whether the agent can be wrong, because it can, but what a wrong action costs.
Sort candidate actions roughly like this:
- Read and summarise. The agent reads information and produces a draft for a person. A mistake costs a reviewer's time.
- Prepare and propose. The agent fills a form or drafts a reply, and a person approves it. A mistake is usually caught, but only if reviewers actually look.
- Act inside your own systems. The agent changes internal records. A mistake can spread quietly before anyone notices.
- Act outside. The agent contacts customers, moves money, or changes access. A mistake is visible to people who cannot be asked to ignore it.
For a first agent, the first two categories are the sensible range. If a candidate only makes sense at the third or fourth level, it is probably a second or third project. Security guidance for language-model applications, such as the OWASP Top 10 for LLM applications, treats excessive agency as its own risk category for exactly this reason: the more an agent is allowed to do, the more a single bad instruction or manipulated input can cost. See also prompt injection controls for AI agents.
3. Can you undo it?
Reversibility is the most underrated factor. Two processes with the same value and the same chance of error are very different if one can be corrected in a minute and the other cannot.
Ask three things. Can the agent's output be held back before it takes effect? Can changes be rolled back from a log or a backup? If something does reach a customer, can you correct it without a legal or financial consequence? A drafted internal summary scores well on all three. A sent contract amendment does not.
This is the practical meaning of a cautious first choice. You are not avoiding risk altogether. You are choosing a place where the failures are cheap and easy to see.
4. Is the data ready?
An agent is only as dependable as the information it can reach. Check whether the inputs are in one place, whether people agree on what they mean, and whether the agent may legally and contractually use them. A process that relies on knowledge held in one person's head, or on documents that contradict each other, will make the agent look unreliable when the real problem is the source material.
Data readiness is also where many projects quietly fail before the agent is involved. If you are unsure, read AI agent data handling and retention before committing, and treat unclear data rights as a reason to pick another candidate rather than a detail to settle later.
Putting the candidates side by side
Build a simple table with one row per candidate and the four questions as columns. Fill each cell with low, medium, or high and one sentence of reasoning. Two patterns usually appear.
- The attractive but dangerous candidate. High value, but wrong actions are costly and hard to undo. Park it, and note what controls would be needed before it becomes possible.
- The boring but strong candidate. Moderate value, low cost of error, easy to reverse, with a clear owner and tidy data. This is usually the right first choice.
If two candidates tie, prefer the one where a mistake becomes visible sooner. Fast feedback is worth more than a slightly larger saving, because it shortens the time between a bad behaviour and the fix.
Check the pilot can be judged
Before you commit, confirm that you could tell whether the first agent succeeded. That requires a unit of work you can count, a baseline of how the process runs today, and a person who will compare the two. If you cannot describe the measurement in a few sentences, the process is not yet ready, however promising it looks. Our guide on choosing a first use case covers the general version of this step.
Decide the stop condition now
Write down, before launch, what would make you pause or stop. Examples are an error rate above an agreed level, a single incident of the agent acting outside its permissions, or reviewers spending more time on corrections than the old process took. Name who decides, and make sure that person has the authority to stop it without a committee. The NIST AI Risk Management Framework describes this kind of ongoing governance and accountability as part of managing AI risk, not as an afterthought.
A short checklist
- One named process owner who wants the help
- A countable unit of work and a baseline
- Actions limited to reading, summarising, or proposing for human approval
- Output that can be held back or rolled back
- Inputs you are allowed to use and can trust
- A written stop condition and a person who can invoke it
If a candidate meets most of these, it is a good first agent. If it meets few, it may still be a good project later, but it is not where to start.
