AI agents in business operations: where they work, where they quietly fail

The central idea

An AI agent earns its place when it owns a bounded decision with a reversible outcome and a measurable cost of being wrong. Every other framing turns into a demo that nobody can put into production.

The word agent has absorbed almost everything: a chat window, a scheduled script, a retrieval pipeline, a system that files its own tickets. The vagueness is expensive, because a team that cannot say which decision the agent owns cannot say what would count as it working. Most programmes that stall have already built something functional. What they never wrote down was the boundary — the point at which the agent stops and a person takes the next step — and without that boundary there is nothing to test, nothing to approve, and nobody willing to sign.

What changed, and why it matters now

The pattern is visible in where the work dies. It is rarely the model evaluation; it is the review that comes after, when legal asks what happens if the agent is wrong and the answer is a shrug. Programmes that survive tend to share an unglamorous trait: the first agent handled something the organisation already did badly and cheaply, where a mistake cost a few minutes rather than a customer. Programmes that stall usually chose the most visible workflow, because that was the one with executive attention, and visibility is exactly what makes an error unacceptable during the period when errors are most likely.

Build the operating model

Scope the first agent as a decision, not a department. Name the input it receives, the judgement it makes, the action it may take without asking, the action it must escalate, and the person who owns the escalation.

Write the escalation rule before the prompt. It is the part that determines whether the system can be approved, and it is the part most teams leave until last. A useful rule is specific about thresholds rather than about sentiment: escalate above a stated value, escalate when confidence falls below a stated level, escalate when the request touches a named category. Vague rules — escalate when unsure — are unenforceable, because the model's sense of being unsure is not calibrated to your risk appetite, and neither is anyone else's.

Measure what the decision produced

Measure the rate at which the agent's output is accepted without edits, the cost of the errors it does make, and the time the owning team gets back. Task volume alone tells you nothing about whether the work improved.

Acceptance rate is the honest number because it is generated by the people who have to live with the output. Track edits separately from rejections: a high edit rate with low rejection means the agent is drafting usefully but not finishing, which is a scoping result rather than a model result. Also track what the team stopped doing. If the hours saved were absorbed into supervising the agent, the programme has moved work rather than removed it, and that shows up nowhere in a usage dashboard.

Where execution breaks

The dominant failure is an agent with wide latitude and no owner, which produces plausible output that nobody checks until something visible breaks.

The second failure is subtler and more common: silent scope creep. An agent scoped for one queue starts being pointed at adjacent ones because it appears to work, and the boundary conditions that made it safe no longer hold. Nobody makes a decision to expand it; it simply accumulates use. The defence is to version the scope like an interface, record which queues are in it, and treat adding one as a change that requires the same review as the original launch. A third failure is evaluation drift: the cases used to prove the agent worked were collected in a quiet period, and six months later the inputs have changed shape while the benchmark has not. Refresh part of the evaluation set each quarter from live traffic and keep the original partition, so the two can be compared rather than one quietly replacing the other.

What this looks like in practice

In practice the first agent that works is usually dull. It reads structured requests that already arrive in a queue, classifies them against categories the team already uses, drafts a response from templates that already exist, and hands anything unusual to a named person. It is not impressive in a board demo. It is, however, approvable, measurable, and reversible, and it produces the operating evidence that makes the second and third agents easier to fund. The teams that get to a fifth agent usually did not get better at prompting; they got better at writing the boundary, and they accumulated a library of escalation rules that new work could inherit. That library is the real asset. It encodes what the organisation has decided it is willing to delegate, which is a governance position rather than a technical one, and it is the part that cannot be bought from a vendor.

The strongest argument against this

The strongest objection is that narrow scoping wastes the capability. If a model can reason across a whole workflow, constraining it to one decision is deliberately leaving value on the table, and a competitor willing to grant more autonomy will move faster. That argument has real force in low-stakes internal work where errors are cheap and recoverable, and teams operating there should scope wider than this guide suggests.

It has much less force wherever an error reaches a customer, a regulator, or a ledger. The asymmetry matters: the upside of broader autonomy is incremental efficiency, while the downside is an incident with a name attached. Organisations that expanded fastest were usually not braver; they were operating in domains where being wrong was survivable, and they should be read that way rather than as a general lesson.

A 30-day implementation sequence

Pick one queue, write the escalation rule first, run the agent in draft-only mode for two weeks, and measure the acceptance rate before granting it any authority to act.

Week one, instrument the workflow as it is and capture a baseline of volume, handling time, and error rate — without this the programme has no way to prove anything later. Week two, run the agent in shadow: it produces output, a person does the work, and the two are compared. Week three, switch to draft-first, where the agent's output is the starting point and every edit is logged. Week four, grant it authority only for the categories where the edit rate is already low, and leave the rest in draft.

Keep a decision log, not a usage dashboard

For every scope change, record what the agent was allowed to do before, what it is allowed to do now, what evidence justified the change, and who approved it. After ten entries the log answers the question every review eventually asks — how did this system end up with the permissions it has — and it answers it with dates and names rather than recollection. Usage dashboards cannot do this. They show that the agent is busy, which is the least interesting property a system can have, and they tend to rise fastest at exactly the moment scope has quietly outgrown its review.

Review fortnightly while the scope is still moving and monthly once it settles. Read acceptance rate, edit rate, escalation volume, and incident count together, because each one alone can be made to look good. A falling escalation rate is a success if acceptance is rising and a warning if it is not — it may simply mean the humans have stopped checking. When a metric improves, ask which of the other three moved with it before recording the improvement as real.

Editorial conclusion

The interesting question in an agent programme has never been whether the model is capable. It is whether the organisation can state, in one sentence, which decision it has delegated and what happens when that decision is wrong. Teams that can write that sentence tend to ship. Teams that cannot tend to run pilots indefinitely, and call the delay a technology problem.