AI agents in business: the problem isn't the model, it's who checks the work

The demo works. The P&L, not so much

If you run a company, you've probably seen this scene. Someone on the team shows you an AI agent that drafts a sales proposal in ten minutes. Everyone applauds. Three months later, nobody can quite say whether the company is earning more, saving anything, or just swapping some tasks for others.

It isn't bad luck, and it isn't a lack of technology. My thesis is different, and fair warning, it could turn out to be wrong: the value of AI agents depends less on how smart the model is than on how much it costs to check their work and how you organize the company around them.

I've written a long, fairly technical paper on this, with hypotheses, an experimental design and the rest. Here's the essence, without formulas (well, with one very small one).

The bottleneck moves

When an agent does the work, doing stops being the problem. The problem becomes twofold: explaining clearly what you want, and checking that what you got is right.

Take the sales proposal from the example. Yes, the agent writes it in ten minutes. But someone has to check the prices, the deadlines, the terms, and that it hasn't promised something the company can't deliver. And that someone often takes longer reviewing text they didn't write than they would have taken writing it.

If you don't reorganize that part, the gain you saw in the demo gets eaten by review, corrections and exceptions. The work doesn't disappear. It just moves to another desk.

The question almost nobody asks: what does checking cost?

I call this the verification ratio. It's simple: how much it costs to review and fix the agent's work, compared with what it used to cost to do the whole thing by hand.

• If checking costs almost as much as doing, delegating doesn't pay, however cheap the agent is.
• If checking is much cheaper than doing, delegating pays even with an imperfect agent.

This explains why AI got into coding with automated tests, or ticket classification, before it got into contract negotiation. It isn't that models are smarter at coding. It's that checking whether code passes its tests is cheap, and checking whether a contract is good is not.

Here's an example with made-up but realistic numbers. A company prepares 160 technical bid dossiers a year. Done by hand, each one costs about €1,110 including review and corrections. With an agent and a properly redesigned process, that drops to about €740: 34% less. But notice the detail: half of the original cost is still human work, completing, reviewing and fixing. The agent doesn't eliminate the work. It transforms it.

And be careful how you do the maths, because the same system can look like a success or a failure depending on how you spread the cost of setting it up:

That's why you should decide how you'll measure before you see the results. Otherwise you'll end up picking whichever calculation proves you right.

Redesign first, then delegate

The usual move is to take the existing process and drop an agent into the middle of it. My bet is that this yields small gains, and often none at all once you count everything.

What I propose instead is organizing work into missions. A mission is an assignment with everything nailed down: what result is expected, for whom, with what resources, by when, and above all, how we'll know it's been done right. That last point, the acceptance criterion, is what makes checking cheap.

Redesigning also means working to lower the verification ratio before you delegate. Turning criteria that lived in someone's head into automated checks. Asking the agent for structured outputs. Separating what can be checked by a rule from what genuinely needs human judgement.

And here's the part that could go wrong for me: if dropping the agent into the existing process turns out to work just as well as redesigning, this whole framework is unnecessary. You could simply buy tools and let each team use them however it likes. I've framed it this way on purpose, so it can be tested.

Your company needs an operating system

I've called the framework Agentic Company OS, and the name isn't just for show. An operating system solves a problem very similar to that of a company running agents: many processes compete for scarce resources, each has different permissions, and everything must keep running when one of them fails.

The analogy helps you see which pieces can't be missing: someone who allocates work between people and agents, limits on what each one can do, budgets for spending and time, a register of which agents exist and who answers for each, and a stop button that doesn't depend on the agent “obeying”.

But the most important conclusion is a different one. The scarce resource in a company with agents isn't compute, which is cheap. It's the attention of the people who check the work. If you launch more missions than your people can review carefully, review turns into a rubber stamp. And at that moment, without anyone having decided it, the agent is the one really in charge.

My practical rule: no new mission starts unless review hours have been set aside for it.

It's stricter than any technical limit, and it's the one that truly sets the pace of the transformation.

Trust is earned with numbers

How much freedom do you give an agent? My answer: it depends on each action, not on the agent. And it depends on two separate things that are best kept apart: how serious a mistake would be, and when a person steps in.

The same agent can classify tickets without anyone looking at each case and, at the same time, need your sign-off before replying to a customer. And some actions (payments, contracts, access changes, decisions about people) always need prior approval from someone other than whoever proposed them.

