AI agents for business: choosing your first task to automate
Neaptide · September 6, 2026 · 9 min read · Updated: October 4, 2026
Choose a first AI agent task, test failures and calculate the value after human review. Includes original diagrams, a calculator and a pilot log.
On this page

Choose a recurring task with accessible source data and an output someone can reliably check. Keep the first AI agent pilot narrow: gather information or prepare a draft, then measure the work left for a person. A fast model response does not, by itself, make the process worthwhile.
Consider a manager handling workshop enquiries. One message includes a date and a group size; another says only “we’d like to bring the team”. Copying fields is easy. Working out what is missing, finding the relevant terms and drafting a useful question takes judgment. That small stretch of work is a plausible pilot candidate.
Do you need an agent, a workflow or a simple integration?
An AI agent uses a model to choose its next steps and call tools in pursuit of a goal. Definitions vary, so agree up front how much freedom the system gets: a fixed route, or its own decisions about what to investigate next. Anthropic distinguishes predefined workflows from agents that dynamically direct their own work.
| Task | A sensible starting point |
|---|---|
| Copy the group size from a form into a table | A conventional integration with known fields |
| Extract a date from free text and prepare a draft | A fixed workflow with a model call and field validation |
| Investigate an unusual request across several sources | A bounded agent that chooses lookups and identifies missing information |
Compare the pilot with the simplest useful alternative, such as a better form and a response template. If the only comparison is fully manual work, a cheaper solution can go unnoticed.
Find the task by watching someone do it
Walk through recent enquiries with the person handling them. Ask where they copy information, make a decision or discover that a fact is missing. A real record gives you a firmer brief than “automate sales”.
- The task recurs often enough to collect examples and observe a meaningful change.
- There is an authoritative, current source, and access can be limited to what the task requires.
- Someone can tell a correct answer from a plausible one without repeating the whole job.
- A wrong draft can be corrected before a message, payment or record change takes effect.
- A named person reviews the output and handles exceptions.
If five documents disagree about the price, resolve that first. A stronger model cannot know which price your manager approved unless the approval is recorded. Cleaning up the source material may turn out to be the most useful part of preparation.
Example: drafting a reply for a workshop
We use Forma, the fictional pottery studio from our website guide. What follows is a proposed process. Nothing here has been deployed, and there are no client results behind it.

The system extracts the request, checks approved terms and prepares a draft with source references. Missing dates trigger a clarification question. A class timetable says nothing about available places. For that you need a separate, current source.
| Input | Expected result | Failure |
|---|---|---|
| A group of six, no date | Draft a question about the date | Invent a date |
| Conflicting prices with no authoritative version | Flag the conflict for the owner | Pick a price without explanation |
| A group larger than the limit | Mark an exception for review | Promise to accommodate everyone |
| The source is unavailable | Identify what could not be checked | Guess the terms |
Start with read access and a separate draft destination. If you later allow sending, approval should cover the exact recipient and text. A retry after an interruption must not quietly send a duplicate.
Test the pilot before involving customers
- Measure the existing process, separating active work from waiting for the customer. Include corrections.
- Collect routine cases and exceptions. Write expected outcomes and forbidden actions in advance.
- Use some cases to improve instructions and hold others back for evaluation.
- Run without sending customer messages. Record system version, output and review time.
- Count every attempt, including failures completed manually.
- Decide whether to expand, narrow the task, fix the data or stop.
A single accuracy percentage conceals very different mistakes. A clumsy greeting and an invented price need different responses. Track unsupported terms, missed clarifications and actions beyond permission separately. Add targeted tests for rare, serious failures. Not seeing one in a small sample does not show that it is unlikely.
Before testing, agree what would justify continuing. Every draft must be reviewed, unconfirmed prices must not reach customers, average human work should fall and the team must be able to handle the exceptions. Set thresholds for your own process. No success rate or sample size fits every pilot.
What real studies show, and how to measure your result
Generative AI at Work studies 5,172 support agents and reports an average 15% increase in issues resolved per hour with AI assistance. This measures a particular workflow, not agent autonomy or the payback of every implementation.
| Source | Sample | Measured outcome |
|---|---|---|
| Generative AI at Work | 5,172 support agents | Issues resolved per hour: +15% on average |
| METR, early 2025 | 16 developers, 246 tasks | Completion time with AI: +19% |
- Generative AI at Work — authors / Stanford
- METR — randomized study, 2025
- METR — limitations of the follow-up, 2026
METR randomly assigned real tasks to conditions allowing or disallowing AI. Participants were experienced developers working in familiar repositories with early-2025 tools. In its 24 February 2026 update, METR warns that participant selection biases the new sample and prevents a reliable estimate of the current speedup.
Do not average the support and development results or transfer them to your workshop. They show why completed work needs measuring. Neither supplies your review time, employee rate or project budget.
Hours freed = volume × (minutes before − minutes after) / 60.
Net time valuation = hours × your rate − recurring costs.
Payback = setup costs / positive monthly benefit.| Input | Evidence |
|---|---|
| Volume and minutes before/after | Real task log, including failures |
| Hourly rate | Agreed internal valuation |
| API and maintenance | Invoices and recorded work |
| Setup costs | Quote or implementation records |
The calculator remains a teaching tool; its initial values are not measurements. Enter your own data. Released hours are not cash savings until you identify expenses that fall or additional work the team can complete.
What to bring to a developer
Prepare a one-page brief naming the person responsible, the information the system will receive, the approved sources and the expected output. Explain what should happen when information is missing and which actions the system must never take. Add examples with identifying details removed, current task timings and a maximum budget for the trial.
Repeat the evaluation after changing the model, instructions or sources, and keep measuring rework. What the first pilot owes you is a next decision you can defend. If it shows that a simpler form and templates work better, that is a useful result.