AI agents for business: where they fit and where they fail

An AI agent for business is a system that takes a process you currently staff: it reads the inputs, decides what to do, acts in your systems, and stops when it reaches something it was not given authority over.

Whether that is worth building depends far less on the technology than on the process. The model is now the easy part. Choosing which work to point it at is not, and it is the choice that is made first, usually with the least information. So this page is about how to make it before anyone commissions anything.

Three questions that decide it

Before the model, the framework or the platform, three properties of the work decide whether an agent is the right instrument.

How often does it run? A process that runs twice a quarter will not repay the build, the monitoring or the maintenance, no matter how irritating it is. Frequency is the first filter because it is the one that determines whether anything else matters. The annoying process and the expensive process are often not the same process, and the annoying one is the easier to nominate.

How varied are the inputs? If every input arrives in the same shape, you want a script, or a rule-based workflow, and you will get a cheaper, faster and more testable result. Agents earn their cost where the inputs are messy: attachments in the wrong format, values that need interpreting, cases that do not match the documented procedure. That distinction is covered in more detail in our note on agentic AI versus AI agents.

What does a wrong answer cost, and how quickly would you notice? These two go together. A mistake that surfaces in an hour and costs a phone call is a good place to learn. A mistake that surfaces in six months inside a customer contract is not, and no amount of testing changes that arithmetic.

The order matters. Frequency decides whether the work is worth doing. Input variety decides whether it needs an agent rather than a workflow. The cost of an error decides what the agent may do without a human.

Shapes of work that tend to fit

These are patterns rather than industries. The industry rarely predicts fit.

Exception queues. You already have automation covering the straightforward cases, and a person handles what falls out of it. That queue is usually the strongest first target you have, because the volume is already known, the cost is visible in someone’s week, and success is easy to define.

Moving work between systems that will never be integrated. Two tools that both matter, no integration budget, and a person acting as the connective tissue. An agent that reads one and writes the other is unglamorous and frequently the fastest thing to justify.

Intake and triage. Incoming email, forms, tickets and documents that have to be read, classified, extracted from and routed. The judgement is real but shallow, the volume is high, and a misroute is recoverable.

First drafts that a person signs. A quote, a reply, a summary, a report. The agent prepares, a human approves. This shape has the best risk profile available, because the approval step is a genuine control rather than a formality, and it is usually where a first project should start.

Reconciliation. Comparing two records that ought to agree, and explaining the difference in terms a person can act on. Checking work is often easier to automate safely than doing it.

The common thread: the inputs vary, the goal is stable, and someone can tell after the fact whether the answer was right. That last property is what makes improvement possible. Without it you are shipping something nobody can evaluate.

Shapes that do not

The process nobody can describe. If three people do the same job three ways and none of them can explain the rule they are applying, there is nothing to automate yet. Writing it down is the project, and it is worth doing whether or not an agent follows.

The process with no digital surface. If the only way into a system is a screen a person clicks through, the integration is the whole project and the agent is a footnote. Sometimes that is still worth it. It should be a decision, not a surprise.

The decision that has to be attributable to a named person. An agent can assemble that decision, evidence it and present it. It should not be the thing recorded as having made it. Check where those obligations apply in your own context before designing anything that touches them.

Low volume with high variety. Ten genuinely novel cases a year is judgement work. Building a system to replace it is expensive, and it will not have enough examples to get good.

Work where the right answer keeps moving. If the ground truth changes faster than you can evaluate against it, you have no way to know whether the agent is still correct. You will find out from a customer.

Being able to name which of these applies is most of the value of an AI automation audit, and “do not automate this one” is a legitimate result of one.

What the agent should not be allowed to do

The safety of a business agent comes from its boundary, not from the model behaving well. Three artefacts do most of the work, and all three are cheaper to produce before the build than after it.

A written authority boundary. Three lists: what it may do alone, what it prepares for a human to approve, and what it must refuse and escalate. Written in the language of your process, not in prompt text.

Scoped credentials matching that boundary exactly. Not the service account someone already had. An agent that can take six actions can take at most six wrong actions, which is a very different exposure from one holding an administrative token.

Logs that answer “why did it do that”. Inputs, tool calls, intermediate decisions, final output. An automation you cannot reconstruct is one you cannot safely widen, and widening it is the entire point of the first project.

Where an agent needs access to internal systems, that access is worth putting behind a deliberate interface rather than handing over raw credentials. That is what the Model Context Protocol is for, and what our MCP server development work builds.

What it costs to run

The build is a project. The running is a commitment, and the second one is what quietly decides whether the automation still works in a year.

Model calls. An agentic run makes more of them than a fixed workflow, because deciding what to do next is itself a call. Cost scales with volume and with how much latitude you gave it.

Latency. A system that reasons takes longer than a system that follows a script. For a queue processed overnight this is irrelevant. For something a customer is waiting on, it is a design constraint.

Someone reading the escalations. Every well-designed agent produces a stream of cases it declined to handle. If nobody owns that stream, the agent is not saving the work, it is relocating it.

Maintenance. Your systems change, models are deprecated and replaced, and tool descriptions that were precise last quarter stop matching what the tools do. This is ordinary software maintenance and it should be budgeted as such.

How to find out before you commit

Take the narrowest slice that is still real. One process, one team, one measurable outcome. A pilot spanning four departments is a strategy exercise, and it will be evaluated as one.

Run it in shadow mode. Real inputs, no authority, a person still doing the job. Compare the outputs. This is the only stage where a disagreement costs nothing, so it is the stage worth being patient in.

Watch the escalation rate, not just the success rate. An agent that escalates honestly is behaving as designed. An agent that answers confidently on inputs it should have refused is the expensive failure, and a headline success rate hides it.

Agree in advance what would make you stop. A threshold, a category of error, a date. Deciding that while the project is still going well is much easier than deciding it afterwards.

Where this lands

Most organisations evaluating agents are asking whether the technology works. It works well enough that the question is no longer interesting. The useful question is narrower and specific to you: which of your processes runs often enough to matter, varies enough to need judgement, produces an answer somebody can check, and carries a mistake you can afford while you are still learning.

There are usually one or two. Starting with them is slower than a strategy document and considerably more likely to end with something running.

That is the question our AI automation audit is built to answer, and agentic workflow automation is how we build whatever survives it.