AI agents for the business you already have

Last reviewed 27 July 2026

What handing over a job means

Handing a job to an agent means one recurring piece of work stops being something a person has to remember to do. The agent watches for the condition that starts the job, runs it end to end, and returns only what it could not settle. Nothing else about the company has to change for that to work.

That is different from the automation most businesses already own. A workflow runs a path somebody drew in advance, and either follows it or breaks when the input does not match. An agent reads the input, decides which path it belongs on, and is expected to say when it does not know. The useful consequence is not speed. It is that the awkward cases stop falling on the floor and start arriving in one place with a reason attached.

An agent is a position rather than a purchase. A category list slowly stops matching the words customers use. A supplier changes a document layout. A sending address loses its reputation. A threshold that was right at last year's volume is wrong at this year's. Every job below has a maintenance surface of that kind, and one handed to an agent nobody operates ends up worse than the manual version it replaced, because the manual version at least complained.

None of this is a trial run for something larger. A business can hand over four jobs and keep every person on the payroll. A business can also be built from nothing with agents doing the work throughout, which is what an agent-run company is. The difference is scope, not seriousness, and what decides whether either one works is the same in both: somebody has to keep the agents running after they are built.

What makes a job suitable

Four tests. A job that fails one of them is usually not ready rather than unsuitable, and the difference matters, because the two have different fixes.

There has to be a trigger you can observe. An invoice past its due date, a form submission, a ticket sitting unassigned, a file arriving in a shared inbox: in each of those a system changed state, and that change is the entire starting condition. Work that begins because an experienced person noticed something has no trigger to watch, and the first task there is finding out what they noticed, not procuring an agent.

The judgement has to survive being written down. An agent cannot infer which customers you want, which code a transaction belongs under, or which of your queues a request should sit in. It applies the version you wrote down, identically on the first record and the ten thousandth, and that consistency is most of the benefit. The uncomfortable corollary is that what you are really buying is the written version, and the agent is only the machinery underneath it. Where the rules live in one person's head, the work in front of you is an interview rather than an implementation.

There has to be a check that is not another model. Each of these jobs has one available. An invoice states a total that either equals the sum of its own lines or does not. A chase can be tested against a ledger that will eventually disagree with it. A lead score can be compared, months later, against which of those leads became customers. A ticket routed to the wrong queue comes back. Where the only way to find out whether the output was right is to ask a model whether it was right, errors accumulate silently and the first evidence arrives months later as a number nobody trusts.

You have to be able to name the conditions under which it stops. A dispute rather than a query. A confidence score under the line. Arithmetic that will not reconcile. A submission naming an account somebody already owns. The most important behaviour any of these agents has is the one where it does nothing and hands back, and it is the part most specifications leave out. If the stopping conditions cannot be listed before the build starts, what exists is a hope rather than a specification.

Where the boundary sits

The boundary is not difficulty. It is consequence. Every one of these jobs divides into a half that prepares a decision and a half that announces one, and the two halves carry completely different risk. Reading a ticket and labelling it is reversible; answering the customer is not. Pulling fields off an invoice is reversible; posting it and paying it is not. Scoring a lead is reversible; the message that goes out under your name is not.

So the sequence that works is to hand over the inside half first. It costs less, it fails where somebody can see it, and it leaves behind a record of past decisions that anything attempted on the outside half will need as its starting evidence. Beginning with the customer-facing half means taking on the largest downside in the job before there is any evidence about how often the agent is right.

Some things stay on the far side of that boundary permanently, and they are recognisable by what they start rather than by how hard they are. Anything that begins a statutory clock. Anything that creates or waives a legal position. Anything that moves money to a party whose identity has not been confirmed. Anything where the person on the other end is deciding about the whole relationship rather than about this one transaction. In each of those the agent's correct output is a flag and a named owner, and its correct action is none.

By job

One page per job, covering what starts it, how it goes wrong, and where it hands back to a person.

Apply