Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual

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 W-9 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 W-8 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 one and which on line two. 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.

And 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 standup. 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 standup. One sentence from the advisor became a process that runs for days, crosses several systems, waits on two people, and loops back on itself more than once.

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

data to gather, approvals, waits 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 which Harper, 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. Give

an 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 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 eleven deterministic stages, it turns the graph into an execution DAG, 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 compiled, immutable, and pinned by its hash.

The model translates. The plan is compiled. The compiler checks the plan against a grammar, the vocabulary of what the firm is allowed to do. Forty-two 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 forty 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 back end, 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 W-9 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, they are nodes in the plan, not prompts. A reply wait defaults to seventy-two hours, and an explicit deadline can be anything from a minute to thirty 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 a 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 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 twenty decisions, nineteen go to the flash tier and one goes to the frontier. That is why we designed for about ninety-five percent of model decisions in a workflow 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.

And the five percent 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 typed call from the Harper Bourbonine 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 typed shape, so the same change applies to almost all of them. That is how about ninety-five percent 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. If you're building AI into regulated work, I'd love to compare notes