Fig. 1. OutcomeGuard: agentic customer-outcome assurance, orchestrated on UiPath Maestro.

Oliver Grant holds two policies with the same insurer — home and motor. That entitles him to a 10% multi-policy discount on his home premium. In September his home invoice came to 1,660.00 NZD. It should have been 1,494.00.

Oliver didn't notice. He never called, never emailed, never complained. And in most insurers today, that is where the story ends. Remediation usually starts with the customers who speak up. The quiet ones stay overcharged.

This article walks through one real run of OutcomeGuard, a control plane I designed and built on UiPath. A different customer's complaint starts a case. The case investigates across six business systems, works out who else the same defect reached, calculates exactly what each person is owed from the systems of record, asks a person to decide, pays through the legacy billing screen, checks the payment independently, and seals the evidence. Then it does the same for Oliver — who never asked.

Unless a caption says otherwise, every screenshot comes from a single recording of that run.

https://www.youtube.com/watch?v=wkoExGFbzNg

OutcomeGuard is a prototype built on synthetic data. Hana, Oliver and Alex are fictional customers of a fictional insurer. The orchestration, the agent, the human decisions, the robot, the refunds (in the synthetic billing system) and the evidence are all real.

1. The problem nobody owns

Insurers rarely let customers down on purpose. They let them down through change. A pricing rule is reconfigured, a release goes out, and a calculation that was right yesterday is quietly wrong today. Billing keeps producing invoices. Nothing crashes. No alarm goes off.

Then a few customers notice. Each complaint is handled on its own: someone checks the invoice, issues a credit, closes the ticket. What rarely happens is the obvious next question — who else did this reach? — answered with the same care, for every affected customer, with proof.

Regulators have noticed this gap. In New Zealand, the conduct regime for financial institutions, in force since 31 March 2025, requires firms to treat customers fairly through a fair conduct programme. In Australia, ASIC's Regulatory Guide 277 on consumer remediation expects firms to find everyone affected and put them back where they should have been. The direction is clear: remediation is a population problem, not a complaints problem — and it needs evidence. (Context only, not legal advice.)

The hard part isn't any single step. It's that the truth is spread across systems. Policy knows the correct price. Billing knows what was charged. Operations knows about the incident. Complaints knows who spoke up. No one system can answer the question that matters: who was harmed, by how much, and have we actually fixed it?

2. One rule for every component

I designed OutcomeGuard around a single principle, and every part of the system is held to it:

AI investigates. Code decides what's true. People decide. Robots execute. Something independent proves it.

An AI agent is very good at reading a messy situation and forming a hypothesis. It is not a source of financial truth, and it should never move money. So in OutcomeGuard the agent may only suspect. Deterministic code is the only thing allowed to calculate. A person is the only one allowed to approve. A robot is the only thing allowed to pay. And a separate check is the only thing allowed to say the payment happened.

That last sentence is the heart of the design. In a regulated process, the most important question about AI isn't how clever it is. It's where its authority ends.

3. Day one: what the business can see

The fictional insurer runs six business systems: Customer, Policy, Billing, Claims, Complaints, and Incident & Change. On day one, this is the picture.

Fig. 2. Day one. A pricing change, an incident with customer impact still unknown, the discount rule, and three qualifying customers. Oliver has no complaint on file.

On 16 September a configuration change, CHG-2026-0017, updated the Home multi-policy discount rule. Operations raised incident INC-2026-0042 — Billing discount calculation anomaly — and marked customer impact as unknown. The rule itself, RULE-DISC-001, is simple: 10% off Home Comprehensive for customers holding two or more active policies.

Three customers qualify. Alex complained in September and has already been refunded. Hana has just complained: "My September home insurance invoice is higher than I expected. I have my car insured with you too, so I thought I got a multi-policy discount." Oliver has said nothing.

Behind that briefing sit real systems of record. I call them the Synthetic Enterprise — six services, each owning its own data, with its own database.

Fig. 3. A test-harness view I built to stage and check the scenario. It isn't a business tool: on day one, no system the business uses shows this comparison. Producing it, with evidence, is what OutcomeGuard does.

Fig. 4. The complaints system holds Hana's complaint, CMP-30004. A complaint is a signal, not proof.

