What work is suitable for an AI agent?

Ask which work suits an AI agent and you will usually get the same answer. Repetitive. High volume. Clear rules. Digital inputs. A clear definition of done, with a person available for exceptions.

All of that is useful. It describes what an agent is capable of, which is different from what is worth handing over. A process can satisfy every item on that list and still have poor economics, or require more control than the benefit justifies.

The short answer is this. Work fits when it repeats often enough to measure, a correct result is economical to verify, mistakes are bounded or reversible, and a named person can handle the exceptions. Volume and clear rules establish feasibility. Verification cost and failure consequence decide whether handing the work over creates value.

01What does the usual advice get right?

Quite a lot. The usual list is a real filter and it removes many weak candidates. Work that arrives on paper, runs four times a year, or depends on rules nobody can explain is harder to hand over, and starting there makes an already uncertain build more expensive.

The limitation is that the list describes the input side. Is the work legible? Is there enough of it? Can the systems be reached? It does not ask what the work costs once an agent is doing it.

Two further questions decide that. What does it cost to check one result, and what happens if a wrong one gets through. Both can be investigated before anything is built.

02What does it cost to check the work?

If verifying a result costs what producing it cost, you have moved the work rather than removed it. The person who used to complete the task now reads someone else’s version, decides whether to trust it, and may redo the parts they cannot verify quickly.

Adjacent evidence from workplace AI shows how much apparent productivity can disappear into that work. Workday surveyed 3,200 full-time employees at organisations above $100 million in annual revenue, all active users of AI, in November 2025, and published the results in January 2026. Eighty-five percent reported saving between one and seven hours a week. Workday also reported:

Nearly 40% of AI time savings are lost to rework, including correcting errors, rewriting content, and verifying outputs. Workday · Beyond Productivity, January 2026

Only 14 percent of respondents consistently reported a clear positive net result. Among frequent users, 77 percent said they review AI-generated work at least as carefully as work done by a person.

That is a self-reported survey about workplace AI, not a measurement of production agents. It does not prove what verification will cost in any particular process. It does show why that cost belongs in the business case from the start.

A 2024 systematic review and meta-analysis of 106 experiments reached a related conclusion. On average, human and AI combinations performed worse than whichever of the two was better on its own. Where people outperformed the AI, combining them helped. Where the AI outperformed people, combining them hurt. The research did not study production agents, and it makes the same point from another direction: putting a person in the loop does not automatically make the result better.

Verification should therefore be treated as a standing operating cost until evidence supports reducing it. Better quality, deterministic checks, narrower sampling and earned autonomy can all change how much review is needed. Accuracy on its own does not remove accountability.

So the useful question is not whether checking disappears. It is what one check costs, who can perform it, and what evidence would justify checking less.

Same organisation, same systems, similar volume. Very different economics.

The test is whether a correct answer is cheap to recognise. Where it is, an agent can carry more work while a person stays across the result. Where it is not, the choice is between extensive review, a narrower scope, or a level of trust the consequence may not support.

03What happens when it is wrong?

The second question decides how much evidence the work needs before an agent may act with more autonomy. The starting point is not how capable the model appears. It is what breaks when the output is wrong.

This is not only a regulatory principle. NIST’s voluntary AI Risk Management Framework connects intended use, expected benefits, error costs, human oversight and ongoing measurement to the decision about whether a system should be deployed at all. The EU AI Act applies a related risk-based logic as law in defined cases, where obligations depend on intended purpose, the people affected, the role each party holds in the value chain, and risk classification. We wrote separately about the operating evidence behind that in showing what every agent did and who approved it.

Shift allocation shows why the detail matters. A system may fall within the Act’s high-risk employment categories when it makes decisions affecting work relationships, or allocates tasks based on individual behaviour or personal characteristics. That does not make every shift-planning tool high-risk automatically. Classification depends on its intended purpose, how it influences the decision, and the conditions in Article 6.

The Scan records the intended use, the data involved, the decisions the agent influences, the people affected and the role each party has. That is the technical and operational input for a classification made with the customer and its advisers, not a legal opinion of ours.

Our own operating controls can be stricter than the legal minimum. For work with higher consequences that may mean a longer shadow period, drafting-only autonomy, and named approvals before go-live. Those are operating decisions for a specific process rather than universal requirements.

None of this rules the process out. It makes the cost and the conditions of controlled use visible before the build decision.

04Where do the answers come from?

From the recorded process, and from focused conversations with the people who own it. A workshop on its own cannot establish how work actually runs. People describe the procedure they know, while the systems hold evidence of what happened case by case.

This is what the Scan does. We reconstruct the recorded process, score eight areas, and investigate the gaps with the people who own the work. The result is not an agent proposal by default. It is a gap list and a decision: build, prepare first, narrow the scope, or leave the work with people.

Where systems produce reasonably complete event logs with stable case identifiers, process mining can reconstruct how the work flows. It is an established discipline for discovering, monitoring and improving operational processes.

Four areas are mainly observed in the systems. Volume is a count. Systems touched is an inventory. Data access is tested by connecting with the approved permissions. Data quality is assessed by inspecting the records the agent would actually receive.

