RAG, AI agents and RPA: choosing the right automation approach

Start with the work, not the technology label

Use RAG when people need answers from governed knowledge. Use APIs for stable system actions and RPA when a legacy user interface is the only practical route. Add an AI agent only when the workflow genuinely requires contextual judgement or a dynamic path.

These approaches are not interchangeable, and they are not mutually exclusive. A useful production workflow often combines them while keeping each responsibility visible.

Put judgement where it adds value. Keep validation and consequential system actions deterministic.

Which approach fits which use case?

Use RAG for governed knowledge, not automatic truth

RAG is useful when staff need natural-language access to private or changing information such as policies, procedures, product records, project documents, or technical manuals. It can make answers easier to find and verify without retraining a model whenever a document changes.

Do

• Assign owners to source documents and define effective dates, metadata, versions, and removal rules.
• Preserve document permissions at retrieval time so users only receive evidence they are authorised to see.
• Test retrieval separately from answer quality. First ask whether the right evidence was found; then ask whether the answer is grounded in it.
• Show citations and provide a safe “not enough evidence” response.

Do not

• Upload an uncontrolled folder and treat ingestion as completion.
• Let the search index bypass source-system access rules.
• Judge quality only by fluent writing. A polished answer based on the wrong passage is still wrong.
• Use RAG alone to calculate, approve, or update a business record.

Use an agent when the workflow must decide

An agent earns its complexity when the task contains ambiguous input, several possible paths, changing context, or tool selection that cannot be represented safely as one fixed sequence. Start with one bounded agent and a small tool set before considering a multi-agent design.

Make tools narrow: retrieve a case, validate an identifier, calculate an amount, create a draft, or submit an approved update. Give the agent the minimum data and permissions it needs. Separate read tools from write tools, validate tool inputs, cap transaction scope, and require a responsible person to approve sensitive or irreversible actions.

Prompt injection cannot be solved by filtering alone. Treat it as a containment problem: even if hostile text influences the model, the agent should not have enough access to expose sensitive data or perform an unauthorised action.

Keep execution predictable with APIs and RPA

A supported API is usually the cleanest foundation for repeatable system actions because it provides an explicit contract that can be validated, logged, retried, and monitored. Make retries safe, reject invalid inputs, use correlation identifiers, and reconcile results against the system of record.

RPA remains valuable when the business action is available only through a legacy screen or virtual desktop. Isolate those UI steps, use stable selectors, log business and application exceptions, and maintain a manual fallback. Do not imitate human clicks when a reliable governed API already provides the same operation unless a documented constraint justifies it.

Example: resolving an emailed service request

1. RAG retrieves the current policy and relevant agreement with permission filtering.
2. An agent interprets the unstructured request and identifies missing information.
3. A deterministic API reads the account and calculates eligibility.
4. A person approves the recommendation when value or risk crosses a defined threshold.
5. An API workflow performs the update; RPA is used only for any remaining UI-only step.
6. The workflow records the evidence, decision, approval, action, outcome, elapsed time, and exception status.

This separation keeps probabilistic reasoning where it helps and deterministic controls where correctness, authorisation, and auditability matter.

Measure benefit at the workflow level

Baseline transaction volume, cycle time, manual handling, error and rework, exception rate, review effort, service level, and operating cost before building. After launch, measure accepted outcomes rather than conversations, tokens, tool calls, or robot runs.

• accepted outcomes completed per period;
• end-to-end cycle time and manual time saved;
• straight-through completion and human-assisted completion;
• error, rework, exception, and escalation rates;
• adoption by intended users;
• cost per accepted outcome, including infrastructure, model use, retries, and human review;
• blocked actions, permission failures, and other risk indicators.

A five-step selection test

1. If people only need answers from approved content, begin with governed retrieval.
2. If the work follows a known path, automate it deterministically through an API or workflow.
3. If the required action is UI-only, use RPA for that bounded step.
4. If contextual judgement changes the path, evaluate an agent with narrow tools and explicit exit conditions.
5. If an action is consequential, place deterministic checks and human approval before execution.

Primary references

• Microsoft: RAG solution design and evaluation
• OpenAI: A practical guide to building agents
• UiPath: API automation and UI automation