Workflows confiáveis e inteligentes para finanças, gestão de patrimônio e seguros — Karthic Rao, Perpetual

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual · Canal: AI Engineer · 14:55 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Governança e regulação de IA, Inferência e otimização de modelos

Resumo

Karthic Rao apresenta uma arquitetura para workflows em setores regulados que combina execução determinística com julgamento de modelos apenas onde ele é necessário. Usando o preenchimento de um formulário W-9 como exemplo, mostra como ambiguidades, coleta de dados, aprovações e acompanhamento tornam tarefas aparentemente simples em processos que duram dias. A proposta transforma pedidos em planos tipados, compilados e aprovados por pessoas, enquanto uma máquina de estados controla etapas e efeitos externos. Com chamadas pequenas e estruturadas, muitos julgamentos podem usar modelos menores ou inferência local, reduzindo o uso de modelos de fronteira e os riscos de conformidade.

Pontos-chave

Em setores regulados, confiabilidade e inteligência não são opostas: a arquitetura deve definir onde cada uma atua.
O fluxo de controle, as evidências e os efeitos externos devem ser determinísticos; modelos devem cuidar de interpretação e julgamento.
O preenchimento de um W-9 pode envolver ambiguidades, documentos ausentes, contato com clientes, aprovações e acompanhamento.
Um planner transforma o pedido em um grafo semântico tipado, e um compilador determinístico valida o plano antes da execução.
Ações externas, como enviar um e-mail ou solicitar uma assinatura, exigem gates de aprovação vinculados ao conteúdo exato.
Julgamentos de modelos retornam respostas tipadas; a máquina de estados decide como prosseguir.
A proposta direciona a maioria das decisões para modelos menores, deixando os casos difíceis para modelos de fronteira.
Chamadas pequenas e verificadas por schema facilitam a migração para modelos hospedados privadamente.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio da confiabilidade em setores regulados	Karthic Rao apresenta a necessidade de equilibrar confiabilidade, inteligência, privacidade e conformidade em workflows financeiros.
03:08	O que envolve preencher um formulário W-9	O exemplo mostra como uma tarefa simples exige decisões fiscais, coleta de dados, contato com o cliente, assinaturas e acompanhamento.
06:16	Onde traçar a fronteira entre determinismo e julgamento	A proposta reserva o controle do fluxo, das evidências e dos efeitos externos ao sistema determinístico, deixando a interpretação para os modelos.
09:34	Planos compilados, aprovações e acompanhamento	O plano W-9 é validado e aprovado antes da execução, com gates para ações externas e regras explícitas para esperas e follow-ups.
12:16	Modelos menores e inferência local	Chamadas pequenas e tipadas permitem direcionar a maioria dos julgamentos a modelos menores e facilitam a migração para modelos hospedados privadamente.

Citações

Em um setor regulado, maximizar tokens é o objetivo errado. — 01:31

A confiabilidade vem de onde você coloca a fronteira entre as duas coisas. — 06:48

O modelo orienta. Ele nunca conduz. — 12:16

É assim que cerca de 95% de inferência local se torna viável como consequência da arquitetura, não como promessa de política. — 14:23

Conceitos e entidades

Perpetual (empresa): Empresa de gestão de patrimônio que usa IA para aumentar a capacidade operacional e a receita de firmas tradicionais.
Karthic Rao (pessoa): CTO da Perpetual e apresentador da proposta de arquitetura para workflows em setores regulados.
W-9 (conceito): Formulário fiscal usado na apresentação para ilustrar as decisões e verificações de um workflow de gestão de patrimônio.
planner (conceito): Componente que usa uma chamada de modelo para traduzir o pedido em um grafo semântico de intenções, entidades, fatos e restrições.
Compiler (conceito): Componente determinístico que valida o plano em relação à gramática e aos contratos de ações permitidos.
State machine (conceito): Mecanismo que executa o plano aprovado, seleciona as etapas e registra cada resultado.
Flash tier (conceito): Categoria de modelos menores e rápidos proposta para lidar com a maioria dos julgamentos tipados do workflow.
Frontier model (conceito): Modelo de fronteira reservado aos casos que exigem capacidades mais avançadas.
Privately hosted models (conceito): Modelos hospedados em ambiente privado, que podem ser usados com chamadas tipadas sem reescrever o workflow.

