Karthic Rao (Perpetual) uses a wealth management example—turning a simple client request into a multiday process of identifying households, gathering missing information, follow-ups, signatures, and evidence retention—to argue that fixed flowcharts break on ambiguity while improvising agents create their own reliability problems. His design places control flow, evidence, and external actions in a deterministic system: models handle interpretation and judgment at explicit, typed points, and any judgment-generated subplan must pass the same compilation and approval boundaries. He describes a planner that translates requests into a semantic graph, a compiler that validates plans against the firm's action contracts (returning a valid plan, clarification request, or refusal), immutable approved plans, payload-specific gates on external actions, state-machine handling of waits and follow-ups, and manual review of uncertain outcomes. An illustrative 20-decision run assigns 19 decisions to a smaller model and one to a frontier model—a design target, not a measured fleet result. He also outlines a path toward privately hosted inference and future training, with the training loop still forthcoming. # Video Identity Observations ## Video Overview - **Title:** *Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual* - **Speaker self-introduction:** > "Hello, I'm Karthik, CTO at Perpetual." ## Observable Presentation Evidence ### Intended Audience - The talk explicitly addresses **builders deploying AI in regulated industries**: > "If you're building AI into regulated work, I'd love to compare notes." - It frames developers as a key audience, contrasted with lab messaging: > "most of what developers hear from the big labs is how to burn more tokens." - Secondary audience implied: **compliance-sensitive firms and technical decision-makers** in finance, wealth management, and insurance ("regulated verticals"). ### Claimed Scope - **Topic scope:** architecture for reliable AI workflows in regulated domains — "building workflows that are both reliable and intelligent for finance, wealth, and insurance." - **Grounding claim:** all content is presented as production-derived, not theoretical: > "Everything in this talk is grounded in building for those constraints." - **Company self-description (creator claim):** > "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." ### Self-Description & Positioning Evidence - Positions Perpetual as **operating AI in production under regulation**: > "Wealth management is a regulated industry and that is where we build with AI in production." - Claims a differentiated architectural stance against both "more agency" and "lock it down" approaches: > "reliability comes from where you place the boundary" between deterministic systems and model judgment. - Quantified claims made by the creator (demonstrated as claims, not verified): ~"95% of model decisions" need no frontier model; "42 typed action contracts"; "about 40 ways to fail closed." ### Demonstrated (vs. Claimed) Presentation Patterns - **Concrete worked example:** a single-sentence task ("Fill out the IRS W9 for Mr. Harper") expanded step-by-step — ambiguity resolution, human gates, follow-up loops, evidence trails. - **Technical depth:** describes planner/compiler/state-machine architecture, hash-pinned plans, action contracts, side-effect lifecycles. - **Forward-looking roadmap stated as such:** "The training loop is next" — the creator distinguishes what exists today (logging, evals) from what is planned (post-training the flash tier). ## Notes for Synthesis - This is a **conference-style technical talk**, not a promotional video; identity signal comes from the speaker's role, company description, and the audience invitation at the close. # Delivery Observation: Karthic Rao — "Reliable, Smart Workflows for Finance, Wealth and Insurance" ## Overall Communication Style The delivery is structured, example-driven, and heavily oriented toward **teaching through concrete narrative**. The speaker builds one running example (the W-9 task) and returns to it repeatedly, anchoring abstract architecture claims in a story the audience can visualize. ## Recurring Rhetorical Patterns - **"Watch what it actually triggers"** — the speaker frequently directs attention explicitly: *"Watch what it actually triggers when a human being executes it"*, *"Now look at what's inside that one sentence"*, *"Now look at what is left for the model to do"*, *"Now look at the dashed steps."* This "look at X" pattern recurs at least five times. - **Contrastive framing**: *"Reliability and intelligence are not opposites"*, *"Filling a form sounds like data entry. It isn't."*, *"One breaks on ambiguity, the other can't be signed off. Neither handles what's inside that sentence."* - **Paired/binary framing** as a device: *"The model translates. The plan is compiled."*, *"The model steers. It never drives."*, *"A question, a document to collect, or a signature."* - **Aphoristic summary sentences** that compress a section: *"Every form is a small program."*, *"How you know a value matters as much as the value itself."*, *"The boundary between the two is the design."* ## Teaching Habits - **Single worked example reused at multiple scales** — the "Fill out the IRS W9 for Mr. Harper" instruction appears at the start ([144]), inside the architecture explanation (which Harper as clarification, the W9 chase plan), and in the privacy discussion ("one typed call from the Harper W-9 plan"). - **Enumerated lists with explicit counts**: *"four facts"*, *"11 deterministic stages"*, *"three verdicts"*, *"42 typed action contracts"*, *"about 40 ways to fail closed"*, *"at most five rounds."* Numbers are used to make claims feel inspectable. - **Anticipating and naming alternatives before rejecting them**: *"The fashionable framing is more agency... The reflexive answer... Both are the wrong axis."* ## Vocabulary and Word Choice - Domain-specific, precise terminology repeated consistently: **deterministic, gate, judgment, typed, fail closed, pinned, immutable, boundary, side effects**. - Distinctive coined phrases: **"token maxing"** (*"token maxing is the wrong goal"*), **"flash tier"**, **"the boundary"** as a motif — closing the talk with the same phrase: *"Next time, ask where the boundary is."* ## Structural Patterns - **Bookending**: the opening thesis (*"Reliability and intelligence are not opposites... deciding where that boundary lies"*) is restated nearly verbatim as the closing takeaway (*"Ask where the boundary is"*). - **Progressive reveal**: story first (human assistant walkthrough), then diagnosis, then architecture, then privacy implications — each section built on the previous. - **Symmetrical principle statements**: *"Determinism governs control flow, evidence, and side effects... intelligence provides interpretation and judgment"* — stated mid-talk and repeated almost word-for-word at the end. ## Confidence Notes - The **"ask where the boundary is"** motif and the **"look at / watch"** attention-directing habit are strongly supported by repetition across the transcript. - Details about pacing, tone of voice, or visual gesture are **not observable from the transcript alone**; no claims are made about them. - The "95% flash tier" claim appears once as a stated design target; whether it is a measured result or a goal is presented as *"we designed for about 95%"*, suggesting an internal target rather than an independently verifiable figure. # Observed Positions — "Reliable, Smart Workflows for Finance, Wealth and Insurance" (Karthic Rao, CTO, Perpetual) ## Speaker Context - **Speaker:** Karthik, self-identified **CTO at Perpetual**, described as "a wealth management rollup" that acquires traditional wealth management firms and uses AI to increase throughput and revenue. - **Grounding claim:** All claims are presented as grounded in AI built for production in a regulated industry. --- ## Central Thesis > "Reliability and intelligence are not opposites. It is up to you where you draw the boundary between them." - The design question in regulated verticals is **where to place the boundary** between deterministic parts and judgment parts — not whether to have "more agency" or "less." - Stated principle: **determinism governs control flow, evidence, and side effects** (what runs next, what is known and how, and any world-changing action — records written, emails sent, forms filed). **Intelligence provides interpretation and judgment** (parsing ambiguous instructions, resolving which client, reading replies). --- ## Four Facts of Finance/Wealth Workflows (claimed) 1. They are **complex** and need runtime strategies — "You can't script every path in advance." 2. Data is **sensitive**, requiring a path to fully privately hosted models. 3. In regulated industries, a policy violation "isn't a bug report. It has severe consequences." 4. Execution must be **highly reliable and deterministic**. Conclusion drawn: inject intelligence only where runtime judgment is genuinely required; minimize LLM use elsewhere. ## Critique of Current Approaches - **No consensus architecture** exists for high reliability with minimal LLM intelligence in regulated industries. - Big labs push "how to burn more tokens," but **"token maxing is the wrong goal"** in regulated contexts. - **Two failed extremes** for the W9-style task: - Fixed flowcharts "break at the first 'which Harper'" (ambiguity). - An improvising agent with no native system-of-record integration "is exactly what a compliance team can't sign off on." - The "fashionable framing" (more agency, better models) and the "reflexive answer" (less agency, hardcode everything) are both called **"the wrong axis."** --- ## Concrete Example: The W9 Task - A one-sentence adviser request ("Fill out the IRS W9 for Mr. Harper") triggers: form lookup, **three matching Harper households** requiring a clarifying call, branching form logic (person vs. disregarded entity, W8 for foreign persons, exactly one line 3a box, LLC letters, SSN vs. EIN never both from verified documents, exemption code restrictions, signature under penalty of perjury). - Discovered missing values start an email thread with the client; the workflow **waits on external timelines**, follows up after 2 days, escalates at daily standup, handles partial replies, writes values **and their provenance** back to the system of record ("how you know a value matters as much as the value itself"), then e-signature with nudges, filing, acknowledgement, and standup update. - Characterization: "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." --- ## Proposed Architecture - **Planner (single model call):** translates request into a typed semantic graph (intents, entities, facts, artifacts, events, constraints), every node grounded in source words; ambiguities surfaced, not guessed. - **Compiler (no model, 11 deterministic stages):** validates graph against a grammar of **42 typed action contracts**; three verdicts only — valid, needs clarification, refused. "~40 ways to fail closed." Compiled plan is immutable and **pinned by hash** across engine, backend, and UI. - **Gates and approvals:** one approval covers the plan; each external action (send email, signature request) has its own gate, tied to the hash of the exact payload and re-checked before sending. - **Model calls are small and typed** (compose email, judge reply, extract fields, verify document); the state machine decides what to do with typed answers. "The model steers. It never drives." - **Judgment is provisional:** e.g., a "partial reply" judgment stays blocked until a person confirms. Follow-ups run as new **child plans**; the approved parent is never changed; at most five rounds. - **No automatic retries**; side effects have a lifecycle including "outcome unknown" and manual review. Chat can approve or answer but cannot change an approved plan. - **Waiting is a plan node**, not a prompt: default 72-hour reply wait, deadlines from 1 minute to 30 days, timeout handled by rule, not model. - The interplay is **recursive** — a judgment can open a new smaller compiled, gated, deterministic plan. --- ## Claims About Model Usage and Privacy - In an "illustrative run of 20 decisions, 19 go to the flash tier and one goes to the frontier" — hence the design target: **~95% of model decisions never need a frontier model**. - Flash-tier models can run **on hardware the firm controls**; every call is small, typed, schema-checked, so switching to a privately hosted model is "a configuration change, not a rewrite." - The ~5% frontier share is described as **"not a permanent tax"**: logged, typed, person-confirmed judgments produce eval-grade training data "by construction," enabling post-training of the flash tier. **Caveat as stated:** "Logging and evals exist today. The training loop is next." - Framed as "about 95% local inference becomes viable as an architectural consequence, not a policy promise." --- ## Closing Recommendation > "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, inspectable points; use logged judgments to reduce reliance on intelligence over time. - Speaker invites comparison of notes with others building AI for regulated work. --- ## Notes on Qualifications - Token/model figures (42 contracts, 40 failure modes, 19/20 split, 95%) are presented by the speaker as illustrative or design targets, not independently verified results. - The frontier-to-flash training loop is explicitly stated as **future work**, not an accomplished capability. - The talk's framing is the speaker's own position; competing views (more agency, more rules) are characterized by him and rejected on his terms. # Video Attribution & Provenance Record ## Speaker Identification | Speaker | Role | Basis | |---|---|---| | **Karthik Rao** (spelled "Karthic Rao" in title, "Karthik" in transcript) | **Creator / Presenter** — self-identified CTO at Perpetual | Opening line: *"Hello, I'm Karthik, CTO at Perpetual"*; closing: *"I'm Karthik, CTO at Perpetual"* | - No guests, interviewers, or narrators appear; the video is a **single-speaker technical presentation**. - Affiliation claim (CTO at Perpetual) is **self-stated**, not independently verified by supplied metadata. ## Organizational Context (per speaker's own account) - **Perpetual** is described as a *"wealth management rollup"* that acquires traditional wealth management firms and applies AI in production. - All claims about the firm, its workflow engine, and its production use are the **presenter's own descriptions** — treat as vendor claims, not verified facts. ## Referenced Sources & Third-Party Claims - **IRS Form W9 / W8** — cited as real-world regulatory artifacts used in the worked example. - **"Big labs"** — referenced generically (no named company) regarding advice to "burn more tokens"; presenter's characterization. - **Internal systems described as fact but unverifiable**: planner (semantic graph), 11-stage deterministic compiler, 42 typed action contracts, ~40 fail-closed paths, flash-tier vs. frontier model split (~95% / ~5%), private-hosted inference path. - No external citations, papers, datasets, or named third-party sources are referenced. ## Promotional Segments - ⚠️ **Promotional closing**: *"If you're building AI into regulated work, I'd love to compare notes"* — a networking/outreach invitation for the presenter's firm. - ⚠️ The entire talk functions partly as **company capability positioning** for Perpetual's workflow engine; no separate product pitch or demo CTA beyond the closing invitation. ## Availability & Interaction Limits - No metadata supplied regarding comments, captions, links, or distribution platform — **all availability status unknown**. ## Provenance Summary - **Sole evidence channel**: the transcript itself. No curated metadata beyond the title was provided. - Speaker name discrepancy noted: title says "Karthic Rao"; transcript self-identifies as "Karthik." - All quantitative claims (e.g., 20-decision illustrative run, 72-hour default reply wait, 5-round follow-up cap) originate from the speaker and are unverified. 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 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 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 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 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 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. 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 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 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 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 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. 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 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. 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 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. 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 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 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 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 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 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 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'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 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 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. 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 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 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.