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

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual · Channel: AI Engineer · 14:55 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI evaluation and benchmarks, AI governance and regulation, Model inference and optimization

Summary

Karthik Rao explains how to build AI workflows for regulated finance, wealth management, and insurance by deciding carefully where determinism ends and model judgment begins. Using a W9 workflow as an example, he shows how a seemingly simple request can involve ambiguity, missing information, client follow-ups, approvals, signatures, and an evidence trail. Perpetual’s approach uses a model to interpret requests, then compiles them into immutable plans governed by typed contracts, human gates, and a deterministic state machine. Small, typed model calls also make private hosting practical and can reduce reliance on frontier models over time.

Key points

Regulated workflows need to be reliable and deterministic, while still handling real-world ambiguity.
Use LLM intelligence only where runtime interpretation or judgment is genuinely required.
A W9 request can involve resolving identity, checking tax rules, collecting missing data, waiting for replies, obtaining a signature, and recording evidence.
Determinism should govern control flow, evidence, and side effects; intelligence should handle interpretation and judgment.
A model translates a request into a semantic graph, while a deterministic compiler validates it and either creates a plan or fails closed.
Typed action contracts constrain the model to actions the firm has defined, and human approvals gate plans and external actions.
Judgment calls return structured answers; the state machine decides what happens next, and follow-ups can run as new child plans.
Small, typed model calls can run on privately hosted models, reducing sensitive-data exposure and dependence on frontier models.

Chapters

Start	Chapter	Summary
00:00	Reliability and intelligence in regulated workflows	Rao introduces the challenge of building AI workflows for regulated industries and argues for using intelligence selectively within reliable systems.
02:01	The complexity behind a W9 request	A one-sentence request to fill out a W9 unfolds into identity checks, tax-related decisions, requests for missing information, follow-ups, and signatures.
05:44	Where to place the boundary	Rao contrasts rigid automation with unconstrained agents and proposes that deterministic systems control execution while models provide judgment.
08:01	Compiling plans and gating actions	The workflow engine translates requests into a graph, validates it through typed contracts, and uses immutable plans, approvals, and deterministic follow-up rules.
11:46	Typed judgments and private model hosting	A state machine executes approved plans, while small structured model calls support local inference and reduce reliance on frontier models.

Quotes

Inject intelligence only where runtime judgment is genuinely required and minimize reliance on LLM everywhere else. — 01:31

Determinism governs control flow, evidence, and side effects. — 06:48

intelligence provides interpretation and judgment — 07:22

The model steers. It never drives. — 12:16

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

Concepts and entities

Perpetual, Karthic Rao, W-9, planner, Compiler, State machine, Flash tier, Frontier model, Privately hosted models

Full transcript (original language)

00:00 Hello, I’m Karthik, 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

00:31 lies. For us, it’s not merely a thought experiment but a question that surfaces serious consequences. Perpetual is a wealth management rollup 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

01:01 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

01:31 judgment is genuinely required and minimize reliance on LLM 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

02:01 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 adviser turns to their assistant and says one sentence. Fill out the IRS W9 for Mr. Harper. To a person, that’s a simple instruction. Watch what it

02:33 actually triggers when a human being executes it. The task has complexities that go beyond what meets the eye. First, the assistant finds form W9 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 adviser, which Harper do you mean? Only once that ambiguity is resolved do they move on to the firm. A lookup, an ambiguity, and a human in the loop all in the first minute of a oneline task.

03:08 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 3 A 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

03:40 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

04:11 the documents on file and the system of record again still missing. So they start an email thread with a 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 2 days, the assistant follows up and brings it to the adviser at the daily standup. If the client

04:42 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

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

05:44 Look at what’s inside that one sentence. Ambiguity to resolve, data to gather, 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 harper and the lack of a native system of record with an integration and an

06:16 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 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 hardcode every path.

06:48 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,

07:22 intelligence provides interpretation and judgment, reading and ambiguous instruction, deciding which Harper, understanding a client’s reply, the model answers a type 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.

08:01 The request goes to a planner that is a model call and its only job is translation. It emits a type 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 11 deterministic stages. It turns the graph into an execution tag or it fails closed. There

08:31 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 the grammar, the vocabulary of

09:03 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

09:34 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 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

10:07 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

10:38 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 weight 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

11:10 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.

11:46 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

12:16 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

12:46 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 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 5% is not a permanent tax

13:17 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 postrain 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.

13:51 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 Berby 9 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

14:23 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 road map 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

14:55 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 Karthik, CTO at Perpetual. If you’re building AI into regulated work, I’d love to compare notes.