AI agents for business, judged on the work they finish

Most businesses do not need an agent that can do anything. They need one process handled properly, every time, including at two in the morning and including the week everybody is on holiday. That is a much smaller ask than the demos suggest, and a much more useful one.

So the first question is never which model. It is which process, and what number tells you afterwards whether it worked. Pick both before anything gets built, or you will end up with something impressive that nobody can prove is earning its keep.

Where an agent pays for itself, and where it does not

Three patterns pay almost every time. A person retyping records between two systems that do not talk. A queue that sits still because the only person who can move it is asleep or in a meeting. A decision made two hundred times a week the same way by someone who is overqualified for it.

Three patterns rarely pay. A process that runs once a month, because the automation costs more than the annoyance. A process nobody has written down, because the agent will faithfully automate whatever the loudest person remembers. And anything where being wrong once is unrecoverable, which needs a human in the loop rather than a better prompt.

We turn down agent work fairly regularly on the first call, usually because what the business actually needs is a report, a form or one integration.

The agent we would point at first, and what it did for us

Speed of first answer is the cheapest agent to build and the easiest one to measure, and in most businesses it is also the one with the largest gap between what leadership believes and what is happening.

On our own site the honest number was worse than embarrassing. Inbound enquiries went to an inbox that got read when somebody had time, and enquiries that arrived on a Friday evening waited until Sunday. On 14 August 2026 we handed the first answer to an agent. Now a submission is answered in five to forty five minutes, in the sender's own language, and every answer closes on one concrete next step rather than a paragraph of enthusiasm.

The point is not that answering fast is clever. It is that time to first answer was a number we could read before and after, which made the agent arguable rather than a matter of taste.

A window, a limit and a store, or it is not safe to leave on

An agent inside a business needs three things that have nothing to do with intelligence. A window, so it does not contact people at three in the morning. A limit, so a bug costs one message rather than four hundred. A store, so it knows what it already did and cannot repeat itself.

Ours has all three, and each one exists because of something that went wrong. The queue releases only between 08:00 and 01:00, so a lead arriving at 03:00 waits for the morning. One answer per email address is enforced in the store, so a webhook retry cannot double-send. A backstop sweep runs twice an hour in case the main trigger ever misses, which it has.

The same idea in a sales context: our marketplace responder is not allowed to send a price or an offer until three real replies from that buyer exist, enforced in the backend rather than requested in a prompt. Every one of those rules is boring, and together they are the reason nobody has to babysit it.

The failure that quietly eats the value

In June 2026 the contact form on this site took 525 sessions, recorded one completed lead event, and delivered zero notification emails. There was a forty day stretch with no lead email at all, and the form said thank you the entire time. Somebody who wanted to hire us filled it in and we never found out.

It was not an agent failure, it was worse: nothing was watching the boring path. The intake now writes every submission to a durable store on disk before it hands anything to a mail provider, each row carries its delivery status and error, and a job compares stored rows against notified rows daily.

Any agent you put in front of customers inherits this risk. Ask what happens to the work when the notification fails, and if the answer is that the request returned 200, the work is being lost somewhere and nobody has noticed yet.

How to judge it after three months

Pick the number first and write it down: time to first answer, tickets closed without a human, hours of retyping removed, days of receivables collected earlier. One number, measured the same way before and after.

Then keep a plain record of what the agent did and what it refused to do. Ours shows every action with its outcome, and an action that cannot be read back from the destination counts as failed no matter what the API replied.

If after three months nobody can say what changed, the agent was the wrong project. That is a cheaper thing to discover with one workflow than with five.