Fig. 5. Six business systems, a database and a gateway, each running as its own service.

One detail matters for everything that follows: a complaint is a signal, not proof. Hana believes she was overcharged. OutcomeGuard has to establish whether she was — from the systems that actually own the truth.

4. The architecture on one page

Fig. 6. OutcomeGuard reference architecture. The numbered badges follow one case from signal to closure.

Read the diagram top to bottom, from people and signals down to the systems of record.

• Orchestration. A UiPath Maestro Case holds the lifecycle: 11 stages and 20 tasks — Intake, Investigation, Impact Determination, Risk Review, Approval, Remediation, Verification, Population Review and Closure, plus two exception stages that end a case cleanly when a signal is invalid or evidence is missing.

• Reasoning. One agent investigates, governed by the UiPath AI Trust Layer: centralized guardrails check every model request and response, and every call goes through the LLM gateway.

• Deterministic truth. Ten Coded Functions (Python, no LLM) own every exact decision — validating the trigger, calculating impact, sizing the population, rating risk and conduct, closing the case, opening a programme and building the evidence pack. Every rule set is versioned.

• Integration. Three API Workflows read the systems of record through a read-only gateway that accepts HTTP GET and nothing else.

• Execution. One unattended RPA robot is the only component that writes to Billing — through the same legacy screen a clerk would use.

• Decisions. Two human gates in Action Center, built as custom Coded Action Apps.

• State and evidence. Data Fabric holds the signals, the live case record and a durable case ledger; a storage bucket holds each case's sealed evidence pack.

The red dashed line is the trust boundary. The cloud can read the systems of record, but it can never write to them. The only write path is the on-premises robot, through the legacy UI, carrying an approved amount.

5. The case plan

Fig. 7. The Maestro case plan. Required stages run every time; conditional stages run only when the rules call for them; exception stages end a case cleanly.

A case-management model fits this problem better than a fixed flowchart. The route depends on what the evidence shows and what people decide. A case with nothing to repay skips Approval, Remediation and Verification. A rejected approval skips the refund. And one case can start another.

Fig. 8. Deterministic gates. A stage completes only when a validated fact says so — for example evidenceComplete === true.

Every gate is a rule on a deterministic output. Investigation can complete only when the evidence is complete. Impact Determination completes only when the calculation is valid. The agent's opinion never opens a gate.

Fig. 9. Everything the case runs, in one Orchestrator folder: ten functions, three API workflows, one agent and one robot.

6. Hana's case, step by step

Here is one complete run. Each screenshot is labelled with the kind of evidence it represents — an observed signal, a system record, an agent finding, a deterministic calculation, a human decision, an execution result or a verification. In a regulated process those are not the same thing, and OutcomeGuard never lets one pass for another.

Step 1 — A signal starts the case

Hana's complaint arrives as a record in UiPath Data Fabric. The case is wired to start on that event (Data Fabric "record created"). In this recording it runs in Studio Web debug mode, so I start it by pressing Debug; deployed, it starts on its own. Nothing about the signal is trusted yet.

Fig. 10. Observed signal: Hana's complaint, recorded in Data Fabric, starts the case.

Step 2 — Intake: is this worth investigating?

A Coded Function checks that the signal carries enough context to investigate — a case type, a domain, a trigger type, a correlation ID and at least one business reference. If it doesn't, the case records a typed exception and ends. No guessing.

Fig. 11. Deterministic check: the trigger contains enough context to begin.

Step 3 — Evidence from eight sources

An API Workflow reads customer, policy, pricing (as of the invoice date), invoice, refunds, complaints, incident and change — and tags each section OK or NOT_FOUND. The case moves on only if the evidence needed for a calculation is complete.

Fig. 12. System records: billed 1,490, authoritative expected price 1,341 under RULE-DISC-001, evidence complete.

Every one of those reads is an HTTP GET through the gateway. Even if something upstream tried to change data, the path physically doesn't allow it.

Fig. 13. Read-only by construction: a GET through the gateway; credentials are redacted in the trace.

Step 4 — The agent investigates, inside the AI Trust Layer

