What will it cost to check the agent's work?

An AI agent can now take on multi-step work: read documents, use internal systems, fill in records and prepare a result. Before choosing what to hand over, it is worth asking a less visible question. When the work comes back, how long will it take someone to decide whether it can be used?

Our view is simple. Delegating a task to an agent saves effort only where the result can be checked in less time than it would take a person to do the work. Where checking costs as much as doing, the agent adds a step and blurs responsibility. So we would let the cost of checking decide which workflows go first, and design the check before building the agent.

Checking is part of the work

A delegated task ends with a decision: accept, correct or reject. Someone has to make it, and that person needs the time and the information to make it properly.

If the check is quick and reliable, delegation frees real capacity. If the reviewer has to redo the work to be confident, there are two bad options. They redo it, and nothing is saved. Or they approve without really looking, and the business ends up relying on work that nobody has examined.

This is why the speed of the agent says little on its own. The useful comparison is the effort to run the agent plus the time to check its output, against the time the work takes today.

Same agent, different economics

Consider a hypothetical manufacturer moving its product catalogue to a new ERP system. The technical data sits in spec sheets of different ages and formats. Two tasks look similar to an agent, because both start from the same documents.

The first task is to extract technical attributes into structured fields: dimensions, materials, operating ranges, certifications. Here the check can be designed to be fast. Each value can point to the page it came from. Simple rules can catch impossible values, wrong units and missing mandatory fields. Conflicts between two sheets for the same product go to the product manager. A member of the product data team compares a sample of products with the source by hand, and the sample is larger for the product families where an error would be costly.

The second task is to write new product descriptions for the website. Checking a description means reading it in full, knowing the product and judging whether each claim is accurate and appropriate. That can take almost as long as writing it. An agent can still help, for example by proposing a draft from the verified attributes. But the person remains the author, and delegating the whole task saves little.

The technology is the same in both cases. What differs is how much it costs to know whether the result is right.

Illustrative framework titled "Delegate where checking is cheaper than doing": a two-by-two grid with effort to do the work on the vertical axis and effort to check the result on the horizontal axis. High effort to do and low effort to check: delegate, the agent does the work and a person can check the result quickly. High effort to do and high effort to check: make it checkable first, add structure, reference cases and rules, or keep a person as the author. Low effort to do and low effort to check: little to gain, simple tools or existing features may be enough. Low effort to do and high effort to check: keep it with a person, checking would take longer than doing the work. — Illustrative framework: the cost of checking decides where delegation to an agent pays off.

Build the check before the agent

A quick and reliable check does not come with the agent. It has to be designed, and that design can take more effort than configuring the agent. In the product data example, it would include six elements.

A definition of an acceptable result, written by the person who owns it. For product data: which fields are mandatory, which tolerances apply, which source prevails when two disagree.

Reference cases with known answers. A set of products already verified by the team lets anyone compare the agent's output with the right result, before go-live and after every change.

Traceability. Every value links to its source, so the reviewer checks a pointer instead of repeating the search, and the system keeps a record of what was checked and by whom.

Automatic checks for trivial errors. Formats, ranges and consistency rules catch them before a person sees the output.

A route for exceptions. When sources conflict or the agent is uncertain, the case goes to a named person with the context needed to decide. The agent does not guess.

Sampling in proportion to risk. Review effort goes where an error would cause the most damage.

One consequence is worth knowing in advance. If nobody can write down what an acceptable result looks like, an agent will not solve that. It is more likely to make the gap visible, later and at a higher cost.

Illustrative example for a hypothetical manufacturer, titled "A check designed before the agent". Set beforehand by the data owner: what counts as acceptable, and reference cases with known answers. Step 1, the agent extracts: each value links to the page of the spec sheet it came from. Step 2, rules screen the output: units, ranges and mandatory fields are checked automatically. Step 3, exceptions go to a person: conflicting sources reach the product manager, with the context to decide. Step 4, a sample is reviewed: the product data team compares a sample with the source, more where errors cost more. Outcome, accepted, corrected or rejected: only values that pass the check enter the new system. — Illustrative example: in the product data case, much of the design effort goes into the check.

The strongest objection

The most valuable work is often the hardest to check. A criterion based on checking cost could push agents towards low-value tasks and leave the important work untouched.

We see two answers. First, checkability is not fixed. Part of the project can be to make valuable work easier to check: structuring the input, agreeing reference cases, separating what can be verified by rule from what needs judgment. Second, where that is not possible, an assisted workflow, where the agent drafts and a person remains the author, is a legitimate result, not a lack of ambition.

A related temptation is to check less as people get used to the agent. Reducing review should follow evidence from reference cases and samples, not familiarity. When the process, the data or the agent changes, that evidence needs to be renewed.

Questions to ask before the first agent

Before choosing which work to delegate, we would work through four questions with the people who will sign off the result.

Who decides whether the output is usable, and how long does that decision take today?

What can be checked by rules or by comparison with a source, and what needs a person?

Where does a case go when the agent is uncertain or the sources disagree, and who decides it?

What evidence would justify checking less, and what would make us check more again?

This is where we see agentic workflows and human oversight meet: the task, the evaluation and the route for exceptions are designed together, and tested in the real working environment with the people who will be accountable for the result.

Before asking whether an agent can do the work, ask how the business will know, quickly and reliably, that it was done right.