Tradução completa (pt-BR)

00:00 Olá, sou Karthik, CTO da Perpetual. Nesta apresentação, vou falar sobre como criar workflows confiáveis e inteligentes para finanças, gestão de patrimônio e seguros. Em áreas reguladas, os workflows precisam ser confiáveis o suficiente para atender aos padrões regulatórios e, ao mesmo tempo, inteligentes o suficiente para lidar com o mundo real. Em áreas como finanças e gestão de patrimônio, isso representa tanto um desafio técnico quanto de conformidade. Confiabilidade e inteligência não são opostos. Cabe a você decidir onde traçar o limite entre elas, e esse é o objetivo desta conversa: decidir onde fica esse limite

00:31 entre elas. Para nós, não é apenas um experimento mental, mas uma questão com consequências sérias. A Perpetual é uma empresa de consolidação de gestão de patrimônio: adquirimos empresas tradicionais de gestão de patrimônio e maximizamos sua capacidade de processamento e receita com a ajuda da IA. Gestão de patrimônio é um setor regulado, e é nele que desenvolvemos com IA em produção. Tudo nesta conversa parte da construção para atender a essas restrições. Os workflows em finanças e gestão de patrimônio têm quatro características, e cada uma

01:01 delas direciona a arquitetura para o mesmo lado. Primeiro, são complexos e precisam de estratégias em tempo de execução conforme o processo se desenrola. Não é possível programar antecipadamente todos os caminhos. Segundo, os dados são sensíveis, então é preciso ter uma forma de executar esses workflows inteiramente em modelos hospedados em ambiente privado. Terceiro, em um setor altamente regulado, uma violação de política não é um relatório de bug. Ela tem consequências graves. Portanto, quarto, a execução precisa ser altamente confiável e determinística. Injete inteligência apenas onde o julgamento em tempo de execução

01:31 for realmente necessário e minimize a dependência de LLM em todos os outros pontos. A IA está se disseminando por setores regulados, mas ainda não há consenso sobre uma arquitetura que ofereça alta confiabilidade com o mínimo uso de inteligência de LLM. Enquanto isso, a maior parte do que os desenvolvedores ouvem dos grandes laboratórios é sobre como gastar mais tokens. Mas, em um setor regulado, maximizar o uso de tokens é o objetivo errado. Essas tarefas são parecidas com as de manutenção. É possível descrevê-las antecipadamente e incorporá-las a uma enorme máquina de estados

02:01 . E essa máquina precisa de apenas um toque de inteligência para navegar por ela. A maioria das etapas simplesmente segue para a próxima conexão. Apenas em alguns pontos de julgamento o modelo escolhe um caminho. Portanto, a maneira inteligente de construir é usar a inteligência de forma mínima e intencional. Vamos concretizar isso com um workflow real de gestão de patrimônio. Um consultor de patrimônio se dirige ao assistente e diz uma frase: “Preencha o formulário W9 do IRS para o Sr. Harper.” Para uma pessoa, é uma instrução simples. Veja o que ela

02:33 realmente desencadeia quando alguém a executa. A tarefa tem complexidades que vão além do que parece à primeira vista. Primeiro, o assistente encontra o formulário W9 nos registros da empresa ou no site do IRS. Depois, procura o Sr. Harper no sistema de registro e encontra três famílias Harper. Então, liga para o consultor: “Qual Harper você quer dizer?” Só depois que essa ambiguidade é resolvida é que prossegue com o formulário. Uma busca, uma ambiguidade e uma pessoa no circuito, tudo no primeiro minuto de uma tarefa de uma única linha.

