How to choose the first process for an AI agent

You have a list of tasks that could go to an AI agent and need to pick the one to try first. Pick a process that runs often, follows rules people can explain, uses data you can already reach, and where a wrong step is cheap to catch and undo. Score a few candidates on those four points, run the winner in a mode where the agent proposes and a person approves, and compare the results with how the work is done today.

Why the first process matters more than the model

Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. The same release notes that “many use cases positioned as agentic today don’t require agentic implementations.”

In our experience the model is rarely the reason a first project stalls. What stalls it is a process nobody can describe step by step, data spread across an ERP, a shared mailbox and a few spreadsheets, or a task where one mistake costs more than a month of saved time.

So decide on the process first. Tools come later.

Step by step: choosing the first process

Collect 5-10 candidates from the people who do the work. Ask team leads which tasks their people repeat every day and which ones they would hand off tomorrow. Typical answers: sorting incoming documents, matching invoices to orders, answering repeat questions from customers or the field team, building a weekly report from several systems.
Write each candidate down as steps. Note what triggers it, which systems it touches, which decisions a person makes and what comes out at the end. If nobody can write the steps down, the process is not ready for automation of any kind.
Check whether it needs an agent at all. Anthropic’s engineering team separates workflows, where code follows predefined paths, from agents, which direct their own steps and tool use, and recommends the simplest solution that works. If the path is always the same, a script or a fixed workflow with one model call is cheaper and easier to test. An agent earns its place when the steps change from case to case.
Score each candidate from 1 to 5 on four points.

Criterion	What a high score means
Volume	It happens many times a week, so small time savings add up
Data access	The inputs are digital and reachable through an API, a database or an export
Clear rules	A new employee could learn the decision rules in a day
Reversibility	A wrong step is caught before it reaches a customer and can be undone

Drop anything with a 1 on reversibility, then take the highest total. A process that scores well on the other three but cannot be undone belongs in a later phase.
Set the boundaries before you build. Decide which systems the agent may read, which it may write to, and which actions always wait for a person. OWASP lists Excessive Agency among the top risks for LLM applications: too much functionality, too many permissions or too much autonomy. The fix is ordinary engineering. Give read-only access where you can, keep each tool narrow, and require a person’s approval for high-impact actions.
Measure the current process. Count how many cases arrive per week, how long one takes and how often it goes wrong. Without this baseline you cannot tell whether the agent helps.
Run one case on real data. Start in proposal mode: the agent prepares the result, a person accepts or corrects it, and every correction is logged. After a few weeks the log shows where the agent is reliable and where it still needs a person.

An illustrative example

Picture a mid-sized manufacturer whose purchasing team receives supplier order confirmations by email, as PDFs in different layouts. Someone opens each one, compares quantities, prices and dates with the purchase order in the ERP, and flags the differences.

This one scores well on all four points. Dozens of documents arrive every week, the purchase orders are already in the ERP, the comparison rules are clear, and nothing changes until a person acts on a flagged difference. The agent reads the confirmation, pulls the matching order and writes a short note, for example “line 3: 400 ordered, 350 confirmed”. It has read access to the ERP and no right to change an order.

Now compare it with “let the agent agree delivery dates with suppliers”. Same team, same data, but a wrong message goes straight to a business partner and cannot be taken back. That makes it a poor first process.

Common mistakes

Starting with the most impressive demo. A customer-facing chat that can issue refunds looks great in a presentation and carries the most risk. Start inside the company.
Choosing a process with no owner. Someone on the business side has to review the output and decide what “correct” means.
Giving the agent a service account with full access. Use the narrowest permissions that work, ideally in the context of the user the agent acts for.
Skipping the baseline. “It feels faster” will not survive the first budget review.
Automating a broken process. If everyone does the task differently, fix the process first. Sometimes a shared form or one integration removes most of the work without any AI.
Ignoring the data layer. An agent that searches documents inherits every problem those documents have. Our guide on preparing company documents for private AI search covers that part.

Next step

This week, take your list of candidates, score them on the four points and pick one. If the winning process lives in older systems, our story about modernising a legacy platform without stopping the business shows how we connect new parts to old ones step by step.

If you want a second pair of eyes on your list, talk to Rebels Software. We build custom platforms, applications, private AI and AI agents, and every project starts with a Discovery workshop: one or two days with your team to map the process and the data behind it, and to choose one case. We test that case as a PoC on your real data, deploy it into your systems if it works, and keep it running under Rebels Care. Book a call on this page and bring your shortlist.