Come Thrive e OpenAI hanno trasformato le correzioni fiscali in un loop Codex che si auto-migliora

Cosa è stato lanciato per le oltre 30 società di Crete

Nell'arco di sei mesi, gli ingegneri forward-deployed di OpenAI e Thrive Holdings hanno costruito Tax AI per la rete di oltre 30 società di contabilità di Crete, applicandolo a 7.000 dichiarazioni 1040 e 1041 durante questa stagione pilota. Il problema di partenza era concreto: la sola immissione dati può richiedere otto ore su una dichiarazione di media-alta complessità, tra documenti disordinati degli anni precedenti, foglio di calcolo e appunti scritti a mano.

I risultati principali sono numeri di efficienza: circa un terzo del tempo di preparazione risparmiato, fino al 97% di precisione, circa il 50% di throughput in più. Ma il dato che interessa davvero agli autori è che il sistema è migliorato mentre era in funzione. Al lancio, solo un quarto delle dichiarazioni raggiungeva il 75% di completamento corretto dei campi; in sei settimane, questa percentuale è salita all'86%, con guadagni ancora più rapidi alle soglie del 90% e del 100%, mentre l'agente passava dai W-2 e 1099 ai K-1 e agli schemi di locazione.

La schermata di correzione è la pipeline dei dati

La scelta di design del frontend che sostiene tutto il sistema è trattare la revisione del professionista non come un passaggio terminale, ma come un evento strutturato. Quando un contabile approva o modifica un valore estratto, il prodotto registra esattamente cosa ha proposto Tax AI, cosa ha modificato il professionista e cosa è finito effettivamente nella dichiarazione presentata. Questa tripletta è la materia prima per tutto ciò che viene dopo.

È facile sottovalutare questo aspetto. La maggior parte delle interfacce di revisione registra la risposta finale e scarta il disaccordo. Qui il disaccordo è il prodotto. Il team ha progettato esplicitamente il flusso di lavoro in modo che 'le persone che svolgono il lavoro guidino ciò che il prodotto impara' — i professionisti generano il segnale di miglioramento semplicemente facendo il loro lavoro, senza un'attività di etichettatura separata o un modulo di feedback aggiunto a parte.

Perché la provenienza doveva essere una superficie di primo piano

Una correzione grezza è ambigua. Un valore modificato prima della presentazione può essere un vero errore di estrazione, un problema di mappatura, un valore riportato da una dichiarazione dell'anno precedente, una preferenza del professionista, o semplicemente rumore del flusso di lavoro. Se l'interfaccia memorizzasse solo input e output, gli ingegneri dovrebbero comunque ricostruire di quale caso si tratti — il loop manuale e lento che l'articolo descrive in apertura.

Tax AI evita questo problema preservando il percorso completo: documenti organizzati e classificati, campi delle proprietà in locazione estratti con citazioni al materiale di origine, valori mappati nel motore fiscale, e infine la modifica del professionista. Questa traccia di provenienza è ciò che permette al sistema di produrre righe di revisione a livello di campo, raggruppare i fallimenti ricorrenti — la mancata rilevazione ripetuta dei 'giorni di locazione equa', la gestione errata delle 'altre spese', la confusione tra più proprietà in un unico pacchetto — e separare i veri bug del prodotto dal rumore previsto prima che qualcosa arrivi a Codex.

Codex lavora poi all'interno di un ambiente delimitato che riflette questa separazione: un worktree scrivibile che contiene la superficie del prodotto relativa al reddito da locazione con le sue valutazioni mirate e di regressione, e un contesto in sola lettura che fornisce la traccia di produzione, i documenti di origine, la previsione e la dichiarazione presentata. L'agente può ispezionare le evidenze senza modificarle, proporre una pull request e reindirizzare i casi ambigui agli ingegneri invece di forzarli attraverso il loop.

L'implicazione: costruire la superficie di revisione prima dell'agente

La lezione riutilizzabile qui è l'ordine delle priorità. La funzionalità per le proprietà in locazione ha richiesto circa sei settimane e una forte supervisione ingegneristica per raggiungere il 90% di precisione e richiamo, ma il ritorno sono state abstrazioni riutilizzabili, convenzioni di valutazione e artefatti di revisione che hanno reso più economici lo Schedule C e lo Schedule A. Nulla di tutto ciò sarebbe stato possibile prima che la superficie di correzione producesse evidenze strutturate, citate e raggruppabili.

Per i team che costruiscono agenti di dominio dove il giudizio esperto definisce la qualità, la lezione è che il frontend attraverso cui gli umani correggono la macchina non è un dettaglio estetico — è lo strato di ingestione per l'auto-miglioramento. Sbagliarlo significa che ogni correzione resta manuale; farlo bene significa che ogni modifica rilasciata genera l'evidenza per il ciclo successivo. Vale la pena riflettere sulla sintesi che Thrive stessa fa di questo principio:

I migliori agenti sono guidati dalle persone per imparare a diventare più capaci, più affidabili e più utili nel tempo.Montana Labs

La prova concreta arriva da una contabile senior che l'anno scorso ha dedicato 180 ore alla preparazione fiscale e quest'anno solo 15 — tempo che ha reindirizzato verso le chiamate a ogni cliente e verso nuovo lavoro. Questo risultato esiste solo perché l'interfaccia che usava per correggere l'agente era, silenziosamente, ciò che lo stava istruendo.