Deterministic AI workflows for finance put control flow, evidence and side effects in a compiled state machine, and call a model only at typed judgment points. Karthic Rao, CTO of the wealth-management consolidator Perpetual, described that split in an AI Engineer talk published on 12 October 2026, using a single W-9 request to show why both fixed flowcharts and improvising agents fail in regulated work.
Deterministic AI workflows for regulated finance
Deterministic AI workflows keep control flow, evidence and external side effects inside a deterministic engine, and use a language model only where a request needs interpretation or judgment. Karthic Rao, CTO of the wealth-management consolidator Perpetual, laid out that boundary in an AI Engineer talk published on 12 October 2026, and framed the design problem as deciding where the line sits rather than how much autonomy to grant.
Perpetual acquires traditional wealth-management firms and applies AI to their operations, which means the systems described in the talk run inside a regulated business. Rao lists four facts that push the architecture in one direction:
- Workflows are complex and need execution strategies that emerge as the process unfolds, so you cannot script every path in advance.
- The data is sensitive and needs a path to privately hosted models.
- A policy violation in a regulated industry is not a bug report.
- Execution therefore has to be highly reliable and deterministic, with model use injected only where runtime judgment is genuinely required.
The talk does not claim this is a solved industry pattern. Rao says AI is spreading through regulated sectors without consensus on an architecture that delivers high reliability with minimal model use, and that most guidance developers hear from large labs is about spending more tokens. In a regulated vertical, he argues, maximizing tokens is the wrong objective. The counter-argument you hear inside regulated companies is just as wrong: fewer agents, more rules, block everything and code every path. Rao places both positions on the wrong axis. Reliability, in his framing, comes from where you put the boundary between the deterministic parts and the parts that genuinely need judgment.
Why a fixed flowchart and an improvising agent both fail
A fixed flowchart breaks at the first exception, while an agent that improvises at every step produces a process a compliance team cannot approve. Rao puts both failure modes side by side and argues that neither handles what is actually inside a one-sentence instruction. The two approaches fail for different reasons: the flowchart fails on ambiguity, the improvising agent cannot be approved at all.
Take the request: fill out an IRS W-9 for Mr. Harper. A person executing it first locates the form in the company records or on the IRS site, then searches the record system and finds three Harper families, then calls the adviser to ask which Harper is meant. Only after that ambiguity is resolved does the form work begin. One query, one ambiguity and one human, all inside the first minute of a task the adviser described as simple.
The W-9 itself behaves less like data entry and more like a small program, because each answer changes the next question. The form determines whether the taxpayer is an individual or a disregarded-entity owner; a foreign person stops and needs a W-8 instead; tax classification requires exactly one box on line 3a, and an LLC adds its corresponding letter, which decides what goes on line one and what goes on line two. The identification number is an SSN or an EIN, never both, and comes from a verified document rather than memory. Exemption codes apply only to some entities and never to an S corporation. Finally, a person signs under penalties of perjury. Wherever the process stalls, the people involved see only three kinds of blockers: a question, a document to collect, or a signature.
In the narrated run, the team then discovers the record system is missing three required values, checks archived documents and the record system again, and still comes up short. They start an email exchange asking the client for exactly those three values, which makes the task depend on someone outside the firm and on that person's schedule.
The W-9 request that takes days and loops twice
One adviser sentence becomes a process that lasts days, crosses several systems, waits on two people and loops more than once. The waiting, approvals and follow-ups turn out to be most of the work.
Once the request is with the client, the workflow waits. If the client does not reply within two days, the assistant follows up and flags it for the adviser at the daily meeting. If the client returns only two of the three values, the missing value is requested again. When all three arrive, the form is completed and the new values are written into the record system along with the history of how they were obtained. In this industry, knowing how a value was obtained matters as much as the value.
The completed form then goes for electronic signature. If the client does not sign within a day or two, a reminder goes out. After signing, the team files the form for the client, sends confirmation and updates the adviser at the next day's meeting.
Inside that single sentence sit an ambiguity to resolve, data to gather, approvals measured in days, follow-up loops and an evidence trail at the end. Rao's point is that these are the parts most workflow automation tools do not address.
How the planner and compiler turn a request into a plan
The request goes first to a planner, which is a model call whose only job is translation. It emits a typed semantic graph of intentions, entities, facts, artifacts, events and constraints, each node grounded in the words of the request and pointing back to them, with any ambiguities recorded.
That graph goes to a compiler that never calls a model. Rao describes 11 deterministic stages that turn the graph into an execution tag or fail safely. There are only three verdicts: valid, needs clarification or refused. A missing helper returns as a question rather than a guess. The compiled plan is immutable and pinned by its hash.
The compiler checks the plan against the firm's grammar, the vocabulary of what the company is permitted to do. In the version described in the talk, that vocabulary holds 42 typed action contracts covering forms, documents, email, electronic signature, calendar and human steps. Every action the planner requests must match a contract, so form filling meets its forms contract and consolidates. If the planner asks for an action outside the grammar, or wires one incorrectly, the compiler refuses.
Rao says there are roughly 40 ways to fail safe, from a cycle in the graph to an unsupported action. The same contract summary is pinned in the engine, the back end and the user interface, so all three agree on what an action means. That is what a closed domain buys: the model can only request things the company already knows how to do safely. One sentence is the whole division of labour. The model translates, and the plan is compiled.
What the compiled W-9 plan actually contains
In the illustrative compiled plan for the W-9 request, the steps are: send the form to the client, wait for the return, verify it and file it. Before execution, a person approves the plan itself.
The plan finds the form, prepares it for the client to fill in, generates the PDF and drafts the email. Drafting is a model call. The send is an action gate, and nothing leaves the firm until a person approves that exact email. The plan then waits for a reply, and a judge reads it. A returned form is verified; if it matches, it is filed behind another gate, and if it does not, the plan runs a follow-up.
Some steps in the plan were never requested by the planner. Generating the PDF, attaching it and judging the reply were added by the grammar because the contracts require them. Waiting, approvals and follow-ups, which were most of the narrated work, are nodes in the plan rather than prompts.
A wait for a reply defaults to 72 hours, and an explicit deadline can range from one minute to 30 days. When a deadline expires, a rule decides what happens, not a model. One approval covers the plan, and each external action such as sending an email or requesting a signature has its own gate. Approval is bound to a hash of the exact payload and is verified again shortly before sending.
Partial replies, provisional judgments and the five-round limit
When a client replies with only part of what was requested, the reply judge marks it partial, and that judgment is provisional. The step stays locked until a person confirms it; once confirmed, the step unlocks and the follow-up runs as a new child plan. The approved parent is never altered, and there are at most five rounds.
Once a plan is approved, a state machine executes it, choosing each step and recording every result. When a step needs judgment, it makes a model call with a fixed schema: drafting an email, judging a reply, detecting missing values, extracting fields, verifying a document. The response returns typed, and the state machine decides what to do with it.
Side effects get their own lifecycle: prepared, dispatched, completed or, when the world does not answer clearly, unknown outcome and manual review. There are no automatic retries. A chat message can approve a step or answer a question, but it cannot alter an already approved plan.
The rule Rao states is that the model guides and never drives. Follow-ups are executed as separate compiled plans, which is how a judgment can OpenAI smaller plan that is compiled, gated and deterministic again. The judgment is recursive: intelligence produces an answer, the deterministic engine decides what that answer means, and the next piece of work is back under compile-time control.
The 95 percent small-model target and the local inference path
Outside the planner, the judgments are small and typed: is this reply complete, does this document match, which field is which. Rao's claim is that these do not need frontier intelligence, and that a small fast model can handle them.
In an illustrative 20-decision run, 19 decisions went to the small model tier and one went to the frontier tier. Rao says the design target is that about 95 percent of model decisions in a workflow never need a frontier model, and he is explicit that this is a design target rather than a measured fleet result. The 20-decision figure is an example, not a benchmark. Only genuinely hard cases reach the frontier tier.
Because each model call is small, typed and checked against a schema, pointing one at a privately hosted model is a configuration change rather than a rewrite: one line changes and the same response returns. The same shape applies to nearly all the calls, which is how roughly 95 percent local inference becomes an architectural consequence rather than a policy promise. Sensitive data is the requirement this design answers, and the answer is that a workflow can be moved onto models you host yourself without touching the surrounding logic.
The talk also draws a line between what exists and what is planned. Typed, logged judgments from the current system feed a training loop with real grade-distribution data, and provisional judgments are confirmed or rejected by a person. Rao says the logging and evaluations already exist and that the training cycle is the next step, with the goal that the frontier share decreases release by release until even the hard cases run locally. That training loop is a stated roadmap item, not a shipped capability, and the remaining 5 percent is not a permanent tax if the loop works.
What this architecture does not prove
The design described in the talk is an architecture argument, and the numbers in it are design targets. The 19-of-20 split and the roughly 95 percent figure are illustrative examples from the speaker, not measurements of production traffic across Perpetual's firms.
Deterministic control flow, typed judgments, action gates bound to payload hashes and no automatic retries address reliability and auditability. They do not by themselves establish regulatory compliance, and the talk does not claim they do. Rao describes a path toward privately hosted inference and says compliance risk decreases as the engineering roadmap progresses; he does not present local execution as a compliance certification.
The comparison table below separates what the talk presents as built from what it presents as planned.
| Element | Status in the talk | Evidence class |
|---|---|---|
| Planner model call and typed semantic graph | Described as built | Speaker first-hand experience |
| 11-stage deterministic compiler, 42 action contracts | Described as built | Speaker first-hand experience |
| 19-of-20 small-model split, ~95% design target | Illustrative example | Speaker stated design target |
| Private hosting as a one-line configuration change | Described as architectural consequence | Speaker first-hand experience |
| Training loop that shifts work to the small tier | Roadmap, not shipped | Speaker stated roadmap |
A second caveat follows from the first. The architecture is described for one vertical, and the talk stays inside wealth management and adjacent regulated work. The grammar of permitted actions is firm-specific by construction, so the 42 contracts are not a reusable standard you can copy; the pattern is transferable, the vocabulary is not.
The where-should-the-boundary-sit question
Rao closes with a single question: do not ask whether your system should have more or less autonomy, ask where the boundary sits. Determinism governs control flow, evidence and side effects, while intelligence handles interpretation and judgment at typed points.
The practical reading for teams building in finance, wealth management or insurance is that the useful design work happens at the seam. Every judgment should be typed, logged and inspectable so that its output can be confirmed or rejected by a person, and so that the next release can rely on it less.
The same split also answers the data-sensitivity requirement, because small typed calls can be repointed at privately hosted models without rewriting the surrounding workflow. Perpetual's implementation details come from a talk published by AI Engineer on 12 October 2026, and the measurements in it are the company's own design targets rather than independent benchmarks.
FAQ
What are deterministic AI workflows in finance?
They are workflows where a deterministic engine owns control flow, evidence and external side effects, and a language model is called only at typed judgment points such as reading an ambiguous instruction or judging a client reply. Perpetual CTO Karthic Rao presented this split in an AI Engineer talk published on 12 October 2026, using an IRS W-9 request as the example.
Why does a fixed flowchart fail on a task like a W-9 form?
A fixed flowchart breaks at the first exception, and the W-9 request contains several: three families share the surname Harper, the record system is missing three required values, and the client has to respond and sign. The process ends up waiting on an external person, looping through follow-ups and lasting days.
Why can an improvising agent be rejected in a regulated workflow?
An agent that decides freely at each step produces behavior a compliance team cannot review in advance. Rao argues that governance in regulated work comes from an approved, immutable plan pinned by its hash, with each external action gated separately.
What is the difference between the planner and the compiler?
The planner is a model call whose only job is translation into a typed semantic graph. The compiler is deterministic, described as 11 stages, and never calls a model; it returns valid, needs clarification or refused.
What does the compiler check the plan against?
Against the firm's grammar, the vocabulary of permitted actions. In the version described in the talk, that is 42 typed action contracts covering forms, documents, email, electronic signature, calendar and human steps, with roughly 40 ways to fail safe.
How long does the workflow wait for a client?
A wait for a reply defaults to 72 hours, and an explicit deadline can range from one minute to 30 days. When the deadline expires, a rule decides what happens rather than a model.
What happens when a client sends only part of the requested information?
The reply judge marks it partial, and that judgment is provisional. The step stays locked until a person confirms it, after which the follow-up runs as a new child plan while the approved parent plan remains unaltered, with at most five rounds.
Does an approved plan ever get modified?
No. Approved plans are immutable and pinned by hash, and a chat message can approve a step or answer a question but cannot alter an approved plan. Each external action has its own gate bound to a hash of the exact payload.
How much of this runs on a small model?
Rao's design target is that about 95 percent of model decisions in a workflow never need a frontier model, illustrated by a 20-decision example where 19 went to the small tier and one to the frontier tier. He states that this is a design target, not a measured fleet result.
Can the same workflow run entirely on privately hosted models?
Rao describes that as the direction the design points in, not a finished switch. Each model call is small, typed and schema-checked, so repointing a call at a self-hosted model is a configuration change of about one line, and the same response shape comes back. The talk frames this as roughly 95 percent local inference becoming an architectural consequence, and compliance risk decreasing as the roadmap progresses.
What still has to improve before this is a finished answer?
The training loop. Logged, typed judgments already produce real grade-distribution data, and people confirm or reject provisional ones, but Rao presents the training cycle as the next step rather than a shipped capability. Until it runs, the frontier share of decisions remains a design target rather than a measured reduction.
Inside a 15-minute talk that starts with one sentence
The talk is 15 minutes long and begins with a single adviser sentence about a W-9 form. By the end it has covered a typed semantic graph, an 11-stage compiler, 42 action contracts, 72-hour default waits, five-round follow-up limits and an illustrative 20-decision run with 19 decisions on a small model.
The useful part of a talk like this one is the specific boundary someone chose and why, and that is what survives the move from spoken to written form. If your explanation of a workflow, an architecture trade-off or a regulated process exists only as a recorded talk, Skalablog turns a YouTube URL into a transcription and then into a written article you can review before publishing.
That is the same move the talk makes for its own subject: take knowledge that lives in one person's head and put it somewhere it can be inspected, corrected and reused. Developers who want to rebuild a planning and compilation pipeline in typed code, rather than only in prompts, tend to pick up the same habits in Crazystack TypeScript, and the people behind Gustavo Dev Doido and the Bootcamp do Dev Doido teach that style in Portuguese. The architecture argument from Perpetual is a useful frame to keep in mind while you work through it.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits