Zelfverbeterende belastingagents bouwen met Codex
Door Members of Technical Staff: Aravind Srinivasan en Samay Shamdasani (Thrive Holdings), Arthur Fernandes Araujo en John de Wasseige (OpenAI)
Hoe Thrive Holdings en OpenAI samen Tax AI voor accountants van Crete ontwikkelden door expertise van experts te combineren met een door Codex aangedreven lus
Systemen in de echte wereld gedragen zich in productie anders dan in een lab en gaan stuk op manieren die vóór uitrol moeilijk te voorzien zijn. Teams ontdekken die fouten vaak pas na de lancering en besteden dan weken aan het onderzoeken van edge cases, het aanpassen van prompts en het vertalen van productiefeedback naar duurzame productverbeteringen. De feedbacklus is handmatig en traag, en verbetert alleen wanneer een engineer die vooruithelpt. Maar vandaag kun je, met doordacht ontworpen eval-infrastructuur, directe toegang tot experts en echte omgevingen, en de toonaangevende agentische mogelijkheden van Codex, agents bouwen die zichzelf verbeteren.
In dit artikel leggen we uit hoe we Codex hebben gebruikt om dit type agent te bouwen. In de afgelopen zes maanden werkten forward deployed engineers en onderzoekers van OpenAI samen met engineers van Thrive Holdings om Tax AI te bouwen, samen met en voor het netwerk van meer dan 30 accountantskantoren van Crete(opent in een nieuw venster), om te helpen bij het opstellen van steeds complexere belastingaangiften. In plaats van te vertrouwen op engineers om elke fout te vinden en te verhelpen, gebruikt Tax AI Codex om productiegebruik om te zetten in gestructureerde signalen die autonome verbetering aandrijven.
Experts bij Crete stellen elk seizoen tienduizenden belastingaangiften op, waarvoor miljoenen onderliggende documenten moeten worden verwerkt. Bij aangiften met een gemiddelde tot hoge complexiteit kan alleen al de gegevensinvoer acht uur per aangifte kosten, vaak met rommelige databronnen, documenten van voorgaande jaren en handmatige extractie en berekening. Zij wezen ons op belastingvoorbereiding als een belangrijke bottleneck tijdens de drukste periode van het belastingseizoen.
Om dit probleem op te lossen verwerkte Tax AI dit belastingseizoen 7.000 belastingaangiften bij de Crete-kantoren die aan de pilot deelnamen. Het systeem automatiseert een groot deel van het tijdsintensieve proces van het opstellen van belastingaangiften 1040 en 1041, maar nog overtuigender dan de efficiëntiewinst is dat het systeem zelf meetbaar beter is dan de versie die drie maanden geleden voor het eerst werd uitgerold.
In Tax AI uploaden experts bronbestanden samen met eventuele klantspecifieke notities. Tax AI maakt vervolgens een indiening voor de tax engine, klaar voor beoordeling. Het bespaart experts ongeveer een derde van hun tijd aan belastingvoorbereiding, stelt aangiften op met tot 97% nauwkeurigheid en verhoogt de doorvoer met ongeveer 50%, waardoor er meer ruimte ontstaat om tijd met cliënten door te brengen.
We kunnen deze verbetering kwantificeren door te begrijpen hoe nauwkeurig Tax AI een aangifte kan voltooien zonder later correctie nodig te hebben. We meten nauwkeurigheid door te kijken welk aandeel aangiften 75%, 90% of 100% correcte veldvoltooiing bereikt. Bij de lancering bereikte slechts een kwart van de aangiften 75% correcte veldvoltooiing, maar binnen zes weken haalde 86% dat niveau. Het systeem liet nog snellere groei zien op de niveaus van 90% en 100% correcte veldvoltooiing. Deze drempels geven ons een praktisch beeld van hoeveel opvolging door experts verschillende aangiften nog vereisen.
In het begin verwerkte Tax AI eenvoudiger werk, zoals W-2's en 1099's. Naarmate het seizoen vorderde, ging het over op complexere aangiften met K-1's, schedules en lastigere edge cases. Elke nieuwe mogelijkheid bespaarde meer tijd per aangifte dan de vorige, omdat de taken die het overnam moeilijker en tijdrovender waren om handmatig uit te voeren. Ook vandaag zien we nog steeds voortdurende vooruitgang.
Hierna lopen we door hoe onze teams Tax AI samen hebben ontwikkeld om zichzelf te verbeteren, steunend op drie cruciale pijlers: 1) feedback van deskundige experts, 2) productietraces (een gestructureerde geschiedenis van input tot eindoutput), en 3) een door Codex aangedreven iteratielus op basis van op maat gemaakte evals om continue, snellere productontwikkeling mogelijk te maken. We hopen dat onze ervaring nuttig zal zijn voor andere bouwers in domeinen waar expertise van experts essentieel is om de kwaliteit van het overkoepelende systeem en de data die erdoorheen lopen vorm te geven.
Naarmate Tax AI werd uitgebreid naar complexere aangiften, bleef het aandeel beoordeelde aangiften dat 75%, 90% en volledige voltooiing bereikte gedurende het belastingseizoen stijgen.
Toen we ons op moeilijkere onderdelen van belastingvoorbereiding stortten (K-1's, schedules voor huurvastgoed en belastingformulieren waarbij waarden over meerdere bronbestanden moesten worden afgestemd), werd duidelijk dat de echte uitdaging was of het product complexe productiefouten zichtbaar, begrijpelijk en bruikbaar kon maken.
In de beginperiode van het product gebeurde het grootste deel van de correctie handmatig. Experts konden systeemfouten corrigeren, maar het product legde niet de volledige context vast: een gewijzigde waarde vóór indiening kon wijzen op een echte extractiefout, een mappingprobleem, ontbrekende productondersteuning of verwachte workflowruis. Om die gevallen uit te zoeken was nog steeds opvolging door het engineeringteam nodig. Engineers konden coding agents gebruiken, maar het systeem was nog niet ontworpen om AI op een betekenisvolle manier binnen een verbeterlus te gebruiken. We hadden niet het signaal om de juiste berg te vinden om te beklimmen.
Dat bracht ons ertoe het systeem rond drie pijlers te ontwerpen:
- Blijf dicht bij experts: De mensen die het werk doen moeten sturen wat het product leert. Hun intuïtie en inzicht laten zien welke fouten ertoe doen en helpen bepalen op welke delen van de workflow het daarna zinvol is te focussen.
- Bouw het product zo dat productie bewijs creëert: Het product moet meer vastleggen dan alleen input en output; het moet het volledige pad vastleggen van bronmateriaal, naar geëxtraheerde velden en herkomst, naar onderliggende indiening en expertcorrectie.
- Creëer een door Codex aangedreven verbeterlus: Zodra productieproblemen zichtbaar en gestructureerd zijn, kunnen ze bevindingen, op maat gemaakte evals en afgebakende engineeringtaken worden. Codex kan dan helpen bij het onderzoeken, wijzigingen voorstellen, die valideren met gerichte en regressie-evals en het product sneller vooruitbrengen dan een puur handmatige iteratiecyclus.
Het voorbeeld van huurwoningen hieronder laat zien hoe die lus in de praktijk werkt en neemt je mee van een correctie door een expert naar een gestructureerde bevinding, vervolgens een evaluatiedoel en uiteindelijk een voor Codex afgebakende engineeringtaak.
Inkomsten uit huurwoningen worden gerapporteerd op Schedule E van een individuele belastingaangifte. Vanuit engineeringperspectief is de taak om die te extraheren eenvoudig te beschrijven, maar moeilijk goed uit te voeren. Het systeem moet rommelig bronmateriaal lezen (handgeschreven notities, e-mails, spreadsheets en andere cliëntbestanden), de velden voor huurwoningen extraheren die het systeem met vertrouwen aan de tax engine kan koppelen, en genoeg bewijs bewaren zodat een expert het resultaat kan goedkeuren of corrigeren. Het vereenvoudigde voorbeeld hieronder laat zien hoe die bronbestanden en geëxtraheerde outputs eruit kunnen zien.
Een bronpakket voor huurwoningen wordt genormaliseerd naar velden met bronverwijzingen voordat die worden gekoppeld aan onderliggende concepten in de tax engine.
Een verschil tussen de door de agent voorspelde waarde en de werkelijke waarde uit de ingediende belastingaangifte kan wijzen op een echte extractiefout, maar het kan ook gaan om een voorkeur van een expert, een waarde die in de tax engine is overgenomen uit de aangifte van een vorig jaar, of een waarde die elders in de aangifteworkflow is ingevoerd of gewijzigd. Experts hielpen ons die gevallen te onderscheiden, zodat we konden vaststellen voor welke acties een correctie door een expert nodig was of welke een indiening blokkeerden.
Doordat we deze correcties in detail konden zien, veranderden we het beoordelingsproces van een afsluitende stap na een mislukking in een continue leercyclus. We ontwierpen de workflow zo dat expertacties als gestructureerde data werden vastgelegd. Nu voedt elke interventie de verbeterlus van het product door precies vast te leggen wat Tax AI voorstelde, wat de expert wijzigde en wat uiteindelijk in de ingediende aangifte terechtkwam.
Voor een complexe workflow zoals huurwoningen moet het systeem behouden wat er gebeurt tussen de bronbestanden en de ingediende aangifte. Onderweg worden documenten geordend, gesplitst en geclassificeerd; velden voor huurwoningen worden geëxtraheerd met bronverwijzingen naar het bronmateriaal; die waarden worden gekoppeld aan de tax engine; en experts kunnen ze vóór indiening nog corrigeren. Die traces op productniveau maken het mogelijk te onderzoeken waar een fout is opgetreden. Om correcties van experts om te zetten in bruikbare evaluatiedoelen, verwerkt het systeem ze in drie stappen:
- Leg het verschil vast: De output van Tax AI wordt vergeleken met de ingediende aangifte om beoordelingsregels op veldniveau te maken die de verwachte waarde, de voorspelde waarde en of het verschil bruikbaar lijkt vastleggen.
- Groepeer verwante fouten: Vergelijkbare beoordelingsregels worden gegroepeerd om terugkerende productfouten te scheiden van verwachte ruis in de workflow. Herhaalde correcties door experts kunnen bijvoorbeeld laten zien dat Tax AI vaak velden voor “fair rental days” mist, “overige kosten” verkeerd verwerkt of meerdere huurwoningen binnen hetzelfde bronpakket door elkaar haalt.
- Zet herhaalde patronen om in evaluatiedoelen: Zodra ze zijn beoordeeld en gemeten, worden herhaalde bevindingen duidelijke evaluatiedoelen voor Codex om te verbeteren.
Beoordelingsregels voor huurwoningen scheiden terugkerende productfouten van verwachte ruis en zetten de bruikbare gevallen vervolgens om in evaluatiedoelen die Codex een berg geven om te beklimmen.
De derde pijler is het creëren van een engineeringlus die op deze nieuwe evals kan handelen. Hier wordt Codex centraal.
Stel dat onze eval-pijplijn signaleert dat Tax AI consequent het veld "fair rental days" mist, terwijl experts het betrouwbaar invullen. Omdat deze bevinding al is verpakt in een gerichte evalset, met representatieve bronpakketten en verwachte outputs, kan Codex de hoofdoorzaak direct binnen de productarchitectuur onderzoeken.
Codex werkt niet alleen met een ondermaatse eindoutput. Het inspecteert de trace, eval, repo en skills samen:
- Onderzoek de pijplijn: Inspecteer bronpakketten, extractieschema's, gedrag van de mapper en codepaden om te bepalen of het probleem een niet-ondersteund veld, een gemist extractiepatroon, een probleem met bronselectie, een leemte in de mapper of een graderprobleem is.
- Voer gerichte oplossingen door: Breid het extractieschema uit, verbeter bronselectie voor documenten over huurwoningen, werk de mapper van de tax engine bij of verfijn de grader als verwachte workflowruis als fout wordt meegeteld.
- Valideer en stel voor: Voer de gerichte eval opnieuw uit, draai bredere regressiesuites en toon een kandidaat-pull request voor engineeringreview.
- Sluit de lus: Zet een terugkerende correctie door een expert om in een meetbare engineeringtaak. Als het bewijs dubbelzinnig is of niet veilig te automatiseren, gaat de zaak terug naar het productteam in plaats van geforceerd door de lus te worden geduwd.
De end-to-end-lus voor zelfverbetering: productietraces brengen terugkerende correcties op veldniveau aan het licht, die foutsignalen worden die Codex samen met de trace, evals, repo en skills kan inspecteren. Bruikbare patronen worden afgebakende evals en kandidaat-productwijzigingen; dubbelzinnige gevallen gaan terug naar engineers voor beoordeling. Elke uitgebrachte verbetering levert nieuw productiebewijs op voor de volgende cyclus.
Het voorbeeld van huurwoningen staat symbool voor een breder herbruikbaar patroon: productie-artefacten en traces gebruiken om de mogelijkheden van een agent te verbeteren. Met beoordeelde bevindingen uit productiedata, brontraces, verwachte output van de tax engine, relevante codevoorbeelden en eval-commando's als invoerset kan Codex de prestaties en nauwkeurigheid in de loop van weken en maanden wezenlijk verbeteren. Dit bouwt voort op de principes die zijn beschreven in ons werk over harness engineering en Symphony, waarin wordt uitgelegd hoe je taken leesbaar maakt voor Codex, afgebakende context en tools biedt en validatie en menselijke beoordeling onderdeel van de omgeving houdt.
Dat bewijs wordt niet automatisch een Codex-taak. Een correctie door een expert kan wijzen op een extractiefout, een mappingprobleem, niet-ondersteund productgedrag, fiscaal oordeel of verwachte workflowruis. Pas nadat herhaalde verschillen zijn beoordeeld en gegroepeerd tot een bruikbare bevinding, zet het systeem ze om in een afgebakende taak met een duidelijke succesvoorwaarde.
We passen deze automatisering toe op een afgebakende laag van het product. Deze laag voert extractie uit en koppelt brondocumenten aan fiscale workflows. Engineers blijven verantwoordelijk voor architectuur, productbeslissingen en uitrol. Experts sturen de verbeterlus via het werk dat ze al doen: geëxtraheerde waarden corrigeren, aangiften beoordelen en definitieve indieningen goedkeuren.
Voor Codex is het resultaat geen vage waarschuwing maar een afgebakende engineeringtaak met bewijs, bewerkbare productoppervlakken en expliciete validatiepoorten. De context voor een representatieve taak rond huurwoningen kan als volgt worden samengevat:
Dezelfde lus geldt ook buiten huurwoningen. Huurwoningen kostten ongeveer zes weken en aanzienlijke engineeringbegeleiding om 90% precisie en recall te bereiken, maar dat werk leverde herbruikbare abstracties, beoordelingsartefacten, eval-conventies en implementatiepatronen op die het makkelijker maakten om vergelijkbaar complexe schedules zoals Schedule C en Schedule A te ondersteunen.
Tax AI bewijst een pad naar het bouwen van zichzelf verbeterende agents. Experts genereren waardevolle feedbacksignalen door de dienst te leveren. Productworkflows bewaren die signalen als gestructureerd bewijs. Door evals ondersteunde engineeringsystemen valideren verbeteringen voordat ze productie bereiken, en een door agents aangedreven lus houdt het systeem in een continue stroom van zelfverbetering.
De structuur van Thrive Holdings stelt ons in staat deze omgeving in specifieke sectoren te repliceren. Holdings is zowel eigenaar als operator, waardoor onze gecombineerde engineeringteams direct kunnen werken met experts en productiedata binnen bedrijven zoals Crete, niet als leverancier maar als partners. Dit betekent dat de technologie, het product en de dienst allemaal onder één dak zitten, zodat we sneller kunnen bewegen en uitzonderlijke producten kunnen bouwen.
Een senior accountant die vorig jaar 180 uur aan belastingvoorbereiding besteedde, besteedde er dit jaar nog maar 15 uur aan. Ze gebruikte een deel van die tijd om al haar cliënten te bellen en hun aangiften met hen door te nemen, een niveau van persoonlijke service dat een jaar geleden niet mogelijk was. De rest van die tijd gebruikte ze om nieuwe cliënten aan te nemen en nieuwe diensten aan te bieden.
Samen gebruiken onze teams nu hetzelfde driedelige ontwerp van Tax AI als blauwdruk voor het bouwen van workflows in andere domeinen binnen Thrive Holdings(opent in een nieuw venster); financiële workflows zoals boekhouding en audit, en operationele workflows zoals automatisering van de IT-helpdesk. In alle domeinen en sectoren blijft de bredere belofte van zichzelf verbeterende agents overeind. De beste agents worden door mensen gestuurd om te leren in de loop van de tijd capabeler, betrouwbaarder en waardevoller te worden.
Wil je meer weten over het OpenAI-team dat aan dit project werkte, neem dan contact op.


