Bygga självförbättrande skatteagenter med Codex

Hur Thrive Holdings och OpenAI tillsammans utvecklade Tax AI för Cretes redovisningsekonomer genom att förena praktikerexpertis med en Codex-driven loop

System i verkligheten beter sig annorlunda i produktion än i ett labb och går sönder på sätt som är svåra att förutse före driftsättning. Team upptäcker ofta dessa fel efter lansering och lägger sedan veckor på att granska gränsfall, justera promptar och översätta produktionsfeedback till hållbara produktförbättringar. Återkopplingsloopen är manuell och långsam och förbättras bara när en ingenjör driver den framåt. Men i dag, med genomtänkt utformad eval-infrastruktur, direkt tillgång till praktiker och verkliga miljöer samt Codex agentiska spetsförmågor, kan du bygga Agenter som förbättrar sig själva.

I det här inlägget går vi igenom hur vi använde Codex för att bygga den här typen av Agent. Under de senaste sex månaderna har OpenAI:s utsända ingenjörer och forskare tillsammans med Thrive Holdings ingenjörer samarbetat för att bygga Tax AI tillsammans med och för Crete⁠(öppnas i ett nytt fönster)s nätverk av över 30 redovisningsbyråer för att hjälpa till att förbereda allt mer komplexa deklarationer. I stället för att förlita sig på att ingenjörer hittar och åtgärdar varje fel använder Tax AI Codex för att omvandla användning i produktion till strukturerade signaler som driver autonom förbättring.

Cretes praktiker upprättar tiotusentals deklarationer varje säsong, vilket kräver arbete med miljontals underliggande dokument. För deklarationer med medelhög till hög komplexitet kan enbart datainmatning ta åtta timmar per deklaration och involverar ofta stökiga datakällor, dokument från föregående år samt manuell extraktion och beräkning. De pekade ut skatteberedning som en betydande flaskhals under den mest intensiva delen av skattesäsongen.

För att lösa detta problem behandlade Tax AI 7 000 deklarationer hos de Crete-byråer som deltog i piloten denna skattesäsong. Systemet automatiserar en stor del av den tidskrävande processen att upprätta deklarationer 1040 och 1041, men ännu mer övertygande än effektivitetsvinsterna är att systemet självt är mätbart bättre än versionen som först driftsattes för tre månader sedan.

I Tax AI laddar praktiker upp källfiler tillsammans med eventuella klientspecifika anteckningar. Tax AI skapar sedan en inlämning till skattesystemet, redo för granskning. Det sparar praktiker ungefär en tredjedel av deras tid för skatteberedning, utkastar deklarationer med upp till 97 % noggrannhet och ökar kapaciteten med cirka 50 %, vilket ger mer utrymme för dem att tillbringa tid med klienter. 

Vi kan kvantifiera denna förbättring genom att förstå hur exakt Tax AI kan slutföra en deklaration utan att senare behöva korrigeras. Vi mäter noggrannhet genom att kontrollera hur stor andel av deklarationerna som når 75 %, 90 % eller 100 % korrekt ifyllnad av fält. Vid lanseringen nådde bara en fjärdedel av deklarationerna 75 % korrekt ifyllnad av fält, men inom sex veckor nådde 86 % den nivån. Systemet visade ännu snabbare tillväxt på nivåerna 90 % och 100 % korrekt ifyllnad av fält. Dessa trösklar ger oss en praktisk bild av hur mycket uppföljning från praktiker som olika deklarationer fortfarande kräver. 

Tidigt hanterade Tax AI enklare arbete, som W-2 och 1099. Allt eftersom säsongen gick tog det sig an mer komplexa deklarationer med K-1, bilagor och svårare gränsfall. Varje ny förmåga sparade mer tid per deklaration än den föregående eftersom uppgifterna den tog över var svårare och mer tidskrävande att göra manuellt. Vi fortsätter att se löpande framsteg i dag.

Härnäst går vi igenom hur våra team tillsammans konstruerade Tax AI för att vara självförbättrande genom att luta sig mot tre kritiska pelare: 1) expertfeedback från praktiker, 2) produktionsspår (en strukturerad historik från indata till slutlig utdata) och 3) en Codex-driven iterationsloop baserad på skräddarsydda evals för att möjliggöra kontinuerlig och snabbare produktutveckling. Vi hoppas att våra erfarenheter blir användbara för andra byggare i domäner där praktikerexpertis är avgörande för att forma kvaliteten i det övergripande systemet och datan som flödar genom det.

När vi tog oss an svårare delar av skatteberedningen (K-1, bilagor för hyresfastigheter och skatteformulär där värden måste stämmas av mellan flera källfiler) blev det tydligt att den verkliga utmaningen var om produkten kunde göra komplexa produktionsfel synliga, begripliga och åtgärdbara.

