Como a Thrive e a OpenAI transformaram cliques de revisão fiscal em um loop autoaprimorável do Codex

O que foi lançado para as mais de 30 contabilidades da Crete

Ao longo de seis meses, engenheiros forward-deployed da OpenAI e a Thrive Holdings construíram o Tax AI para a rede de mais de 30 contabilidades da Crete, e rodaram o sistema em 7 mil declarações 1040 e 1041 durante essa temporada piloto. O problema de partida era concreto: só a digitação de dados pode levar oito horas em uma declaração de complexidade média a alta, lidando com documentos confusos de anos anteriores, planilhas e anotações manuscritas.

Os resultados de destaque são números de eficiência — cerca de um terço do tempo de preparação economizado, até 97% de precisão, aproximadamente 50% mais throughput. Mas a afirmação que realmente importa para os autores é que o sistema melhorou enquanto estava em operação. No lançamento, apenas um quarto das declarações atingia 75% de preenchimento correto de campos; em seis semanas, esse número subiu para 86%, com ganhos ainda mais rápidos nos limiares de 90% e 100%, à medida que o agente avançou dos W-2s e 1099s para os K-1s e cronogramas de aluguel.

A tela de correção é o pipeline de dados

A decisão de design de frontend que sustenta todo o sistema é tratar a revisão do profissional não como uma etapa final, mas como um evento estruturado. Quando um contador aprova ou edita um valor extraído, o produto registra exatamente o que o Tax AI propôs, o que o profissional modificou e o que efetivamente entrou na declaração enviada. Esse trio é a matéria-prima para tudo que vem depois.

É fácil subestimar isso. A maioria das interfaces de revisão captura a resposta final e descarta a discordância. Aqui, a discordância é o produto. A equipe desenhou o fluxo de trabalho explicitamente para que 'as pessoas que fazem o trabalho guiem o que o produto aprende' — os profissionais geram o sinal de melhoria simplesmente fazendo seu trabalho, sem uma tarefa separada de rotulagem ou um formulário de feedback anexado ao processo.

Por que a proveniência tinha que ser uma interface de primeira classe

Uma correção bruta é ambígua. Um valor alterado antes do envio pode ser um erro real de extração, um problema de mapeamento, um valor carregado de uma declaração de ano anterior, uma preferência do profissional, ou apenas ruído do fluxo de trabalho. Se a interface armazenasse só a entrada e a saída, os engenheiros ainda teriam que reconstruir qual desses casos era — o loop manual e lento que o texto descreve no início.

O Tax AI evita isso preservando o caminho completo: documentos organizados e classificados, campos de propriedades para aluguel extraídos com citações de volta ao material de origem, valores mapeados no motor fiscal e, então, a edição do profissional. Essa trilha de proveniência é o que permite ao sistema gerar linhas de revisão no nível de campo, agrupar falhas recorrentes — erro repetido em 'dias de aluguel justo', tratamento incorreto de 'outras despesas', confusão entre múltiplas propriedades em um mesmo pacote — e separar bugs genuínos do produto do ruído esperado antes que qualquer coisa chegue ao Codex.

O Codex então trabalha dentro de um ambiente delimitado que reflete essa separação: um worktree com permissão de escrita contendo a superfície do produto de renda de aluguel e suas avaliações direcionadas e de regressão, e um contexto somente leitura fornecendo o trace de produção, os documentos de origem, a previsão e a declaração enviada. O agente pode inspecionar as evidências sem alterá-las, propor um pull request e encaminhar casos ambíguos de volta aos engenheiros, em vez de forçá-los pelo loop.

A implicação: construa a interface de revisão antes do agente

A lição reutilizável aqui é sobre ordem. A capacidade de propriedades para aluguel levou cerca de seis semanas e supervisão intensa de engenharia para atingir 90% de precisão e recall, mas o retorno foram abstrações reutilizáveis, convenções de avaliação e artefatos de revisão que tornaram o Schedule C e o Schedule A mais baratos de implementar. Nada disso era possível até que a interface de correção começasse a gerar evidências estruturadas, citadas e agrupáveis.

Para equipes que constroem agentes de domínio em que o julgamento especializado define a qualidade, a lição é que o frontend onde humanos corrigem a máquina não é cosmético — é a camada de ingestão para a autoaprimoração. Erre nisso e cada correção continua manual; acerte e cada mudança lançada gera a evidência para o próximo ciclo. Vale a pena parar para pensar no resumo que a própria Thrive faz desse princípio:

Os melhores agentes são guiados por pessoas para aprender a se tornar mais capazes, mais confiáveis e mais valiosos com o tempo.Montana Labs

A prova humana disso é uma contadora sênior que passou 180 horas na preparação fiscal no ano passado e apenas 15 este ano — tempo que ela redirecionou para ligar para todos os clientes e assumir novos trabalhos. Esse resultado só existe porque a interface que ela usava para corrigir o agente era, discretamente, o que estava ensinando ele.