Building Reliable, yet Smart Workflows for Finance, Wealth and Insurance

Hello, I'm Karthic, CTO at Perpetual.

In this presentation, I'll talk about building workflows that are both reliable and intelligent for finance, wealth and insurance.

In regulated domains, workflows must be reliable enough to meet regulatory standards while still being intelligent enough to handle the real world.

In fields such as finance and wealth management, this presents both a technical and a compliance issue.

Reliability and intelligence are not opposites.

It is up to you where you draw the boundary between them.

And that is the point of this talk, deciding where that boundary lies.

For us, it's not merely a thought experiment, but a question that surfaces serious consequences.

Perpetual is a wealth management roll-up.

We acquire running traditional wealth management firms.

And we maximize their throughput and revenue with the help of AI.

Wealth management is a regulated industry.

And that is where we build with AI in production.

Everything in this talk is grounded in building for those constraints.

Workflows in finance and wealth management come with four facts,

and each of them pushes the architecture in the same direction.

First, they're complex and they need runtime strategies as the process unfolds.

You can't script every path in advance.

Second, the data is sensitive, so you need a path to move these workflows entirely onto privately hosted models.

Third, in a highly regulated industry, a policy violation isn't a bug report.

It has severe consequences.

So, fourth, execution has to be highly reliable and deterministic.

Inject intelligence only where runtime judgment is genuinely required

and minimize reliance on LLMs everywhere else.

AI is spreading through regulated industries,

but there's still no consensus on an architecture

that gives you high reliability with the least use of LLM intelligence.

Meanwhile, most of what developers hear from the big labs is how to burn more tokens.

But in a regulated industry, token maxing is the wrong goal.

These tasks are close to main.

You can lay them out in advance and build them into a massive state machine.

And that machine needs only a sprinkle of intelligence to navigate it.

Most steps just follow the next edge.

Only at a few judgment points does the model pick a branch.

So the intelligent way to build is to use intelligence minimally and on purpose.

Let's make this concrete with a real wealth management workflow.

A wealth advisor turns to their assistant and says one sentence.

Fill out the IRS W-9 for Mr. Harper to a person that's a simple instruction.

Watch what it actually triggers when a human being executes it.

The task has complexities that go beyond what meets the eye.

First, the assistant finds form W-9 from the firm's records or from the IRS website.

Then they look for Mr Harper in the system of record and find

three Harper households. So they call the advisor. Which Harper

do you mean? Only once that ambiguity is resolved do they move

on to the form. A lookup, an ambiguity and a human in the loop

all in the first minute of a one line task.

Filling a form sounds like data entry. It isn't. Every form is a

small program. A W9 first decides who the taxpayer is, the person or the owner if it's a disregarded

entity. A foreign person stops right here because they need a W8 instead. Then how they're taxed?

Exactly one box on line 3A and an LLC adds its letter. That decides which name goes on line 1

and which on line 2. Then whose number? An SSN or an EIN. Never both. Taken from a verified document.

never from memory. Exemption codes apply only to some entities and never to an S-corporation.

And finally, who signs under penalties of perjury? Each answer changes the next question

and the people involved only ever see three kinds of gates, a question, a document to collect, or

a signature. Now they start filling the form and realize the system of record is missing three of

the values it needs. They check the documents on file and the system of record again still

missing so they start an email thread with the client asking for exactly those three

values. The task now depends on someone outside the firm on their timeline.

now the workflow waits. The request is with the client and all three values are still

missing. If the client doesn't reply within two days, the assistant follows up and brings

it to the advisor at the daily stand up. If the client replies with only two of the three values,

they follow up again for the missing one. When all three arrive, they complete the form and write

the new information back to the system of record, including the trail of how they obtained those

values. In this industry, how you know a value matters as much as the value itself.

Once the form is filled, it goes out for e-signature.

If the client doesn't sign within a day or two, the assistant nudges them again.

Once it's signed, they file it for the client, send the acknowledgement and update the advisor

at the next day's stand-up.

One sentence from the advisor became a process that runs for days, crosses several systems,

weights on two people and loops back on itself more than once.

Look at what's inside that one sentence. Ambiguity to resolve

data together. Approvals, weights measured in days, follow-up loops and an

evidence trail at the end.

Workflow automation tools exist, but they rarely handle this real-world complexity and

ambiguity.

A fixed flowchart breaks at the first witch harbour and the lack of a native system of

record with an integration and an agent that improvises its way through is exactly what

a compliance team can't sign off on.

One breaks on ambiguity, the other can't be signed off.

neither handles what's inside that sentence. So what do we do about it? The fashionable framing

is more agency and better models. Given agent the whole task and wait for the next model to

make it reliable. The reflexive answer, especially inside regulated firms, is the opposite. Less

agency, more rules, lock it down and hard code every path. Both are the wrong axis.

In regulated verticals, reliability comes from where you place the boundary between the two,

between the parts that must be deterministic and the parts that genuinely need judgment.

Here's the principle.

Determinism governs control flow, evidence, and side effects.

What runs next, what we know, and how we know it, and anything that changes the world,

