The guide to AI process automation
AI process automation is using AI agents to run a costly, repeatable manual process end to end: the agent reads the inputs, does the multi-step work, and hands people the decisions that need judgement. This is the honest version, what it is, where it pays, and when automating is the wrong move. Written from building it in production, not theory.
AI process automation: at a glance
- What it is
- AI agents running a costly, repeatable manual process end to end, in production.
- Where it pays
- Repeatable, high-volume work with a quantifiable cost and a templatable output.
- Where it does not
- Low volume, fast-changing processes, work an off-the-shelf tool already does, or poor data.
- The payback test
- Price divided by monthly saving. A £20,000 agent that saves £4,000 a month pays back in about five months.
- How a build runs
- Paid Process Discovery, fixed-price build with a human in the loop, then evals, monitoring and an SLA.
- Delivery
- Production in 90 days, fixed price, money back if the proof of concept fails.
- Read it free
- The full guide is on this page. The PDF is the same guide, emailed for offline reading.
What is AI process automation?
Using AI agents to run a costly, repeatable manual process from start to finish. A person currently opens three systems, copies data between them, checks a document against a rule, and decides what happens next. An agent does the gathering and the checking, and brings a human the decision rather than the whole task.
Not RPA
Robotic process automation follows fixed rules and breaks when an input changes shape. Agents read messy, unstructured inputs and handle the exceptions.
Not a chatbot
A chatbot answers questions. An agent acts inside your systems, with permission and an audit trail, and produces a result you can check.
An AI agent
Reads the inputs, does the multi-step work, and hands people the decisions that need judgement, with the context already gathered.
Where does AI process automation pay?
Hit these four and the maths usually works. Miss them and it usually does not.
Repeatable
The steps are broadly the same each time, even if the content differs.
High volume
It happens often enough that small savings add up to a real number.
Costly
You can put a figure on what it consumes: hours, errors, or slow turnaround.
Templatable
The output has a recognisable shape: a structured record, a checked document, a routed request.
The test that matters
Payback. Take the build cost and divide it by the saving each month. A £20,000 agent that saves £4,000 a month pays back in about five months. If you cannot estimate the monthly saving, you are ready to measure the process, not automate it.
A strong candidate, or the wrong move?
Most guides skip the second column. If two or three on the right describe your process, wait or fix the upstream problem first.
Strong candidate
- The work is repeatable and high in volume
- You can put a number on what it costs today
- The output has a recognisable, templatable shape
- People describe it as "death by a thousand cuts"
- Volume is climbing and the only plan is to hire
Wait, or fix first
- The volume is low, so a person is cheaper and more flexible
- The rules, inputs or goal change every few weeks
- An off-the-shelf tool you already license does it
- The source data is incomplete, inconsistent or scattered
- The cost of an error is too high to remove a person
Custom build, or off-the-shelf?
The honest middle ground is common: buy the commodity parts, build only the thin layer that is genuinely yours.
Buy when
- A tool you already use, or could license cheaply, does the job
- It is faster to start and cheaper to run
- Someone else maintains it for you
Build when
- The process is specific to how you work
- It spans several systems that do not talk to each other
- It needs to read your unstructured documents
- It has to meet a standard a generic tool cannot reach
How does a build actually work?
Three steps, kept deliberately simple. The third cost is the one people forget.
Process Discovery
A short, paid engagement
We map the process, find the steps worth automating, and return a fixed-price plan with the payback line. If it is a poor fit, you have spent a small, known amount to avoid a large, uncertain one.
The build
Fixed price, quoted after discovery
Deployed on your stack with role-based access and an audit trail, a human kept in the loop where judgement matters. Cost drivers are honest: how many systems it touches, how messy the inputs are, how high the cost of a mistake is.
Run it
Ongoing, and real
Evals, monitoring and an SLA keep it trustworthy as inputs drift. The model usage is usually the smallest line; the discipline around it is what matters. A build with no run plan is a demo, not an operation.
The standard is production in 90 days, at a fixed price, with money back if the proof of concept fails. You are buying a result with a defined way out.
Questions to ask any vendor
Use this list on us and on anyone else. The answers tell you more than the demo does.
- 1Who owns the data and the model outputs? It should be you, in writing.
- 2Where does it run? Your platform and your tenant, or someone else's. For regulated work, your own environment is often the only acceptable answer.
- 3How do we prove what the agent did? Ask to see the audit trail and the logs.
- 4What happens when it is wrong? Look for a human in the loop, a confidence threshold and an escalation path.
- 5How is it evaluated over time? "We checked it at launch" is not an answer. Evals should be ongoing.
- 6What is the run cost, in full? Get the monthly number, including monitoring and support.
- 7Is the price fixed, and what is the guarantee? You should know the number before you commit.
Where has this worked?
Three examples, framed exactly as they stand. We also run our own company on six connected Claude agents across sales, finance and delivery.
PoC to betaEight-agent pharmacy pipeline
A US pharmacy needed prescription checks done faster without dropping the regulated standard. The pipeline takes a 15 to 20 minute manual check down to seconds, with a pharmacist on the exceptions.
In production (beta)Clinical research (Lumono.ai)
A plain-English research question turned into publication-ready analysis with citations, doing work that used to take many months. Named with permission.
Discovery deliveredOrder-to-schedule (secure-logistics operator)
A delivered discovery and a designed pilot: an intake agent feeding a 70-plus-rule engine, manage-by-exception so people only touch the orders that need a decision. Not live yet, and we will not say it is.
Email me the PDF
Prefer to read offline? We will email you the PDF. No sequence you cannot leave.
Common questions about AI process automation
What is AI process automation?
AI process automation is using AI agents to run a costly, repeatable manual process from start to finish. The agent reads the inputs, does the multi-step work, and hands people the parts that need judgement, with the context already gathered. It goes further than robotic process automation, which follows fixed rules and breaks when the input changes, and further than a chatbot, which talks but does not act inside your systems.
Where does AI process automation pay?
It pays when the work is repeatable, high in volume, costly in a way you can measure, and produces a templatable output. The test that matters is payback: take the cost of the build and divide it by the value it reclaims each month. A £20,000 agent that saves £4,000 a month pays for itself in about five months.
When is AI automation the wrong move?
When the volume is low, when the process changes too often, when an off-the-shelf tool already does it, when the data is too poor, or when the risk of error is too high to remove a person from the decision. If two or three of these describe your process, the honest recommendation is to wait, or to fix the upstream problem, before you automate.
Should you build a custom agent or buy an off-the-shelf tool?
Buy when a tool you already use, or could license cheaply, does the job to a standard you can live with. Build when the process is specific to how you work, spans several systems that do not talk to each other, needs to read your unstructured documents, or has to meet a standard a generic tool cannot reach. The common middle ground is to buy the commodity parts and build only the thin layer that is genuinely yours.
What does AI process automation really cost?
There are three costs. Discovery, a short paid engagement that maps the process and returns a fixed-price plan with the payback line. Build, fixed price, quoted after discovery. And run cost, which is real: evals, monitoring and an SLA keep the system trustworthy as inputs drift. A build with no run plan is a demo, not an operation.
How does an automation build actually work?
Three steps. First, a paid Process Discovery that maps the process and returns a fixed-price plan and the payback line. Second, the build, with a human kept in the loop where judgement matters, deployed on your stack with role-based access and an audit trail. Third, we run it: evals, monitoring and an SLA. The standard is production in 90 days, at a fixed price, with money back if the proof of concept fails.
What questions should you ask any automation vendor?
Who owns the data and the model outputs? Where does it run? How do we prove what the agent did? What happens when it is wrong? How is it evaluated over time? What is the run cost, in full? Is the price fixed, and what is the guarantee? If a vendor is comfortable answering all seven, that is a good sign. If they steer you back to the demo, that is a sign too.
Start with a process worth automating
Map a costly manual process, scope a fixed-price build, and see the payback before you commit. If it is the wrong move, we will say so.