To give an agent more freedom, I want real evidence, not a nice demo:

• Volume. If you'll only tolerate one serious failure in a hundred, you need around 300 consecutive cases without a serious failure before relaxing oversight. Twenty good cases prove nothing.
• Consistency. Give it the same task five times, and it has to get it right all five. An agent that averages 90% but often fails when repeating the same task can't be trusted.
• Automatic rollback. If the model, the data or the tools change, the agent goes back under closer watch. Trust is earned with evidence and lost without needing an explanation.

One last idea, which I think is among the most important. Naming a person as “responsible” for what an agent does isn't enough. If that person can't stop it, has no time to review it or can't see what it did, they aren't responsible: they're the scapegoat for when something goes wrong. Responsibility only comes with authority, time and information. If any of the three is missing, the design is wrong.

It's not all about savings

If you only measure how much you save, you'll end up choosing the lowest-value missions. I believe the real value of agents lies in two other places.

Coverage. Work that used to go undone because it didn't pay: replying to every sales lead, not just the promising ones; reviewing every contract, not a sample; analysing every incident. There's nothing to compare against here, so you measure it differently. For example, you have the agent handle a randomly chosen half of the cases you used to drop, and compare what happens to sales in each half.

Speed. Sending a proposal in a day instead of a week can change who wins the customer. That isn't measured in hours saved, but in sales, margin or customers retained.

And a warning for the cautious, myself included: waiting has a cost too. While you evaluate one mission per quarter, a competitor may be learning to make its work verifiable across dozens of processes. I'm not saying you should jump without a net. I'm saying the pace should be set by your capacity to review, not by fear.

How to start tomorrow

You don't need a clinical trial to decide whether an agent is worth it. But you shouldn't trust the feeling that it “goes faster” either: in a METR study, experienced developers took longer using AI while believing they were faster. Here's a middle path, designed so a small business can follow it:

1. Pick a single mission where checking is much cheaper than doing, and where a mistake can be undone.
2. Appoint an owner who has the authority to stop it, hours set aside to review it, and access to everything the agent does.
3. Measure how you do it today, with at least 30 real cases. Without that baseline, you won't know whether you've improved.
4. Write down on one page, before you start, what counts as “done right”, how you'll calculate the cost, and what result would make you continue, change course or stop.
5. Run the agent in parallel, with no real-world effects, on the same cases your team handles. Have someone compare the two outputs without knowing which is which. With 30 to 50 paired cases, you can already make an informed decision.
6. Move to a real pilot with human approval for anything that has impact. Measure the full cost: review, corrections and integration included.
7. Decide, and write down why. If it doesn't work, going back to the old process is a good decision too, and what you've learned carries over to the next mission.

In a small business, a first cycle can take 6 to 8 weeks. In a large company, the security review, the data protection review and the ERP integration alone can take more than a quarter, so it's worth starting them on day one. And if your company operates in Europe, remember that the EU AI Act already requires training for the people who work with these systems.

What really decides who wins

Let me put it plainly: in the agentic company, the winner isn't whoever has the best model. Models can be bought, and tomorrow your competitor will have the same one you do. The winner is whoever knows how to make their work verifiable and organizes delegation around their people's attention.

That capability can't be bought or copied. It's built mission by mission: every acceptance criterion written down, every automated check and every well-designed review makes verification cheaper and widens what you can safely delegate. It's an asset that compounds, and it's what will separate the companies that transform how they work from those that merely change their tools.

So the question for your next leadership meeting isn't “which agent should we buy?”. It's this:

What work are we able to verify, and how much attention do we have to do it?

Start there. Everything else comes after.

Sources

• Becker, Rush, Barnes and Rein (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.
• Brynjolfsson, Li and Raymond (2025). Generative AI at Work. The Quarterly Journal of Economics, 140(2).
• Feng, McDonald and Zhang (2025). Levels of Autonomy for AI Agents.
• Raúl Nogales (2026). La transformación de la empresa en la era de la inteligencia artificial agéntica (The transformation of the company in the age of agentic AI). Position paper, version 2.0, in Spanish.

About Raúl

Raúl is the Founder and CEO of AVAP. He is a serial entrepreneur with 30+ years of experience building technology companies across Silicon Valley, Europe, the US, Africa, and Latin America. He previously founded Pademobile and HalCash, and is the driving force behind AVAP, a new technology for building and operating AI Systems.