03:08 Preencher um formulário parece uma tarefa de inserção de dados. Não é. Todo formulário é um pequeno programa. Primeiro, o W9 determina quem é o contribuinte: a pessoa ou o proprietário, se for uma entidade desconsiderada para fins fiscais. Se for uma pessoa estrangeira, o processo para aqui, porque ela precisa de um W8. Depois, determina como é tributada. Exatamente uma caixa na linha 3; um LLC acrescenta sua letra. Isso determina qual nome vai na linha um e qual vai na linha dois. Depois, de quem é o número? Um SSN ou um EIN? Nunca

03:40 os dois. Deve ser obtido de um documento verificado, nunca da memória. Os códigos de isenção se aplicam apenas a algumas entidades e nunca a uma S corporation. E, por fim, quem assina sob pena de perjúrio? Cada resposta muda a pergunta seguinte. E as pessoas envolvidas só veem três tipos de barreiras: uma pergunta, um documento a coletar ou uma assinatura. Agora começam a preencher o formulário e percebem que faltam três dos valores necessários no sistema de registro. Conferem

04:11 os documentos arquivados e verificam novamente o sistema de registro: os dados continuam faltando. Então, iniciam uma troca de e-mails com o cliente, pedindo exatamente esses três valores. Agora, a tarefa depende de alguém de fora da empresa, no tempo dessa pessoa, e o workflow fica aguardando. A solicitação está com o cliente e os três valores continuam faltando. Se o cliente não responder em até 2 dias, o assistente faz um acompanhamento e leva o assunto ao consultor na reunião diária. Se o cliente

04:42 responder com apenas dois dos três valores, eles voltam a entrar em contato para pedir o que falta. Quando os três chegam, preenchem o formulário e registram as novas informações no sistema de registro, incluindo o histórico de como obtiveram esses valores. Neste setor, como se sabe um valor importa tanto quanto o próprio valor. Depois de preenchido, o formulário é enviado para assinatura eletrônica. Se o cliente não assinar

05:12 em um ou dois dias, o assistente volta a lembrá-lo. Depois que ele assina, o assistente arquiva o formulário para o cliente, envia a confirmação e atualiza o consultor na reunião do dia seguinte. Uma frase do consultor se transformou em um processo que leva dias, atravessa vários sistemas, aguarda duas pessoas e volta a etapas anteriores mais de uma vez.

05:44 Observe o que há dentro daquela frase. Ambiguidade a resolver, dados a coletar, aprovações, prazos medidos em dias, ciclos de acompanhamento e, ao final, um histórico de evidências. Existem ferramentas de automação de workflows, mas raramente lidam com essa complexidade e ambiguidade do mundo real. Um fluxograma fixo falha logo na primeira pergunta: “Qual Harper?”, e a falta de um sistema de registro nativo com uma integração e um

06:16 agent que improvisa ao longo do processo é exatamente algo que uma equipe de conformidade não pode aprovar. Um falha diante da ambiguidade; o outro não pode ser aprovado. Nenhum dos dois lida com o que está dentro daquela frase. Então, o que fazemos? A abordagem da moda é mais autonomia e modelos melhores. Dê a tarefa inteira ao agent e espere que o próximo modelo a torne confiável. A resposta instintiva, especialmente dentro de empresas reguladas, é o oposto: menos autonomia, mais regras, restrições rígidas e todos os caminhos codificados de forma fixa.

06:48 Ambas as opções partem do eixo errado. Em setores verticais regulados, a confiabilidade vem de onde se coloca o limite entre as duas coisas: entre as partes que precisam ser determinísticas e as que realmente exigem julgamento. Eis o princípio. O determinismo rege o fluxo de controle, as evidências e os efeitos colaterais: o que é executado em seguida, o que sabemos e como sabemos. E tudo o que muda o mundo, como gravar um registro, enviar um e-mail ou arquivar um formulário,