Procedure fit is also measurable when the logs are complete enough. Conformance checking compares the documented process with the order recorded in the log. If a documented step is regularly bypassed, that difference is visible before it becomes an agent failure.

The recorded process is evidence, not the blueprint. The Scan starts from the business outcome you want and then decides which responsibilities belong with people, with agents and with the systems already there. It does not automate the current process merely because that is what the log contains.

Cost of checking and review capacity begin with evidence and finish with people. Reopened cases, corrected entries and repeated steps show where rework already exists. Queue depth, backlog age and ownership show whether anyone can review the agent’s exceptions. The people doing the work explain what the record cannot.

Cost of a mistake is judgement from the start. Its effects usually land outside the system that recorded the case: a customer who did not return, a regulatory question, a correction sent by email.

The honest limitation is work that leaves no usable trace. A spreadsheet on a second screen, a message to a colleague, a copy-paste between systems that were never introduced. Some of it can be captured through observation or desktop evidence. The rest has to be discussed, and it is often where the most important exceptions sit.

That changes the conversation. Instead of asking someone to describe an entire process, the Scan can ask why a particular step is missing in four out of ten recorded cases. Evidence narrows the discussion to the exceptions and the decisions that actually matter.

05What does a real assessment look like?

Consider an illustrative claims-intake process. High volume, rules-based, digital inputs. It passes the usual suitability test comfortably.

The Scan finds three signals that conflict. Volume and system access score well. Procedure fit does not, because the recorded process regularly departs from the written one. Review capacity scores poorly too, because no owner has enough time to check the proposed output.

Read together, the signals say something the headline checklist cannot. The work is reachable and plentiful, the documented procedure no longer describes it, and there is no capacity to review the output. Building immediately would reproduce a process that has already changed, then give the results to somebody with no time to notice.

The useful outcome is the gap list. Update the procedure, then create review capacity or narrow the first agent role to the part one person can stay across. Both are manageable before the build and expensive to discover after go-live.

06Which work should you leave alone?

Some, and saying so is part of the job. It is also the part with money against it: about a quarter of McKinsey’s global fees now come from outcome-based pricing rather than time, according to Michael Birshan, one of its managing partners, speaking to Business Insider in November 2025. When the fee follows the build, an assessment that concludes do not build has to be worth paying for on its own, or it quietly stops being written. A scan that only returns yes is a quotation with extra steps. It has to stay useful when the answer is not yet, not at this scope, or do not build.

The clearest stop signals are these.

A correct answer is only recognisable by redoing the work. Research summaries, judgement calls with no reference to check against, anything where the reviewer would have to repeat the task to know it was right. The agent may produce a good result. The process cannot verify it economically.

Nobody has the capacity to review it. If the proposed reviewer is already at capacity, narrow the scope until review fits, or address the staffing first. Adding an agent to a queue nobody can supervise moves the bottleneck rather than clearing it.

The rules change faster than they can be maintained. Exceptions are normal. A process is different when its underlying policy moves every few weeks and nobody can state which version currently applies.

It runs too rarely to measure reliably. A process that fires a few times a month may never produce enough cases to establish a stable baseline, detect drift, or justify its own oversight. A person with a good checklist is often the cheaper answer.

The path is fully deterministic. If every step and branch can be specified in advance, ordinary workflow automation is likely to be cheaper and more reliable. An agent earns its place where some bounded interpretation or adaptation is genuinely required.

07What work is a good fit for an AI agent?

Work fits when a correct answer is economical to recognise, the consequence of a wrong one is bounded or reversible, there is enough volume to measure performance, and somebody has the capacity and the authority to handle exceptions. It also needs enough variation or judgement to justify an agent rather than ordinary automation.

Matching invoices to orders and receipts. Pulling structured fields out of documents into a system of record. First-line triage where the routing decision can be checked at a glance. The work is bounded, but not always identical.

Return to the claims intake. Two hundred cases a day and one team lead. Most cases are unambiguous in a way that person can confirm in seconds. Handing over that bounded part changes the arithmetic, and the lead can spend more time on the smaller group that is genuinely uncertain.

The work does not disappear. The exceptions always needed a person. They are also the part that received the least attention, because the same person was carrying the routine volume as well.

So the gain is not automatically a saving. It is capacity released from routine work, and it becomes value when a named owner uses it to improve throughput, service, judgement or an actual cost position. That conversion belongs in the business case, and it has to be measured after go-live.

The two questions are the ones to take away. Pick the process you were already considering. Ask how long it takes someone to know one result is right. Then ask what happens if a wrong one gets through. If either answer is unknown, that is the first finding.

Reading the recorded process needs approved access to the systems the work runs on. That is what the Scan is for, and where we start. But the two questions need no tooling at all. Ask them before you speak to a vendor and the business case will already be better grounded.

Suitability is not a property of the work alone. It is the work, the cost of verifying it, and the consequence of a mistake, held together. A suitable agent takes on measurable volume inside boundaries a person can still control.

Common questions