Now the agent reads the evidence and explains what most likely happened. Before its request reaches the model, and again before its answer comes back, the AI Trust Layer runs centralized guardrails — prompt-attack detection, harmful-content checks and intellectual-property checks. Each check is recorded in the trace; in this run, every one passed.

Fig. 14. Governance evaluation: centralized guardrails on the request and the response, every check PASSED.

Fig. 15. Agent finding: a suspected cause tied to INC-2026-0042 and CHG-2026-0017, confidence HIGH — and an escalation, because the defect may reach other customers.

The agent's output is structured, with closed value sets — so a vague or lazy answer is rejected, not recorded. Its finding is always labelled suspected, not established. It can't compute an amount, propose a refund, or move the case forward. And it flagged the question that matters: this probably isn't just Hana.

Step 5 — Code decides what's true

Fig. 16. Deterministic calculation: billed 1,490.00 − authoritative 1,341.00 = 149.00; nothing refunded yet; 149.00 outstanding.

A Coded Function calculates the impact with exact decimal arithmetic, net of any earlier refunds. That choice means a customer who has already been made whole is never paid again: their outstanding amount is zero. The basis is written out in plain words and kept with the case, so anyone can check it later.

Step 6 — Who else?

This is where OutcomeGuard stops being a complaint handler. It asks the policy system which policies the same rule governed, then compares each one's authoritative price with what Billing actually charged.

Fig. 17. Deterministic calculation: the rule governed 5 policies; 3 customers were overcharged; 315.00 NZD is still owed across 2 customers.

Exposure is not harm. Five policies fell under the rule. Three were actually overcharged, one was not, and one had no invoice yet, so it couldn't have been. Of the three, Alex had already been refunded. That leaves Hana — and Oliver.

Step 7 — Risk and conduct

Fig. 18. Versioned rules rate the case HIGH: 149.00 exceeds the 50.00 auto-remediation limit, and the same defect reached three customers.

Fig. 19. Conduct assessment: MATERIAL, with a referral to Compliance to decide whether the matter is reportable.

Two versioned rule sets decide what happens next. Risk is HIGH, so a person must approve. Conduct is MATERIAL, so Compliance is told. Thresholds live in versioned rules, not in a prompt — none of this is the agent's judgement.

Step 8 — A person decides whether, never how much

Fig. 20. Human decision: the approver sees the calculation, the case facts and why approval is needed. The amount is calculated by code and is not editable.

The approval is a UiPath Action Center task with a custom app. Every amount on it is an input, so the approver decides whether OutcomeGuard pays — never how much. Both buttons stay disabled until the approver writes a reason, and that reason is kept word for word in the case and the evidence pack.

Fig. 21. Human decision: the reason is recorded verbatim, then confirmed in a second step that cannot be undone.

Step 9 — The robot pays through the legacy screen

Like many core systems, Billing has no refund API — it has a screen. An unattended UiPath robot opens it and keys in the refund exactly as a clerk would: the invoice, the approved amount, a reason code, the case number and an idempotency key derived from the case.

Fig. 22. The robot fills the legacy billing console. The screen's own controls: approved cases only, pays out once, bounded by payments, history preserved.

Fig. 23. Execution result: 149.00 NZD refunded on INV-10012, case 97713846, idempotency key 97713846-REFUND-1.

The idempotency key is a quiet but critical control. If the robot retries after a timeout, or anyone submits the same refund again, Billing returns the original refund instead of paying twice. The original invoice is never edited — the refund is its own record, so the history survives.

Step 9b — What if the refund runs twice?

Retries happen in real systems. A robot times out halfway, a job is restarted, someone resubmits a form because the screen looked frozen. So after the run I tried to pay Hana again on purpose — same invoice, same 149.00, same case number and the same idempotency key, 97713846-REFUND-1.

Fig. 23.a. A deliberate second attempt: the same invoice, amount, case and idempotency key the robot already used.

Billing refused to pay again. It created no new refund and returned the original one — the same refund ID the robot received, and the same refund the verification step had already read back.

Fig. 23.b. Execution result: "Refund Already Processed". No new refund was created; the original refund 9993e6f9… is returned.

Fig. 23.c. System record: Hana's invoice INV-10012 still has exactly one refund. A retry can never become a second payment.