like a record written, an email sent, or a form filed.

Intelligence provides interpretation and judgment. Reading an ambiguous instruction, deciding which Harper, understanding a client's reply. The model answers a typed question and the deterministic system decides what to do with the answer and the interplay is recursive. A judgment can open a new smaller plan that's compiled, gated and deterministic again. You'll see that in a moment with follow ups. The boundary between the two is the design.

Here's how that works in the workflow engine we've built.

The request goes to a planner. That is a model call and its

only job is translation. It emits a typed semantic graph of

intents, entities, facts, artifacts, events, and

constraints, each grounded in the words of the request with any

any ambiguities it found. Every node points back to the words

it came from. That graph goes to a compiler that never calls a

model. In 11 deterministic stages, it turns the graph into

an execution tag or it fails closed. There are only three

verdicts. Valid needs clarification or refused.

Which Harper comes back as a question, not a guess. The plan is

is compiled, immutable and pinned by its hash.

The model translates. The plan is compiled. The compiler checks

the plan against the grammar. The vocabulary of what the firm

is allowed to do. 42 typed action contracts across forms,

documents, email, e-signature, calendar and human steps.

Each action the planner asks for has to match a contract. Here

form fill finds its forms contract and locks in. If the

planner asks for an action that isn't in the grammar or wires

one up wrong, the compiler refuses.

There are about 40 ways to fail closed from a cycle in the graph

to an unsupported action

And the same contract digest is pinned in the engine, the backend and the UI. So all three agree on what an action means. That is what a closed domain buys you. The model can only ask for things the firm already knows how to do safely. Here is a compiled plan for a W9 chase. Send the client the form, wait for it to come back, check it and file it.

Before anything runs, a person approves the plan itself.

Find the form, prepare it for the client to fill, render the PDF and draft the email.

Drafting is a model call, so it is violet.

Sending is an action gate. Nothing leaves the firm until a person approves that exact email.

Then the plan waits for a reply and a judge steps in to read it.

The returned form is verified. If it matches, it's archived behind another gate. If it doesn't,

the plan follows up. Now look at the dashed steps. Rendering the PDF, attaching it, judging the reply.

The planner never asked for them. The grammar added them because the contracts require them.

In the story, waiting, approvals, and follow-ups were most of the work.

Here there are nodes in the plan, not prompts. A reply wait defaults to 72 hours and an explicit

deadline can be anything from a minute to 30 days. When it passes, a rule decides what happens,

not a model. One approval covers the plan and every external action like sending an email or

a signature request has its own gate. The approval is tied to a hash of the exact payload and it's

checked again right before sending. When a client replies with only part of what we asked,

the reply judge marks it partial. That judgment is provisional. The step stays blocked until a

person confirms it. A person confirms it and the step unblocks. Then the follow-up runs as a new

child plan. The approved parent is never changed and there are at most five rounds.

Once a plan is approved, a state machine runs it. It picks every step and records every result.

When a step needs judgment, it makes one fixed schema model call. Compose an email, judge or

reply, spot missing values, extract fields, verify a document. The answer comes back typed,

and the state machine decides what to do with it. Side effects get a life cycle of their own.

Prepare, dispatching, succeeded, or when the world doesn't answer cleanly, outcome unknown,

and manual review. There are no automatic retries. A chat message can approve a step

or answer a question. It can't change an already approved plan. The model steers. It never drives.

Now look at what is left for the model to do. Outside the planner, the judgments are

small and typed. Is this reply complete? Does this document match? Which field is which?

They don't need frontier intelligence. A fast small model, the flash tier, can handle

them. In this illustrative run of 20 decisions, 19 go to the flash tier and one goes to the

frontier. That is why we designed for about 95% of model decisions in a workflow never

never needing a frontier model and the flash tier can run on

hardware you control. Only the genuinely hard cases go to a

frontier model.

the 5% is not a permanent tax because every judgment is

typed and logged and the provisional ones are confirmed

or rejected by a person. Each frontier decision produces

eval grade distribution real training data by construction.

That data can post train the flash tier. Logging and evals

exist today. The training loop is next. So the frontier share

shrinks release over release until even the hard cases run

locally.

Remember the requirement we started with because data is

sensitive. You need a path to move workflows entirely to

privately hosted LLMs. So can this design really get there? Take

one type call from the Harper Burbinine plan. Every model call

is small, typed and checked against a schema. So pointing it

at a privately hosted model is a configuration change, not a

rewrite. One line changes and the same answer comes back. Every

other call has that same small type shape. So the same change

applies to almost all of them.

That is how about 95% local inference becomes viable as an architectural consequence, not a policy promise.

That is the path that sensitive data demands and compliance risk goes down as an engineering roadmap, release by release.

So if you remember one thing, don't ask whether your system should have more agency or less.

Ask where the boundary is.

Let determinism govern control flow, evidence and side effects.

Let intelligence handle interpretation and judgment.

At typed points, you can inspect and use every judgment you log to need less of it next time.

Ask where the boundary is. Thank you.

I'm Karthic, CTO at Perpetual.