What AI agents can actually automate

Definitions, because the word has been stretched

“Agent” is currently applied to everything from a chatbot with a scripted flow to a system that autonomously executes multi-step work. Gartner has a term for the gap — agent washing — and the practical consequence is that two vendors can use the same word for products that differ by an order of magnitude in capability and risk.

The useful definition is narrow. An agent is a language model that can call tools — search a database, read a file, hit an API, send an email — decide which to call based on what it has learned so far, and repeat until a task is done. The distinguishing feature is the loop: it is not answering once, it is taking a sequence of actions it chose.

That loop is the entire source of both the value and the danger. A system that only produces text is wrong at worst. A system that takes actions is wrong and has done something.

What makes a workflow suit an agent

Across the workflows that work well, the same properties keep appearing.

The work is mostly reading, deciding and routing. Gathering information from several systems, comparing it against rules, and producing a decision or a draft is exactly what these systems are good at. Triage, classification, extraction, summarising a case file, and preparing a recommendation all fit.

Mistakes are visible and cheap to reverse. A misrouted ticket gets rerouted. A weak draft gets edited. Compare that with an incorrectly issued refund or a wrongly closed account, where the error propagates into finance, into a customer relationship, and sometimes into a regulator’s field of view.

A person is already in the loop, or can be. The highest-yield agent designs today are not autonomous. They compress an hour of gathering and drafting into a minute, and a person approves the result. You capture most of the value and almost none of the risk.

The volume justifies the engineering. An agent is a production software system that needs integration, evaluation, monitoring and maintenance. Something that happens eleven times a month rarely repays that. Something that happens four hundred times a day usually does.

The inputs are bounded, even if messy. Free-form email is fine. Documents in inconsistent formats are fine. What is hard is a task where the required knowledge lives in someone’s head and appears nowhere in any system.

Where agents are genuinely working

The categories below are where results are most consistent — and note that most are assistive rather than autonomous.

Support triage and drafting. Read the incoming message, pull the customer’s account state and history, identify the issue, draft a reply grounded in real documentation with links to the sources. The agent does the reading and the first draft; an agent sends only for a narrow class of cases where being wrong is cheap.

Document extraction into systems of record. Invoices, purchase orders, claims, contracts, forms. Pull the fields, validate them against expected ranges and existing records, write the confident ones through, queue the uncertain ones for review. The validation and the confidence threshold are what make this work — an extraction agent without them just moves the error further downstream.

Internal knowledge retrieval. “What is our policy on this?” answered from actual policy documents, with citations, respecting the asker’s permissions. Boring, and among the highest-value things most organisations can build.

Research and synthesis. Gathering information across many sources into a structured brief — competitive summaries, due-diligence packs, literature reviews. Output is a document a person reads, which keeps the risk profile mild.

Engineering support work. Test generation, migration of repetitive patterns, first-pass code review, log triage during an incident. Well-suited because the work is high-volume, and because the verification step — tests, review, CI — already exists.

Operational monitoring. Watching for conditions across systems that are tedious to check manually, and assembling the context a human needs to act. The agent gathers; the person decides.

Where they should not be pointed yet

Irreversible actions without confirmation. Moving money, deleting data, sending contracts, changing production configuration, anything with legal weight. The engineering answer is not “make the model more accurate” — it is to keep a confirmation step for actions that cannot be undone.

Long autonomous chains. Reliability compounds badly. A step that is right 95% of the time is right about 60% of the time after ten sequential steps, and errors early in a chain get built upon rather than caught. Long workflows should be decomposed into checkpointed stages, not handed over as one instruction.

Work whose real content is judgement about people. Hiring decisions, performance assessment, discipline, credit and benefits determinations. Some carry direct legal exposure. All of them share a property that matters more: the person affected deserves a reason, and “the system scored you low” is not one.

Anything where nobody can explain the decision. If your industry requires you to justify an outcome, the system has to produce the reasoning and the evidence, not just the answer. That is a design constraint from the first day, not a feature to add later.

Tasks nobody has written down. If the process exists only as tribal knowledge, the first project is documenting it. That effort frequently delivers most of the available value on its own, and occasionally reveals that the workflow should simply be deleted.

Scoping one so it survives

Pick one workflow with a measurable cost. Not “AI for customer service” — “the 400 daily tier-one tickets that take an agent six minutes each.” A number you can compare against later is what makes success arguable.

Write down the current process as steps. Where the information comes from, what decisions get made, what the exceptions are. This is where most of the discovery happens, and where projects get honestly re-scoped.

Give it the narrowest tools that do the job. Every capability granted is a capability that can be misused — by a confused model or by someone who has worked out how to manipulate its inputs. Read-only access wherever reading is enough. Scoped credentials, never a shared admin key. This is a security design problem as much as an AI one: an agent that reads untrusted input and holds real permissions is a genuinely new class of attack surface.

Define the confidence threshold and the escape hatch. What happens when it is unsure? Every deployment that lasts has a clear answer, and it is usually “hand it to a person with the context already gathered.”

Build the evaluation set before the agent. Fifty to a hundred real cases with known-correct outcomes. Without it you cannot tell whether a change improved anything, and you will be changing things constantly.

Log everything. What it saw, what it decided, which tools it called, what came back. When it does something strange — it will — this is the difference between a fix and a shrug. It is also what lets you answer a customer who asks why.

Ship the assistive version first. Agent proposes, human approves. Run it long enough to build a record of where it is reliable, and let that evidence — not a vendor’s confidence — decide which cases graduate to automatic.

The honest economics

Two things are true at once, and vendors tend to tell you only one.

Agents can remove a large share of the gathering-and-drafting time in the workflows above. That is real, and for high-volume processes it is substantial.

They also cost more to run than traditional automation, they are non-deterministic in ways that require ongoing evaluation, and they need maintenance as models, APIs and your own systems change. A deployed agent is not a finished project; it is a system with an operating cost.

Which means the workflows worth automating are the ones where volume is high enough that the saving outruns that overhead. For genuinely repetitive, well-specified tasks, a plain script remains cheaper, faster and more predictable — and choosing it over an agent is an engineering decision, not a failure of ambition. The technology is exciting; that is not by itself a reason to route a workflow through it.

Where we sit

We build AI agents and automation with those constraints as the starting point: narrow scope, tight permissions, evaluation from the beginning, a person at the points where being wrong is expensive, and logs that let you reconstruct what happened.

We will also tell you when a workflow does not need an agent — when a rule, a script or a search index does the job for less money and less uncertainty. That is a cheaper answer for you than a build, which is exactly why it is worth asking for.

If you have a workflow in mind and want an honest read on whether it fits, the initial consultation is free and we reply within 24 hours.