AI Agents for Business: Which Four Jobs Actually Work?

Every vendor deck now has agents in it, and the word has been stretched far enough that it no longer tells you what you are buying. Underneath the language, an agent is software that can take a goal, work out a sequence of steps, use tools to carry them out, and keep going until it is done or stuck. That is genuinely different from older automation, which followed a fixed sequence somebody wrote in advance.

What nobody tells you in the deck is that this flexibility is the problem as well as the feature. Fixed automation fails loudly and predictably. An agent can fail creatively, which is harder to notice and considerably harder to explain to a client.

Here is what matters most:

• Agents are worth it where the sequence of steps genuinely varies. Where it does not, ordinary automation is cheaper and safer.
• Four jobs work reliably in production today. Three commonly-sold ones get quietly abandoned.
• The deciding question is what a wrong answer costs. Agents suit work where a mistake is recoverable and visible.
• An agent without a defined stopping condition and a human review point is an unbounded risk, not a product.
• Measure the exception rate, meaning how often a person must step in. Accuracy on its own is a marketing number.

The four that work

These are the ones we see survive past month three, in our own systems and our clients'.

Reading messy documents and pulling structured data out. The strongest case by a distance. An invoice from a supplier who redesigned their template, a bank statement photographed at an angle, a contract where the payment terms are buried in a schedule. Fixed rules break on all of these. An agent handles the variation, flags what it is unsure about, and a person resolves the flagged cases. This is the bulk of what we build, and the reason it works is that a wrong answer is visible and cheap to correct before it lands anywhere important.

Research and gathering. Pulling together everything known about a company, a property, a claim or a counterparty from several sources, then producing a structured summary a person reviews. It works because the output is a draft for a human, not a decision. If the agent misses something, the person reading it notices.

Triage and routing. Deciding which of nine queues a new item belongs in, what priority it carries, and who needs to know now. This suits agents because the rules are fuzzy and numerous, and because a mis-route is noticed immediately and costs a minute to fix.

First-draft generation inside a defined format. A draft report, a draft response, a draft summary that follows a known structure and gets edited before it goes anywhere. We run one system that produces well over a thousand finished reserve study reports a year with roughly eighty-five percent less time per report, and the reason it works is that it drafts into a rigid format and a qualified person signs off.

Notice the pattern. In all four, the agent produces something a human sees before it becomes consequential.

The three that get abandoned

I would rather tell you this before you spend money than after.

Fully autonomous customer-facing agents. Not the scripted assistant that answers known questions, which is fine. The one given latitude to resolve a customer's problem end to end. The failure mode is not that it is wrong occasionally, it is that it is confidently wrong to a customer in writing, and you find out when they forward the transcript. Firms that try this usually pull it back to draft-and-approve within a quarter, which is where it should have started.

Agents that decide anything a regulator or a client could question. If the answer needs to be defensible afterwards, the reasoning has to be inspectable and consistent, and an agent's path through a problem varies between runs. Use fixed rules for the decision and an agent for the gathering that feeds it.

Sales and outbound agents that operate unattended. I can be blunt here because we did this to ourselves. We ran our own outbound through an automated pipeline: sixty-three campaigns, more than eleven thousand messages, a thirty-four percent hard-bounce rate and zero recorded replies. The system reported success throughout. Worse, when the language model behind it ran out of credit, the service returned an error, the step was not set to treat that as a failure, and the pipeline logged 11,458 sends as successful while every single one had died. We do not sell outbound automation for this reason, and I would treat anyone who does without showing you their own reply rate with some caution.

The question that decides it

Before scoping anything, answer this: what does a wrong answer cost, and who sees it first?

If a mistake is caught by the person who receives the output, in the ordinary course of their work, an agent is a reasonable bet. The cost of being wrong is a few seconds of correction.

If a mistake flows silently into a system of record, a client deliverable, or a regulatory filing, then you need either fixed rules or a mandatory review gate. This is not a technology limit you can buy your way past with a better model. It is a design decision about where the human sits.

That question also settles the build. Agents suited to the first case need a confidence score, a review queue, and a stopping condition. An agent with no defined point at which it gives up and asks is the single most common design fault we see, and it is what produces the horror stories about runaway cost and strange behaviour.

What one actually costs to run

Two costs, and proposals usually only mention one.

The build is a project: scoping, connecting the systems it needs, defining the confidence threshold, building the review queue, testing against real messy data rather than samples. For one well-defined job that is typically weeks, not months.

The running cost is per-use and it is the one that surprises people. Every step an agent takes costs money, and an agent that reasons its way through eight steps costs roughly eight times one that takes one. This is manageable and predictable once measured, but it means the pilot number and the production number can differ by a lot once real volume arrives. Ask any vendor for cost per completed task at your expected volume, not a monthly platform fee.

Then size the return the same way as any automation. Count how often the work happens, the mechanical minutes it takes now, and a fully loaded hourly cost. Two hundred items a month at fifteen minutes each is fifty hours. At forty dollars an hour that is two thousand a month. Apply a realistic exception rate rather than an accuracy claim: if a quarter still need a person, you are saving three-quarters of it, not all of it.

How to start without betting much

Pick one job from the four that work. One document type, one research task, one routing decision. Put it into production with real data and real volume, with a review queue from day one, and measure the exception rate for a month.

That number tells you everything the sales process cannot. It tells you whether the second project is worth funding, and it gives your team a realistic picture of what their day looks like afterwards, which is the thing that determines whether anyone keeps using it.

And keep the framing straight with your people while you do it. The agent reads, gathers, routes and drafts. Your team reviews, judges and owns the client. Projects sold internally as headcount reduction tend to be quietly sabotaged by the people whose help you need to build them.

FAQ

What is the difference between an AI agent and ordinary automation?

Ordinary automation follows a sequence somebody defined in advance and does the same thing every time, which makes it predictable and cheap to debug. An agent works out its own sequence towards a goal and can adapt when the input varies, which is why it handles messy documents and fuzzy routing that rules cannot. The trade is predictability: two runs of the same agent on the same input may take different paths.

Do AI agents replace staff?

In the deployments that survive, no. The mechanical portion of the work goes away and the same team absorbs more volume, while the cases needing judgement reach a person faster and with better context. Deployments designed explicitly to reduce headcount tend to fail for organisational reasons long before technical ones, because they need cooperation from the people being displaced.

How do we stop an agent doing something expensive or strange?

Three controls, and a build without all three is not finished. A hard limit on how many steps it may take before stopping. A restricted set of actions it is permitted to perform, so it cannot reach systems outside its job. And a review gate before anything consequential leaves the system. The failure stories almost always trace back to a missing stopping condition.

How long does a first agent project take?

For one well-defined job, expect weeks rather than months, with most of the time going into the messy real-world input rather than the agent itself. Then budget a month of running it in production to learn your actual exception rate. That measurement period is not optional, because it is the only honest basis for deciding whether to build the second one.

Key takeaways

• AI agents suit work where the sequence of steps varies. Where it is fixed, ordinary automation is cheaper and more predictable.
• Four jobs work reliably: document extraction, research gathering, triage and routing, and first-draft generation into a fixed format.
• The deciding question is what a wrong answer costs and who notices it first.
• Every agent needs a step limit, a restricted set of permitted actions, and a human review gate before anything consequential.
• Exception rate, not accuracy, predicts how much work your team still does after deployment.

If you have a specific job in mind and want a straight answer on whether it belongs in the first group or the second, that is a short conversation.

Book a free strategy call

Related reading: what is intelligent automation · what is hyperautomation · do you need an AI automation consultant

Services: AI agent development · document processing automation