Workflow automation, RPA and AI agents are three different answers to the same complaint: too much of the working day is spent moving information between systems that were never introduced to each other. The complaint is real. The confusion is that vendors in all three categories answer it with the same slide, the same efficiency figure and the same promise about freeing people for higher-value work.
They are not interchangeable. One is a rules engine that routes work between applications through APIs. One is a robot that drives an application’s screen because there is no API to route through. One is a model that decides what to do next, which is a genuinely different proposition with genuinely different failure modes. Picking the wrong one is not a preference error, it is a budget error that shows up eighteen months later as a maintenance bill nobody forecast.
This guide is the working comparison: what each approach is, what it costs, how each one breaks, how to choose between them for a specific process, and how to combine all three in the same workflow without creating something nobody can support. It draws on our workflow automation, RPA and intelligent automation practice, and it is written for mid-sized organisations choosing where to spend a first serious automation budget. For the strategic view of where automation fits alongside everything else, our digital transformation work covers the wider ground.
Table of contents
- What workflow automation, RPA and AI agents actually do
- Workflow automation vs RPA vs AI agents at a glance
- Where workflow automation, RPA and agents each break down
- Choosing between workflow automation, RPA and AI agents
- What workflow automation costs against RPA and AI agents
- Reliability: how workflow automation and agents fail differently
- Maintenance after go-live: workflow automation versus bots
- Integration: why workflow automation wins wherever APIs exist
- Governance and audit trails across workflow automation and agents
- Security: the exposure workflow automation avoids and agents create
- Combining workflow automation, RPA and AI agents in one process
- A 90-day plan to pilot workflow automation or an agent
- Skills and the operating model behind workflow automation
- Mistakes that waste a workflow automation budget
- Frequently asked questions about workflow automation, RPA and AI agents
- References
What workflow automation, RPA and AI agents actually do
The three categories overlap in marketing and separate cleanly in engineering. The useful distinction is not what they promise but what makes the decision at each step, and what they touch when they act.
Workflow automation orchestrates through APIs
A workflow automation platform holds the process definition — the steps, the branches, the approvals, the timers, the retries — and calls each system through its API. Nothing is guessed. A form submission triggers a record creation, a routing rule picks the approver, a timer escalates after two days. Power Automate, Zapier, Make, n8n, Camunda and Temporal all sit in this family despite very different price points and target users.
RPA drives the screen when there is no API
Robotic process automation automates the interface a human would use: it opens the application, finds the field, types the value and clicks the button. That is why it exists — it reaches systems that expose no integration surface at all, including terminal emulators, desktop clients and web portals belonging to third parties. The robotic process automation category grew almost entirely out of that gap, and vendors like UiPath and Microsoft’s Power Automate desktop flows still frame it that way.
AI agents decide the sequence themselves
An agent is given a goal, a set of tools and a context, and it chooses which tool to call in what order. The sequence is not written down in advance, which is exactly the point when the input is unstructured — an email thread, a supplier PDF, a customer complaint — and exactly the risk when the action is irreversible. Everything else in this guide follows from that single property.
The property that separates them is determinism
Workflow automation and RPA are deterministic: the same input produces the same path every time, and when it does not, something broke and you get an error. An agent is probabilistic: the same input can produce a different path, and a wrong answer often looks exactly like a right one. That difference drives cost, testing, governance and the entire oversight model.
Where “intelligent automation” fits
Intelligent automation is the umbrella term for combining them — a deterministic spine that calls a model for the one judgement step that genuinely needs it. It is not a fourth category to buy, it is an architecture, and it is where most mature programmes end up.
Workflow automation vs RPA vs AI agents at a glance
The table below is the summary most teams need before a scoping conversation. Everything in it is expanded later, but the shape of the decision is visible immediately.
| Factor | Workflow automation | RPA | AI agents |
|---|---|---|---|
| What decides each step | Rules you wrote | Rules you wrote | A model, at run time |
| What it touches | APIs, webhooks, queues | Screens, keyboard, files | Tools and APIs you expose |
| Input it handles well | Structured records | Structured, on a screen | Unstructured text and documents |
| Same input, same output | Always | Always | Not guaranteed |
| Typical build time | Days to three weeks | Two to eight weeks | Six to sixteen weeks |
| Breaks when | An API contract changes | A screen changes | The input drifts from what was tested |
| Failure is | Loud — a logged error | Loud — a stuck robot | Quiet — a plausible wrong answer |
| Audit trail | Native, step by step | Native, action by action | Needs deliberate instrumentation |
| Who can maintain it | A trained business analyst | An RPA developer | An engineer plus an evaluation owner |
| Best first use | Approvals, onboarding, handoffs | Legacy data entry and reconciliation | Triage, summarising, drafting |
Read the table as a sequence, not a menu
The order matters. Ask whether workflow automation can do it, because it is the cheapest to build and the cheapest to own. Only when the answer is no because there is no integration surface should RPA enter the conversation. Only when the answer is no because the step needs judgement over unstructured input should an agent.
Most processes are a mix of all three
A single end-to-end process rarely belongs to one category. Invoice handling is agent work at the extraction step, workflow automation at the approval and posting steps, and occasionally RPA at the one supplier portal with no API. Choosing per process is the common mistake; choose per step.
Where workflow automation, RPA and agents each break down
Every category has a failure mode that its own vendors do not lead with. Knowing them in advance is worth more than any feature comparison, because they determine the support cost you inherit.
Workflow automation stalls at the system with no API
The honest limit of workflow automation is reach. If a system exposes nothing — no REST API, no webhook, no database access, no export — the platform has nowhere to connect and the process stops at that boundary. This is the specific gap RPA was invented to fill, and it is the only strong reason to introduce robots.
It also degrades into connector sprawl
The second failure is organisational. Low-code platforms make the first fifty automations trivial and the next two hundred ungoverned. Nobody knows what runs, who owns it, or which service account it uses. A workflow automation estate without an inventory becomes a category of shadow IT that fails an audit rather than a productivity gain.
RPA breaks whenever the screen moves
An RPA robot depends on the position, name or structure of interface elements. A vendor releases an update, a field moves, a pop-up appears, and the robot stops or — worse — types the right value into the wrong box. Teams running large estates plan for a steady stream of this work, and it is why RPA maintenance is consistently underestimated in business cases.
RPA also encodes a bad process permanently
Because a robot mimics the human path exactly, it preserves every workaround built up over a decade of policy changes. Automating a broken process makes it fast and permanent. A workflow automation redesign at least forces someone to write the rules down, which usually exposes three steps that exist for no current reason.
Agents fail quietly, which is the expensive kind
A deterministic automation that fails tells you. An agent that misreads a contract clause produces a confident, well-formatted, wrong answer that flows straight into the next step. Detecting that requires sampling, evaluation sets and monitoring designed in from the start — the practices covered in our guide to monitoring AI agents in production.
Agents also cost per run, forever
Deterministic automation has an almost free marginal execution. An agent pays for tokens on every run, and the cost rises with context length, retries and tool calls. At low volume this is irrelevant. At a million executions a year it becomes the dominant line in the business case, and it does not fall with scale the way licence costs do.
Choosing between workflow automation, RPA and AI agents
The decision is easier than the market makes it look, because three questions settle almost every case. Ask them in order and stop at the first one that gives a clear answer.
Question one: is there an API?
If every system in the process exposes an API or webhook, workflow automation is the default and the other two need to justify themselves. If one system does not, you have a choice between RPA, a data export workaround, or paying the vendor for integration. Do not skip that third option — an integration project is often cheaper over three years than a robot maintained forever.
Question two: can you write the rule down?
If a competent colleague can state the decision rule in a sentence — approve under £500, route to the regional team, reject if the VAT number is missing — it is deterministic work and belongs in a workflow. If the rule genuinely requires reading and judgement, an agent earns its place. Most steps that feel like judgement turn out to be an unwritten rule nobody has bothered to state.
Question three: what does a wrong action cost?
Payments, contracts, patient data and anything irreversible demand a deterministic path with an explicit human approval. Drafting, triage, classification and summarising are cheap to get wrong and easy to correct, which is why they are where agents pay back fastest. Our human-in-the-loop AI workflows guide covers where to place the checkpoint.
| If the process looks like this | Start with | Because |
|---|---|---|
| Structured data, APIs on both sides, clear rules | Workflow automation | Cheapest to build, cheapest to own, fully auditable |
| Legacy or third-party system with no integration surface | RPA | Only option that reaches the screen |
| Free-text email, PDFs, scanned documents | AI agent for extraction only | Rules cannot parse unstructured input reliably |
| High volume, low variation, strict SLA | Workflow automation | Predictable cost and latency per execution |
| Low volume, high variation, expert judgement | AI agent with review | Rule maintenance would exceed the saving |
| Irreversible financial or legal action | Deterministic path plus human approval | The cost of one wrong action dominates |
| Process changes every quarter | Workflow automation | Editing a rule is minutes; retraining trust is months |
| Nobody agrees what the current process is | Neither — map it first | Automation multiplies whatever is already there |
Volume decides more than sophistication
Run the arithmetic before the architecture. Two hundred executions a month rarely justifies anything beyond a low-code workflow automation flow, whatever the process looks like. Two hundred thousand justifies engineering effort in whichever category fits, because a penny per execution becomes a real number.
The build-versus-buy question sits underneath all three
Every category has a buy option and a build option, and the trade-offs are the same ones covered in our build vs buy vs low-code decision framework. Choosing the technology and choosing the delivery model are separate decisions, and conflating them is how organisations end up with a bespoke platform to maintain and no automations running on it.
What workflow automation costs against RPA and AI agents
Costs split into four lines that behave very differently: build, licence, run and maintain. Comparing platforms on licence alone is the most common way to get this wrong, because it is the line where the three categories differ least.
The four cost lines
Build is one-off engineering. Licence is the platform or per-robot fee. Run is the marginal cost of each execution — near zero for deterministic tooling, real for models. Maintain is the annual rework caused by changes around the automation, and it is the line that separates a good workflow automation business case from a bad RPA one.
| Cost line | Workflow automation | RPA | AI agent |
|---|---|---|---|
| Build, per process | £3k–£15k | £8k–£30k | £15k–£60k |
| Platform or licence, per year | £1k–£25k | £4k–£8k per unattended robot | £0–£10k tooling |
| Marginal cost per execution | Effectively nil | Effectively nil | £0.01–£0.50 |
| Annual maintenance | 10–15% of build | 20–30% of build | 25–40% of build |
| Oversight effort | Exception queue only | Robot monitoring | Sampling, evaluations, drift checks |
| Time to first measurable saving | 2–6 weeks | 6–12 weeks | 10–20 weeks |
These are planning ranges we use when scoping UK mid-market work, not quotations and not survey data. Use them to size a business case and to sanity-check a proposal, then replace them with real numbers as soon as you have them. The method for turning them into a defensible case is in our guide to calculating enterprise AI ROI.
First-year cost lands roughly three to one
Taking a mid-range process through build, licence and first-year maintenance, the three approaches separate cleanly, and the gap is wider than most first business cases assume.
The saving side is where most cases are dishonest
Hours saved is not money saved unless a cost actually leaves the organisation or capacity is redeployed to something measurable. A workflow automation case built on twenty people each saving fifteen minutes a day will not survive contact with a finance director. Cases built on cycle time, error rates, penalty avoidance or headcount not hired do survive.
Watch the second-order costs
Service accounts, licences for the systems the robots log into, storage, monitoring, and the analyst time spent reviewing exceptions all belong in the model. On agent work, add evaluation development and the cost of the review capacity that makes the output safe to use.
Reliability: how workflow automation and agents fail differently
Reliability is where the categories genuinely diverge, and where the comparison stops being a matter of taste. The question is not which fails more often, it is which failures you can see.
Deterministic failure is visible failure
When a workflow automation step fails, there is an error, a retry, a queue and an alert. Nothing silently produces the wrong result, because there is no mechanism for it to do so — the path is fixed. Operational monitoring is therefore conventional, and the golden-signals approach set out in Google’s SRE book transfers directly.
RPA failure is visible but frequent
Robots fail loudly too, but the trigger is outside your control: someone else’s release schedule. That makes RPA reliability a function of how often the systems underneath change, which is why estates built on stable internal legacy applications behave far better than estates built on third-party web portals.
Agent failure is a quality problem, not an outage
An agent rarely goes down. It produces output that is fluent, structured, and sometimes wrong, and no infrastructure alert fires. Catching that needs an evaluation set, sampled human review and drift monitoring on the inputs — practices covered in our guide to testing AI agents before production and formalised in the NIST AI Risk Management Framework.
Design the exception path first
Whatever the numbers turn out to be in your environment, something must catch the remainder. An automation with no defined exception route does not save work, it relocates it into somebody’s inbox and hides it. Write the exception path before the happy path, in all three categories.
Measure the same way across all three
Use one set of metrics — completion rate, exception rate, cycle time, cost per execution, rework rate — so that a workflow automation flow, a robot and an agent can be compared on the same dashboard. Category-specific vanity metrics like “hours returned” make that impossible.
Maintenance after go-live: workflow automation versus bots
The business case is written on build cost. The regret is written on maintenance. Over a three-year horizon, the maintenance line typically overtakes the build line for RPA and agents, and rarely does for workflow automation.
What triggers rework in each category
Workflow automation reworks when an API contract changes or the business rule changes — both are announced and both are rare. RPA reworks when any screen in the path changes, which is neither announced nor rare. Agents rework when the input population drifts, a model version is retired, or an evaluation exposes a regression.
Ownership decays faster than technology
The most common cause of a dead automation is not a technical break, it is that the person who built it changed role. Name an owner per automation, record it in the inventory, and review the list quarterly. This is unglamorous and it is the single highest-return governance habit in the whole programme.
Retirement is part of maintenance
Processes get replaced, systems get migrated, and automations outlive their purpose while still consuming licences and service accounts. Every workflow automation inventory should carry a retirement decision, and anything running against a system scheduled for replacement should be flagged before the migration, not after.
Budget maintenance explicitly
Put a maintenance percentage in the business case from day one, sized by category, and hold a standing allocation of developer time against it. Programmes that fund only new builds accumulate a backlog of broken automations and quietly lose the trust that made the second wave possible.
Integration: why workflow automation wins wherever APIs exist
The integration surface available to you is the strongest single predictor of which approach will succeed, and it is knowable before any vendor conversation starts.
Audit the integration surface first
For every system in the process, record whether it offers a REST API, a webhook, a supported export, database access, or nothing at all. That one-page audit will assign most steps to a category on its own, and it takes an afternoon. Workflow automation covers every row that has an API; the rows with nothing are your RPA candidates or your integration backlog.
Prefer an integration project to a permanent robot
If a vendor sells an API module for a fee that is less than three years of robot maintenance, buy the module. Organisations routinely pay for robots forever to avoid a one-off integration cost, which is a false economy visible only when the maintenance line is modelled honestly. Our legacy modernisation guide covers when the underlying system is the real problem.
Treat RPA as a bridge with an expiry date
Where a robot is genuinely the only option, record why, and record what would remove the need — an API on the roadmap, a system replacement, a supplier change. RPA used as a deliberate bridge is sound engineering. RPA used as a permanent substitute for integration accumulates into an estate nobody can safely change.
Orchestration platforms are the durable layer
The workflow automation layer tends to outlive the components it calls. Whether the extraction step is a model today and a different model in two years, or the data-entry step is a robot today and an API tomorrow, the process definition, the retries and the audit trail survive. Engineering-grade tooling such as Temporal and Apache Airflow is built on exactly that assumption.
Model the process in a standard notation
Where a process crosses teams, model it in BPMN before choosing tooling. It sounds heavy for a small automation and it repeatedly earns its keep, because it separates the process from the product and makes a platform migration a re-implementation rather than a rediscovery.
Governance and audit trails across workflow automation and agents
Auditors do not care which category you chose. They care whether you can show who authorised an action, what data it used, and what it did — for every execution, months later.
Deterministic tooling gives you the trail free
A workflow automation platform records each step, its inputs, its outputs and its timestamps as a matter of course, and RPA platforms log every action a robot takes. That evidence is usually sufficient for financial controls with no additional engineering, which is a genuine and underrated advantage.
Agents need the trail designed in
For an agent you must decide what to capture: the prompt, the context retrieved, the tools called, the arguments, the output, the model version and the reviewer’s decision. Nothing captures that by default. The OpenTelemetry GenAI semantic conventions are the practical starting point for what a span should carry.
Know which rules apply before you build
Automated decisions affecting individuals attract specific obligations under UK GDPR, and the ICO’s guidance on AI and data protection is the reference. Organisations selling into the EU should also read the EU AI Act framework, since obligations attach to the use case, not the vendor.
One inventory covers all three categories
Maintain a single register: what it does, which systems it touches, what data it processes, who owns it, which category it is, when it was last reviewed. Splitting the register by technology is how the workflow automation estate ends up governed and the robots do not. Our AI governance framework for SMEs guide covers the surrounding structure.
Approvals belong to people, not machines
Wherever an approval carries legal or financial weight, the automation should prepare the decision and a named person should make it. That pattern keeps the accountability chain intact and, in practice, gets automation through risk committees that would reject a fully autonomous design.
Security: the exposure workflow automation avoids and agents create
Each category has a different attack surface, and the differences are large enough to change an architecture decision.
Robots hold human credentials
An RPA robot logs in as a user, often with broad permissions, frequently with a shared account. That is a privileged identity operating unattended, and it deserves vaulted credentials, dedicated accounts and session recording. Shared robot logins are one of the most common findings in an automation security review.
Workflow automation concentrates connector permissions
Connector consent in a low-code platform can grant far wider access than the flow actually needs, and those permissions persist after the flow is retired. Review scopes at creation, prefer service principals with least privilege, and audit the connector inventory on the same cycle as user access.
Agents introduce prompt injection
Any agent that reads external content — email, web pages, supplier documents — can be instructed by that content. Where the agent also holds tools that write or pay, the consequences are direct. The OWASP Top 10 for LLM applications catalogues the pattern, and the NCSC guidelines for secure AI system development set out the controls.
Constrain tools rather than trusting instructions
The reliable control is not a better prompt, it is a smaller blast radius: read-only tools by default, allow-lists on write actions, spending limits, and a deterministic approval step in front of anything irreversible. Tool design guidance from vendors such as Anthropic’s tool use documentation is worth reading before the first agent goes near production.
Log enough to investigate
If something goes wrong at three in the morning, you need to reconstruct what ran, with what inputs, under whose identity. Deterministic automation usually gives you that. For agents, budget the instrumentation as part of the build, not as a later hardening exercise.
Combining workflow automation, RPA and AI agents in one process
The mature pattern is not a choice between three categories but a layered design where each does the part it is good at. This is what “intelligent automation” means once the marketing is removed.
The layered pattern
Put the deterministic spine in charge. The workflow automation platform holds the process, triggers each step, enforces the rules and keeps the audit trail. It calls a model for judgement over unstructured input, and a robot for the one system with no API. Both are subordinate components with defined inputs and outputs, not owners of the process.
| Layer | Owns | Built with |
|---|---|---|
| Trigger | Events, schedules, form submissions | Workflow automation platform |
| Understanding | Reading documents and free text | AI model or agent, confidence scored |
| Decision | Applying the business rule | Deterministic rules in the workflow |
| Action | Writing to systems of record | APIs first, RPA only where forced |
| Oversight | Approvals, exceptions, sampling | Human queues in the workflow |
| Evidence | Audit trail and metrics | Platform logs plus agent tracing |
Keep the model out of the decision
The strongest version of this pattern uses the model to extract and classify, and leaves the decision to written rules. The agent says “this is an invoice for £4,120 from supplier X with purchase order Y”; the workflow decides whether that can be paid. Confidence stays measurable and the audit trail stays deterministic.
Route low confidence to a person
Every extraction step should emit a confidence signal, and everything below the threshold should go to a human queue rather than onward. Tune the threshold with real volumes in the first month — set too high it drowns the team, set too low it lets errors through, and only production data tells you where it sits.
Sequence the rollout
Deploy the deterministic spine first and run it with humans doing the judgement step. Add the model once the process is stable, behind a review queue, and only then reduce review as the evaluation data earns it. Teams that start with the agent spend months debugging a process problem they mistake for a model problem. The organisational side of this is covered in our AI agent operating model guide.
A 90-day plan to pilot workflow automation or an agent
Ninety days is enough to prove or kill an approach on one real process, provided the scope stays narrow and the measurement starts before anything is built.
| Weeks | Activity | Output |
|---|---|---|
| 1–2 | Pick one process, measure it as it runs today | Baseline: volume, cycle time, error rate, cost |
| 2–3 | Audit the integration surface for every system | API or no API, per step |
| 3–4 | Apply the three questions, assign a category per step | Target design on one page |
| 4–8 | Build the deterministic spine, humans in judgement steps | Working workflow automation in production |
| 8–10 | Run in parallel with the manual process | Comparison against the baseline |
| 10–12 | Add the model or robot to the one step that needs it | Evaluation set and review queue |
| 12–13 | Decide: scale, adjust or stop | Costed recommendation with evidence |
Measure before you build or you cannot prove anything
The baseline is the deliverable most pilots skip and most business cases later need. Two weeks of counting — how many, how long, how often wrong, at what cost — converts the whole exercise from opinion into evidence, and it costs almost nothing.
One process, end to end, beats five demos
A pilot that automates one process completely tells you what the second one will cost. Five partial automations tell you nothing and leave five half-finished things in production. Depth first, breadth second.
Write the stop criteria at the start
Decide in week one what result would make you stop. Without that, every pilot succeeds, because the criteria are written after the numbers are known. Stop criteria are the difference between a pilot and a commitment with extra steps.
Skills and the operating model behind workflow automation
The technology choice is the easy half. What determines whether a second wave happens is who owns the automations and how new ones get approved.
Workflow automation can sit with the business, with guardrails
Low-code platforms genuinely let analysts build useful automations, and that is where the volume comes from. It works when there is a central inventory, a naming convention, a review before anything touches a system of record, and a service-account policy. It fails when the platform is opened to everyone with no register.
RPA needs a developer discipline
Robots are software and behave like it: version control, environments, testing against a staging system, release notes. Estates run as a business-user activity accumulate undocumented robots that nobody dares to change, which is how RPA earned its reputation for technical debt.
Agents need an evaluation owner
Someone must own the evaluation set, review sampled outputs, and hold authority to pause the agent. That role does not exist in most organisations before the first agent ships, and appointing it afterwards is how quality problems run for a quarter before anyone notices.
A small central team beats a large committee
Two or three people who own the platforms, the inventory and the review gate can support a surprising amount of workflow automation across a mid-sized organisation. A monthly board that approves automation requests without owning delivery adds latency and no quality.
Train for the exception, not the demo
The people who will live with an automation need to know what it does, how to spot a failure and what to do when it stops. Training that shows only the happy path produces users who quietly build a manual workaround the first time an exception appears.
Mistakes that waste a workflow automation budget
These are the failures that recur across programmes regardless of the technology chosen, and every one of them is avoidable at the planning stage.
Automating a process nobody has mapped
If two people describe the current process differently, automation will encode whichever version the builder heard. Map it, agree it, simplify it, then automate — and expect to delete steps that exist only because a form used to be paper.
Buying the category the loudest vendor sells
An RPA vendor will find an RPA-shaped problem, and an agent vendor will find an agent-shaped one. Run the three questions yourself, with the integration audit in hand, before any demo. The answer frequently turns out to be plain workflow automation on systems you already own.
Ignoring the exception queue
Every automation creates exceptions, and those exceptions are work. Unowned, they become a backlog that erodes the saving and the credibility of the programme together. Size the queue and staff it explicitly.
Treating an agent as a cheaper robot
Agents are not a drop-in replacement for deterministic automation, and using one where a rule would do buys variability, run cost and an oversight burden for no benefit. The reverse error — forcing rules onto genuinely unstructured input — produces a rule set that grows forever and is abandoned within a year.
Skipping the data question
Automation moves data between systems, and if the underlying records are inconsistent the automation propagates that at speed. Where records disagree across systems, settle the single source of truth question first, and for anything model-driven check the readiness work in our AI-ready data checklist.
Declaring victory at go-live
The automation that runs on launch day is not the automation that runs in month six. Review the inventory quarterly, retire what is dead, and re-measure against the baseline. Programmes that do this compound; programmes that do not restart every two years with a new vendor.
Frequently asked questions about workflow automation, RPA and AI agents
Is RPA obsolete now that AI agents exist?
No, and the framing is wrong. RPA solves a connectivity problem — reaching a system with no API — while agents solve a comprehension problem. An agent that needs to use a legacy screen still needs something to drive that screen. RPA’s role is narrowing to that bridge, which is the role it should always have had.
Can workflow automation handle documents and email?
Only the structured parts. A workflow automation platform can route an email, attach it to a case and trigger an approval, but it cannot reliably read a supplier’s non-standard invoice layout. Pair it with an extraction model and keep the decision in the rules.
What should we automate first?
The process with high volume, low variation, clear rules and a measurable baseline — typically onboarding, approvals, or a reconciliation. It is rarely the most painful process, because pain usually correlates with complexity and ambiguity, which makes for a poor first result.
How many people do we need to run this?
For a first year in a mid-sized organisation, one delivery lead plus one builder is enough to run a workflow automation programme of ten to twenty automations, with specialist help for the RPA or agent components. The constraint is usually access and process ownership, not developer capacity.
Do we need to buy a platform before starting?
No. Most organisations already own a capable workflow automation platform inside Microsoft 365 or their ERP and have never inventoried what it can do. Prove one process on what you have, then buy deliberately when a real constraint appears.
How do we stop low-code sprawl?
A register, a naming convention, a named owner per automation, and a review gate for anything that writes to a system of record. Four lightweight controls, applied from the first automation, prevent the estate that costs a year to untangle later.
What does good look like after twelve months?
Ten to twenty automations in production with named owners, a measured baseline for each, an exception queue that is staffed and shrinking, one or two model-assisted steps under review, and a retirement list. That is an unglamorous picture and it is what a working programme actually looks like.
References
Robotic process automation — overview
OMG — Business Process Model and Notation (BPMN) 2.0
Microsoft — Get started with Power Automate
Microsoft — Introduction to desktop flows
Camunda — process orchestration
Temporal — understanding durable execution
NIST AI Risk Management Framework
OWASP Top 10 for Large Language Model Applications
NCSC — Guidelines for secure AI system development
ICO — Artificial intelligence and data protection
European Commission — Regulatory framework for AI
OpenTelemetry — GenAI semantic conventions
Google SRE Book — Monitoring distributed systems
Anthropic — Tool use overview
GOV.UK — AI Playbook for the UK Government