07:22 a inteligência oferece interpretação e julgamento: ler e interpretar uma instrução ambígua, decidir qual Harper é, entender a resposta de um cliente. O modelo responde a uma pergunta de tipagem, e o sistema determinístico decide o que fazer com a resposta. E essa interação é recursiva. Um julgamento pode abrir um novo plano menor, que é compilado, passa por verificações e é determinístico. Você verá isso daqui a pouco nos acompanhamentos. O limite entre os dois é o próprio projeto. Veja como isso funciona no mecanismo de workflow que criamos.

08:01 A solicitação vai para um planejador, que é uma chamada de modelo, e seu único trabalho é a tradução. Ele emite um grafo semântico tipado de intenções, entidades, fatos, artefatos, eventos e restrições. Cada elemento é fundamentado nas palavras da solicitação, junto com as ambiguidades identificadas. Cada nó aponta de volta para as palavras de que se originou. Esse grafo vai para um compilador que nunca chama um modelo e executa 11 etapas determinísticas. Ele transforma o grafo em uma tag de execução ou falha de forma segura. Há

08:31 apenas três vereditos: válido, precisa de esclarecimento ou recusado. “Qual Harper?” retorna como pergunta, não como palpite. O plano é compilado, torna-se imutável e é fixado pelo seu hash. O modelo traduz. O plano é compilado. O compilador verifica o plano em relação à gramática, ao vocabulário do

09:03 que a empresa tem permissão para fazer. São 42 contratos de ação tipados para formulários, documentos, e-mail, assinatura eletrônica, calendário e etapas humanas. Cada ação solicitada pelo planejador precisa corresponder a um contrato. Neste caso, o preenchimento de formulário encontra seu contrato e fica definido. Se o planejador solicitar uma ação que não esteja na gramática ou conectar alguma de forma incorreta, o compilador a recusa. Há cerca de 40 maneiras de falhar de forma segura, desde um ciclo no grafo até uma ação sem suporte. E o mesmo

09:34 O resumo do contrato fica fixado no engine, no backend e na interface do usuário. Assim, os três concordam sobre o significado de uma ação. Isso é o que um domínio fechado oferece. O modelo só pode solicitar coisas que a empresa já sabe fazer com segurança. Aqui está um plano compilado para cobrar o formulário W-9: enviar o formulário ao cliente, esperar que ele o devolva, verificá-lo e arquivá-lo. Antes de qualquer coisa ser executada, uma pessoa aprova o próprio plano: encontrar o formulário, prepará-lo para o cliente preencher, renderizar o PDF e redigir o e-mail. Redigir é uma chamada de modelo,

10:07 então fica em violeta. O envio é uma etapa de aprovação. Nada sai da empresa até que uma pessoa aprove aquele e-mail específico. Então, o plano aguarda uma resposta, e um juiz entra em cena para lê-la. O formulário devolvido é verificado. Se estiver de acordo, é arquivado após outra etapa de aprovação. Se não estiver, o plano faz um acompanhamento. Agora, veja as etapas tracejadas. Renderizar o PDF, anexá-lo, julgar

10:38 a resposta. O planejador nunca as solicitou. A gramática as adicionou porque os contratos as exigem. Na história, esperar, obter aprovações e fazer acompanhamentos eram a maior parte do trabalho. Aqui, são nós do plano, não prompts. O prazo padrão para uma resposta é de 72 horas, e um prazo explícito pode ser de um minuto a 30 dias. Quando ele vence, uma regra decide o que acontece, não um modelo. Uma aprovação abrange o plano, e cada ação externa, como enviar um e-mail ou