This is the difference between "we try not to pay twice" and "we cannot pay twice". The protection doesn't depend on the robot being careful. It sits in the system of record, keyed to the case.

Fig. 24. A customer notice is drafted for Hana from a versioned template. Nothing is sent automatically.

Step 10 — Proved by someone other than the robot

Fig. 25. Verification: a separate API workflow reads the refund back from Billing — VERIFIED, 149.00 NZD, same refund ID.

A robot saying "done" is not proof. A different component reads the refund back from Billing through the read-only gateway and compares it with what was approved. Only a verified refund counts.

7. Oliver

Hana has been repaid. But OutcomeGuard checks the population again after her refund — and it still finds money owed.

Fig. 26. Re-check after Hana's refund: one customer is still owed 166.00 NZD.

Now a person decides what happens to everyone else. The reviewer sees exposure against harm, the overcharge per policy, and what the agent suspected — clearly labelled as a suspicion.

Fig. 27. Population review: 5 policies governed, 3 overcharged, 166.00 NZD still owed to one customer.

There are three choices: open a remediation programme, refer the population for analysis, or take no further action. The screen warns when "no further action" would leave someone unpaid.

Fig. 28. Human decision: open a remediation programme, with the reason recorded.

Opening the programme writes a brand-new signal — for Oliver. Nobody complained. The control plane raised it.

Fig. 29. The programme writes one new signal, for the one customer still owed, and that signal starts their case. The step is idempotent, so a retry can never create a second.

Fig. 30. Observed signal: Oliver's case, raised by the programme rather than a complaint.

Oliver's case then runs the same path, under the same controls. Nothing is copied from Hana's case — his amount is recalculated from the systems of record.

Fig. 31. Deterministic calculation: billed 1,660.00 − authoritative 1,494.00 = 166.00 NZD.

Fig. 32. Human decision: 166.00 NZD for a customer with zero complaints on file.

Fig. 33. The approver records why: a proactive refund, opened by the remediation programme.

Fig. 34. Execution result: 166.00 NZD refunded on INV-10013, idempotency key 95789802-REFUND-1.

After Oliver's refund is verified, the population is checked one more time.

Fig. 35. 0.00 NZD still owed across the population.

Fig. 36. Human decision: with nothing owed, the reviewer closes the programme.

Oliver's money came back. He never had to ask.

8. Proof, not prose

A case can't simply declare itself finished. Before it closes, a Coded Function checks the facts: was the evidence complete, was the impact established, was everything owed repaid and independently verified? If any answer is no, closure is refused.

Fig. 37. Closure rules (versioned): CLOSED_REMEDIATED_AND_VERIFIED, finding OVERCHARGE_REMEDIATED.

Every closed case then writes a sealed PDF evidence pack to a storage bucket and a durable row to the case ledger. The SHA-256 fingerprint of the pack is kept in the ledger. Change one byte of the PDF and the fingerprint no longer matches.

Fig. 38. Evidence pack stored, its SHA-256 recorded, a ledger row written.

Fig. 39. The case ledger in Data Fabric: one durable row per closed case.

Leaders and Compliance see the programme on a read-only oversight dashboard: who was affected, what's still owed, which cases closed, who decided, and the evidence behind each.