I produktens tidiga dagar var det mesta av korrigeringen manuell. Praktiker kunde korrigera systemfel, men produkten fångade inte hela kontexten: ett ändrat värde före inlämning kunde spegla en verklig miss i extraktionen, ett mappningsproblem, saknat produktstöd eller väntat brus i arbetsflödet. Att reda ut dessa fall krävde fortfarande uppföljning från ingenjörsteamet. Ingenjörer kunde använda kodningsagenter, men systemet var ännu inte utformat för att använda AI på ett meningsfullt sätt i en förbättringsloop. Vi hade inte signalen för att identifiera rätt berg att bestiga.

Det ledde oss till att utforma systemet kring tre pelare:

1. Håll er nära praktikerna: De som utför arbetet behöver styra vad produkten lär sig. Deras intuition och förståelse visar vilka fel som spelar roll och hjälper till att avgöra vilka delar av arbetsflödet som är värda att fokusera på härnäst.
2. Bygg produkten så att produktion skapar bevis: Produkten måste fånga mer än bara in- och utdata; den måste fånga hela vägen från källmaterial, till extraherade fält och proveniens, till nedströms inlämning och expertkorrigering.
3. Skapa en Codex-driven förbättringsloop: När produktionsproblem är synliga och strukturerade kan de bli fynd, skräddarsydda evals och avgränsade ingenjörsuppgifter. Codex kan sedan hjälpa till att undersöka, föreslå ändringar, validera dem mot riktade evals och regressionsevals och föra produkten framåt snabbare än en helt manuell iterationscykel. 

Exemplet med hyresfastigheter nedan visar hur den loopen fungerar i praktiken och går igenom hur en korrigering från en praktiker blir ett strukturerat fynd, sedan ett eval-mål och slutligen en avgränsad ingenjörsuppgift för Codex.

Inkomst från hyresfastighet rapporteras på Schedule E i en individuell deklaration. Ur ett ingenjörsperspektiv är uppgiften att extrahera den enkel att beskriva men svår att göra bra. Systemet måste läsa stökigt källmaterial (handskrivna anteckningar, e-post, kalkylblad och andra klientfiler), extrahera de fält för hyresfastigheter som systemet med säkerhet kan mappa till skattesystemet och bevara tillräckligt med bevis för att en praktiker ska kunna godkänna eller korrigera resultatet. Det förenklade exemplet nedan visar hur dessa källfiler och extraherade utdata kan se ut.

En skillnad mellan det Agent-förutsagda värdet och det faktiska värdet i den inlämnade deklarationen kan spegla en verklig miss i extraktionen, men den kan också bero på en handläggares preferens, ett värde som förts vidare från föregående års deklaration i skattesystemet eller ett värde som införts eller ändrats någon annanstans i deklarationsflödet. Handläggare hjälpte oss att skilja dessa fall åt så att vi kunde identifiera vilka åtgärder som krävde en korrigering från en handläggare eller blockerade en inlämning.

Eftersom vi kunde se dessa korrigeringar i detalj omvandlade vi granskningsprocessen från ett avslutande steg efter fel till en kontinuerlig lärandecykel. Vi utformade arbetsflödet för att fånga expertåtgärder som strukturerad data. Nu matar varje ingripande produktens förbättringsloop genom att registrera exakt vad Tax AI föreslog, vad handläggaren ändrade och vad som till slut hamnade i den inlämnade deklarationen.

För ett komplext arbetsflöde som hyresfastigheter måste systemet bevara vad som händer mellan källfilerna och den inlämnade deklarationen. Längs den vägen organiseras, delas och klassificeras dokument; fält för hyresfastigheter extraheras med källhänvisningar tillbaka till källmaterialet; dessa värden mappas in i skattesystemet; och handläggare kan fortfarande korrigera dem före inlämning. Dessa produktspår gör det möjligt att undersöka var ett fel uppstod. För att göra handläggarkorrigeringar till användbara utvärderingsmål behandlar systemet dem i tre steg:

• Fånga skillnaden: Tax AI:s utdata jämförs med den inlämnade deklarationen för att skapa granskningsrader på fältnivå som fångar det förväntade värdet, det förutsagda värdet och om skillnaden verkar åtgärdbar.
• Gruppera relaterade fel: Liknande granskningsrader grupperas för att skilja återkommande produktfel från väntat brus i arbetsflödet. Till exempel kan upprepade korrigeringar från handläggare visa att Tax AI ofta missar fält för ”antal dagar till marknadshyra”, hanterar ”övriga kostnader” fel eller blandar ihop flera hyresfastigheter i samma källpaket.
• Gör upprepade mönster till utvärderingsmål: När de har granskats och mätts blir återkommande fynd tydliga eval-mål för Codex att förbättra.

Den tredje pelaren är att skapa en ingenjörsloop som kan agera på dessa nya evals. Det är här Codex blir central.

Anta att vår eval-pipeline flaggar att Tax AI konsekvent missar fältet "antal dagar till marknadshyra", medan handläggare pålitligt fyller i det. Eftersom detta fynd redan har paketerats i en riktad eval-uppsättning, med representativa källpaket och förväntade utdata, kan Codex undersöka grundorsaken direkt i produktens ramverk.