11:10 uma solicitação de assinatura, tem sua própria etapa de aprovação. A aprovação está vinculada a um hash do payload exato e é verificada novamente logo antes do envio. Quando um cliente responde com apenas parte do que pedimos, o juiz de respostas marca a resposta como parcial. Esse julgamento é provisório. A etapa continua bloqueada até que uma pessoa confirme. Uma pessoa confirma, e a etapa é desbloqueada. Então, o acompanhamento é executado como um novo plano filho. O plano pai aprovado nunca é alterado, e há no máximo cinco rodadas.

11:46 Depois que um plano é aprovado, uma máquina de estados o executa. Ela seleciona cada etapa e registra cada resultado. Quando uma etapa precisa de julgamento, ela faz uma chamada de modelo com um schema fixo. Redigir um e-mail, julgar uma resposta, identificar valores ausentes, extrair campos, verificar um documento: a resposta retorna em formato tipado, e a máquina de estados decide o que fazer com ela. Os efeitos colaterais têm um ciclo de vida próprio: preparação, envio, sucesso ou, quando o mundo não responde de forma clara, resultado

12:16 desconhecido e revisão manual. Não há novas tentativas automáticas. Uma mensagem de chat pode aprovar uma etapa ou responder a uma pergunta. Ela não pode alterar um plano já aprovado. O modelo orienta. Ele nunca conduz. Agora, veja o que resta para o modelo fazer. Fora do planejador, os julgamentos são pequenos e tipados. Esta resposta está completa? Este documento corresponde? Qual campo é qual? Eles não

12:46 precisam de inteligência de fronteira. Um modelo pequeno e rápido, da categoria flash, pode lidar com eles. Nesta execução ilustrativa de 20 decisões, 19 vão para a categoria flash e uma vai para o modelo de fronteira. Por isso, projetamos o sistema para que cerca de 95% das decisões do modelo em um workflow nunca precisem de um modelo de fronteira. E a categoria flash pode ser executada em hardware sob seu controle. Só os casos realmente difíceis vão para um modelo de fronteira. E esses 5% não são um custo permanente

13:17 porque cada julgamento é tipado e registrado, e os provisórios são confirmados ou rejeitados por uma pessoa. Cada decisão de fronteira produz uma distribuição de notas de evals, dados de treinamento reais por construção. Esses dados podem ser usados para fazer post-training da categoria flash. O registro e os evals já existem. O ciclo de treinamento vem a seguir. Assim, a parcela de decisões de fronteira diminui a cada lançamento, até que até mesmo os casos difíceis sejam executados localmente.

13:51 Lembre-se do requisito com que começamos: como os dados são sensíveis, você precisa de um caminho para transferir workflows inteiramente para LLMs hospedados de forma privada. Então, será que este design pode realmente chegar lá? Veja uma chamada tipada do plano Harper Berby 9. Toda chamada de modelo é pequena, tipada e verificada em relação a um schema. Portanto, apontá-la para um modelo hospedado de forma privada é uma mudança de configuração, não uma reescrita. Uma linha muda, e a mesma resposta retorna. Todas as outras chamadas têm o mesmo formato pequeno e tipado. Portanto, a mesma mudança

14:23 se aplica a quase todas elas. É assim que cerca de 95% de inference local se torna viável como consequência da arquitetura, não como promessa de política. Esse é o caminho que os dados sensíveis exigem, e o risco de conformidade diminui com um roteiro de engenharia, lançamento após lançamento. Então, se você lembrar de uma coisa, não pergunte se o seu sistema deve ter mais ou menos autonomia. Pergunte onde fica o limite. Deixe que o determinismo governe o fluxo de controle, as evidências e os efeitos colaterais. Deixe que a

14:55 inteligência cuide da interpretação e do julgamento. Em pontos tipados, você pode inspecionar cada julgamento e usar tudo o que registrar para precisar de menos julgamentos. Da próxima vez, pergunte onde fica o limite. Obrigado. Sou Karthik, CTO da Perpetual. Se você está desenvolvendo IA para atividades regulamentadas, adoraria trocar ideias.

Transcrição original

[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.