Fig. 40. Defect CHG-2026-0017: 3 customers affected, 0.00 NZD still owed, 315.00 NZD repaid by these two cases (Alex's 145.00 was repaid before OutcomeGuard ran: 460.00 in total), 2 cases closed, no exceptions.

Fig. 41. Every closed case with its approver, its verification and its evidence pack.

The evidence pack answers the questions an auditor actually asks — why we investigated, what we consulted, what was true, who decided, what was executed, and how we know — and labels every answer with its evidence class.

Fig. 42. The evidence pack: every section names its evidence class, so a suspicion is never mistaken for a fact.

Fig. 43. Tamper-evident: a SHA-256 of the case facts in the pack, and a hash of the PDF itself kept with the case.

Fig. 44. After OutcomeGuard: all three customers the change overcharged are repaid — 460.00 NZD in total. One of them never complained.

9. What the AI was not allowed to do

Most agentic demos show what the AI can do. In a regulated process, what it can't do matters more.

• It can't move money. It has no tool that writes anywhere. Its one tool reads evidence through a gateway that rejects everything but GET.

• It can't decide the amount. Arithmetic on money happens only in deterministic code.

• It can't open a gate. Whether a case moves forward is decided by rules on deterministic outputs.

• It can't certify its own work. Its finding is printed as "suspected, not established", and its confidence never becomes permission.

• It can't bypass governance. Every model call passes the AI Trust Layer's centralized guardrails and is traced.

The same discipline applies to everyone else. The approver can't change the amount. The robot can't choose what to pay. The verification workflow can't pay. No single component can complete the money path on its own — which is exactly what a risk or audit team wants to hear.

10. What building it taught me

Building this surfaced the kind of problems that never appear on a slide. Two of them are worth sharing.

A green job is not an answer. In one early run, the agent returned a placeholder — no cause, a status I hadn't defined — and the job still showed Successful, because its output contract accepted any text. Better prompting wasn't the fix. Closed value sets and required fields were: now a non-answer fails loudly instead of being recorded as fact. A related lesson: any free text an agent reads is part of its prompt, so signal text is treated strictly as a claim to verify.

Timing is a dependency; idempotency makes it safe. The case's own data record is created a moment after the case starts, so a very fast first task can arrive before it exists. A retry handles it — but only because every step is idempotent, so retrying is always safe.

11. Outcomes

• The whole affected population found from one complaint — including the customer who never complained.

• Every refund approved by a named person, with the reason recorded verbatim.

• No duplicate payments: impact is always net of earlier refunds, and every refund carries an idempotency key (tested deliberately, see Step 9b).

• Every refund verified independently of the robot that made it.

• Tamper-evident evidence for every closed case, each statement labelled with its evidence class.

• Speed: each case ran end to end in eight to nine minutes, human decisions included.

In production I would track time from defect to full remediation, the share of affected customers found without a complaint, refunds per approver hour, and audit findings per programme.

12. The road to production and beyond insurance

This prototype runs in a development tenant against a synthetic enterprise. Taking it to production means deploying the case properly, so a reviewer's decision starts the next customer's case on its own; connecting to real systems of record through durable, governed integrations; and agreeing thresholds and rule sets with Risk and Compliance.

Nothing in the pattern is specific to insurance. A bank fee applied to the wrong accounts, a telco plan billed at the wrong rate, a utility tariff misapplied after a system change — each is the same problem: find everyone a change harmed, calculate from authoritative data, let people decide, execute safely, and prove it.

Key terms

Agentic automation:

Automation where an AI agent reasons and investigates, while deterministic tools, people and robots handle facts, decisions and actions.

Maestro Case:

UiPath's long-running case management. It holds a case's state and moves it through stages based on rules.

AI Trust Layer:

UiPath's central governance for AI: guardrails on every model request and response, approved models and regions, and an audit log.

Coded Function:

A small piece of deterministic code (here, Python) that gives the same answer for the same input — no AI involved.

API Workflow:

A workflow that calls system APIs; here it only reads, through a GET-only gateway.

Action Center:

Where UiPath sends tasks that need a human decision.

Idempotency key:

A unique key on an action, so repeating it can never create a second payment.

Trust boundary:

The line between what the cloud can do (read) and what only the on-premises robot can do (write).

Evidence class:

The kind of statement something is — a signal, a system record, a calculation, an agent finding, a human decision, an execution result or a verification.

Closing

The interesting question in enterprise AI is not how clever the agent is. It's where its authority ends. OutcomeGuard draws that line explicitly: AI investigates, code decides what's true, people decide, robots execute — and something independent proves it.

Oliver will never know any of this happened. His money just came back. That is the point.

Designed and built by Jobin Thekkekara Joy, Solution Architect.

Built with UiPath Maestro (Case Management), Agents, the AI Trust Layer, Coded Functions, API Workflows, RPA, Action Center, Data Fabric and Orchestrator. The synthetic enterprise runs on FastAPI, PostgreSQL and Docker. Prototype on synthetic data; customers are fictional; regulatory references are context, not legal advice. Not affiliated with or endorsed by UiPath.