Codex arbetar inte enbart med ett slutresultat av låg kvalitet. Det granskar spår, eval, förvar och färdigheter tillsammans:

• Undersök pipelinen: Inspektera källpaket, extraktionsscheman, mapper-beteende och kodvägar för att avgöra om problemet är ett fält som inte stöds, ett missat extraktionsmönster, ett problem med val av källa, en lucka i mappningen eller ett problem i gradern.
• Implementera riktade korrigeringar: Utöka extraktionsschemat, förbättra val av källa för dokument om hyresfastigheter, uppdatera mappningen till skattesystemet eller förfina gradern om väntat brus i arbetsflödet räknas som ett fel.
• Validera och föreslå: Kör den riktade evalen igen, kör bredare regressionssviter och visa ett kandidatförslag till Pull-begäran för teknisk granskning.
• Slut loopen: Gör en återkommande korrigering från en handläggare till en mätbar ingenjörsuppgift. Om bevisen är tvetydiga eller inte säkert kan automatiseras skickas fallet tillbaka till produktteamet i stället för att tvingas genom loopen.

Exemplet med hyresfastigheter är typiskt för ett bredare återanvändbart mönster: att använda produktionsartefakter och spår för att förbättra en Agents förmågor. Givet granskade fynd från produktionsdata, källspår, förväntad utdata från skattesystemet, relevanta kodexempel och eval-kommandon som en uppsättning indata kan Codex väsentligt förbättra prestanda och noggrannhet över veckor och månader. Detta bygger vidare på principerna som beskrivs i vårt arbete om harness engineering och Symphony, som går igenom hur man gör uppgifter begripliga för Codex, ger avgränsad kontext och verktyg samt låter validering och mänsklig granskning vara en del av miljön. 

De bevisen blir inte automatiskt en Codex-uppgift. En korrigering från en handläggare kan spegla en miss i extraktionen, ett mappningsproblem, produktbeteende som inte stöds, skattebedömning eller väntat brus i arbetsflödet. Först efter att upprepade skillnader har granskats och grupperats till ett åtgärdbart fynd gör systemet dem till en avgränsad uppgift med ett tydligt framgångsvillkor.

Vi tillämpar denna automatisering på ett avgränsat lager av produkten. Detta lager utför extraktion och mappar källdokument till skattearbetsflöden. Ingenjörer är fortsatt ansvariga för arkitektur, produktbeslut och leverans. Handläggare styr förbättringsloopen genom det arbete de redan gör: korrigerar extraherade värden, granskar deklarationer och godkänner slutliga inlämningar.

För Codex är resultatet inte en vag varning utan en avgränsad ingenjörsuppgift med bevis, redigerbara produktytor och uttryckliga valideringsgrindar. Kontexten för en representativ uppgift om hyresfastigheter kan sammanfattas så här:

Samma loop gäller även utanför hyresfastigheter. Hyresfastigheter tog omkring sex veckor och betydande teknisk tillsyn för att nå 90 % precision och recall, men det arbetet gav återanvändbara abstraktioner, granskningsartefakter, eval-konventioner och implementeringsmönster som gjorde det lättare att stödja liknande komplexa bilagor som Schedule C och Schedule A.

Tax AI visar en väg till att bygga självförbättrande Agenter. Handläggare genererar värdefulla återkopplingssignaler genom att leverera tjänsten. Produktarbetsflöden bevarar dessa signaler som strukturerade bevis. Ingenjörssystem med stöd av evals validerar förbättringar innan de når produktion, och en Agent-driven loop håller systemet i ett kontinuerligt självförbättrande flöde. 

Thrive Holdings struktur gör att vi kan återskapa denna miljö i specifika branscher. Holdings är både ägare och Operator, så våra samlade ingenjörsteam kan arbeta direkt med handläggare och produktionsdata inifrån verksamheter som Crete, inte som leverantör utan som partner. Det betyder att tekniken, produkten och tjänsten alla finns under samma tak för att hjälpa oss att röra oss snabbare och bygga exceptionella produkter.

En senior redovisningsekonom som lade 180 timmar på skatteberedning förra året lade bara 15 timmar på det i år. Hon använde en del av den tiden till att ringa var och en av sina klienter och gå igenom deras deklarationer med dem, en nivå av personlig service som inte var möjlig för ett år sedan. Resten av tiden använde hon till att ta sig an nya klienter och utöka tjänsteutbudet.

Tillsammans använder våra team nu samma tredelade design från Tax AI som en ritning för att bygga arbetsflöden i andra domäner inom Thrive Holdings⁠(öppnas i ett nytt fönster); redovisningsflöden som bokföring och revision samt operativa flöden som automatisering av IT-helpdesk. Över domäner och branscher består det bredare löftet om självförbättrande Agenter. De bästa Agenterna styrs av människor för att lära sig bli mer kapabla, mer betrodda och mer värdefulla över tid.

Om du vill veta mer om OpenAI-teamet som arbetade med detta projekt, hör av dig.