Pagbuo ng self-improving tax agent gamit ang Codex

Paano magkasamang dinebelop ng Thrive Holdings at OpenAI ang Tax AI para sa mga accountant ng Crete sa pamamagitan ng pagsasanib ng kadalubhasaan ng practitioner at loop na pinapatakbo ng Codex

Iba ang kilos ng mga real-world system sa production kaysa sa lab, at nasisira ang mga ito sa mga paraang mahirap asahan bago i-deploy. Madalas matuklasan ng mga team ang mga failure na iyon pagkatapos ng launch, saka gumugugol ng mga linggo sa pagsisiyasat ng mga edge case, pag-aayos ng mga prompt, at pagsasalin ng production feedback tungo sa matitibay na pagpapabuti ng produkto. Manwal at mabagal ang feedback loop, at gumagaling lamang ito kapag may engineer na nagpapasulong dito. Ngunit ngayon, sa maingat na dinisenyong eval infrastructure, direktang access sa mga practitioner at real-world na kapaligiran, at sa makabagong agentic na kakayahan ng Codex, maaari kang bumuo ng mga agent na nagpapahusay sa sarili.

Sa post na ito, ipapaliwanag namin kung paano namin ginamit ang Codex upang buuin ang ganitong uri ng agent. Sa nakalipas na anim na buwan, nagtulungan ang mga forward deployed engineer at researcher ng OpenAI kasama ang mga engineer ng Thrive Holdings upang buuin ang Tax AI kasama at para sa network ng 30+ accounting firm ng Crete⁠(magbubukas sa bagong window) upang tumulong sa paghahanda ng lalong kumplikadong mga tax return. Sa halip na umasa sa mga engineer para hanapin at ayusin ang bawat failure, ginagamit ng Tax AI ang Codex upang gawing structured signal ang paggamit sa production na nagpapagana sa autonomous na pagpapabuti.

Naghahanda ang mga practitioner ng Crete ng sampu-sampung libong tax return bawat season na nangangailangan ng pagproseso sa milyun-milyong pinagbabatayang dokumento. Para sa mga filing na katamtaman hanggang mataas ang pagiging kumplikado, ang data entry pa lamang ay maaaring umabot ng walong oras bawat return, at madalas na may kasamang magulong data source, mga dokumento ng nakaraang taon, at manwal na extraction at kalkulasyon. Itinuro nila sa amin ang tax preparation bilang isang mahalagang bottleneck sa pinakaabalang yugto ng tax season.

Upang lutasin ang problemang ito, nagproseso ang Tax AI ng 7,000 tax return sa mga firm ng Crete na lumahok sa pilot ngayong tax season. Ina-automate ng system ang malaking bahagi ng prosesong matrabaho sa oras ng paghahanda ng 1040 at 1041 tax return, ngunit higit pang kapansin-pansin kaysa sa pagtaas ng efficiency ay ang mismong system ay mas mahusay nang nasusukat kaysa sa bersyong unang na-deploy tatlong buwan na ang nakalipas.

Sa Tax AI, nag-a-upload ang mga practitioner ng mga source file kasama ng anumang note na partikular sa kliyente. Pagkatapos, lumilikha ang Tax AI ng submission sa tax engine, handa na para sa review. Nakatitipid ito sa mga practitioner ng humigit-kumulang isang katlo ng kanilang oras sa tax preparation, gumagawa ng mga draft return na may hanggang 97% accuracy, at nagpapataas ng throughput nang humigit-kumulang 50%, na lumilikha ng mas maraming puwang para makagugol sila ng oras sa mga kliyente. 

Masusukat namin ang pagbuting ito sa pamamagitan ng pag-unawa kung gaano katumpak na nakukumpleto ng Tax AI ang isang return nang hindi na nangangailangan ng pagwawasto sa bandang huli. Sinusukat namin ang accuracy sa pamamagitan ng pagtingin kung anong bahagi ng mga return ang umaabot sa 75%, 90%, o 100% tamang pagkumpleto ng field. Sa launch, isang-kapat lamang ng mga return ang nasa 75% tamang pagkumpleto ng field, ngunit sa loob ng anim na linggo, 86% ang umabot sa markang iyon. Nagpakita ang system ng mas mabilis pang paglago sa mga antas ng 90% at 100% tamang pagkumpleto ng field. Nagbibigay sa amin ang mga threshold na ito ng praktikal na pananaw sa kung gaano karaming follow-up ng practitioner ang kailangan pa ng iba’t ibang return. 

Sa umpisa, mas simpleng gawain ang hinawakan ng Tax AI, tulad ng mga W-2 at 1099. Habang nagpapatuloy ang season, lumipat ito sa mas kumplikadong mga return na may K-1, mga schedule, at mas mahihirap na edge case. Bawat bagong kakayahan ay nakatipid ng mas maraming oras bawat return kaysa sa nauna dahil mas mahirap at mas matagal gawin nang mano-mano ang mga gawaing hinawakan nito. Patuloy pa rin naming nakikita ang tuloy-tuloy na pag-unlad ngayon.

Susunod, ipapakita namin kung paano magkasamang in-engineer ng aming mga team ang Tax AI upang maging self-improving sa pamamagitan ng pag-asa sa tatlong kritikal na haligi: 1) feedback mula sa ekspertong practitioner, 2) mga production trace (isang structured na kasaysayan mula input hanggang huling output), at 3) isang loop ng pag-ulit na pinapatakbo ng Codex batay sa mga iniangkop na eval upang paganahin ang tuloy-tuloy at mas mabilis na pagde-develop ng produkto. Umaasa kaming magiging kapaki-pakinabang ang aming karanasan sa iba pang builder sa mga domain kung saan mahalaga ang kadalubhasaan ng practitioner sa paghubog ng kalidad ng mas malawak na system at ng data na dumadaloy rito.

Habang sumusulong kami sa mas mahihirap na bahagi ng tax preparation (K-1, mga schedule ng paupahang real estate, at mga tax form kung saan kailangang pagtugmain ang mga value sa maraming source file), naging malinaw na ang tunay na hamon ay kung magagawa ng produkto na gawing nakikita, nauunawaan, at naaaksyunan ang mga kumplikadong failure sa production.

Sa mga unang araw ng produkto, karamihan sa pagwawasto ay manwal. Maaaring iwasto ng mga practitioner ang mga error ng system, ngunit hindi nakukuha ng produkto ang buong konteksto: ang binagong value bago mag-file ay maaaring magpakita ng tunay na extraction miss, problema sa mapping, kakulangan sa suporta ng produkto, o inaasahang ingay ng workflow. Kinailangan pa rin ng follow-up mula sa engineering team upang maayos ang mga kasong iyon. Maaaring gumamit ang mga engineer ng mga coding agent, ngunit hindi pa dinisenyo ang system noon upang makagamit ng AI nang makabuluhan sa loob ng improvement loop. Wala pa kaming signal upang matukoy ang tamang bundok na aakyatin.

Dahil dito, dinisenyo namin ang system sa paligid ng tatlong haligi:

1. Manatiling malapit sa mga practitioner: Ang mga taong gumagawa ng trabaho ang kailangang gumabay sa natututuhan ng produkto. Ibinubunyag ng kanilang intuwisyon at pag-unawa kung aling mga error ang mahalaga at tumutulong magbigay-linaw kung aling mga bahagi ng workflow ang dapat pagtuunan sa susunod.
2. Buuin ang produkto upang lumikha ng ebidensya ang production: Kailangang makuha ng produkto ang higit pa sa mga input at output; kailangan nitong makuha ang buong landas mula sa source material, sa mga na-extract na field at provenance, hanggang sa downstream submission at pagwawasto ng eksperto.
3. Lumikha ng improvement loop na pinapatakbo ng Codex: Kapag nakikita at structured na ang mga isyu sa production, maaari na silang maging mga finding, iniangkop na eval, at scoped na engineering task. Pagkatapos, makatutulong ang Codex sa pagsisiyasat, pagmumungkahi ng mga pagbabago, pagva-validate ng mga ito laban sa mga naka-target at regression eval, at pagpapasulong ng produkto nang mas mabilis kaysa sa purong manwal na siklo ng pag-ulit. 

Ipinapakita ng halimbawa ng rental properties sa ibaba kung paano gumagana ang loop na iyon sa praktika, at ipinapaliwanag kung paano nagiging structured finding ang pagwawasto ng practitioner, pagkatapos ay target ng eval, at sa huli ay engineering task na naka-scope para sa Codex.

Iniuulat ang kita mula sa rental property sa Schedule E ng isang indibidwal na tax return. Mula sa pananaw ng engineering, simpleng ilarawan ang gawain ng pag-extract nito ngunit mahirap gawin nang mahusay. Kailangang basahin ng system ang magulong source material (mga sulat-kamay na note, email, spreadsheet, at iba pang file ng kliyente), i-extract ang mga field ng rental property na may kumpiyansang maimamapa ng system sa tax engine, at magpanatili ng sapat na ebidensya upang maaprubahan o maitama ng practitioner ang resulta. Ipinapakita ng pinasimpleng halimbawa sa ibaba kung ano ang maaaring maging hitsura ng mga source file at na-extract na output na iyon.

Ang pagkakaiba sa pagitan ng value na hinulaan ng agent at ng aktuwal na value mula sa na-file na tax return ay maaaring magpakita ng tunay na extraction miss, pero maaari rin itong maging preference ng practitioner, value na dinala mula sa return ng nakaraang taon sa tax engine, o value na ipinakilala o binago sa ibang bahagi ng filing workflow. Tinulungan kami ng mga practitioner na matukoy ang mga kasong iyon para malaman namin kung aling mga aksyon ang nangailangan ng pagwawasto ng practitioner o humarang sa isang submission.

Dahil nakikita namin nang detalyado ang mga pagwawastong ito, nabago namin ang proseso ng review mula sa isang panghuling hakbang pagkatapos ng failure tungo sa isang tuloy-tuloy na siklo ng pagkatuto. Dinisenyo namin ang workflow upang makuha ang mga aksyon ng eksperto bilang structured data. Ngayon, bawat intervention ay nagpapakain sa improvement loop ng produkto sa pamamagitan ng pagtatala kung ano mismo ang iminungkahi ng Tax AI, ano ang binago ng practitioner, at ano ang tuluyang napunta sa na-file na return.

Para sa isang kumplikadong workflow tulad ng rental properties, kailangang mapanatili ng system ang nangyayari sa pagitan ng mga source file at ng na-file na return. Sa landas na iyon, inaayos, hinahati, at inuuri ang mga dokumento; ine-extract ang mga field ng rental property na may mga citation pabalik sa source material; iminamapa ang mga value na iyon sa tax engine; at maaari pa ring iwasto ng mga practitioner ang mga ito bago mag-file. Ginagawang posible ng mga trace na ito sa antas ng produkto na siyasatin kung saan naganap ang failure. Upang gawing kapaki-pakinabang na mga target ng evaluation ang mga pagwawasto ng practitioner, pinoproseso ng system ang mga ito sa tatlong hakbang:

• Kunin ang pagkakaiba: Inihahambing ang output ng Tax AI sa na-file na return upang makagawa ng mga review row sa antas ng field na kumukuha sa inaasahang value, hinulaang value, at kung mukhang maaaring aksyunan ang pagkakaiba.
• Igrupo ang magkakaugnay na failure: Pinagpapangkat ang magkakatulad na review row upang maihiwalay ang mga paulit-ulit na failure ng produkto mula sa inaasahang ingay ng workflow. Halimbawa, maaaring ipakita ng paulit-ulit na pagwawasto ng practitioner na madalas mapalampas ng Tax AI ang mga field ng “fair rental days,” hindi maayos na nahahawakan ang “other expenses,” o nalilito sa maraming rental property sa loob ng iisang source package.
• Gawing mga target ng eval ang mga paulit-ulit na pattern: Kapag nasuri at nasukat na, nagiging malinaw na mga target ng eval ang mga paulit-ulit na natuklasan para mapahusay ng Codex.

Ang ikatlong haligi ay ang paglikha ng engineering loop na kayang kumilos batay sa mga bagong eval na ito. Dito nagiging sentral ang Codex.

Ipagpalagay na na-flag ng aming eval pipeline na palaging napapalampas ng Tax AI ang field na "fair rental days", habang maaasahang pinupunan ito ng mga practitioner. Dahil naka-package na ang natuklasang ito sa isang naka-target na eval set, na may mga kinatawang source package at inaasahang output, maaaring siyasatin ng Codex ang ugat ng problema nang direkta sa loob ng product scaffold.

Hindi gumagana ang Codex gamit lamang ang isang kulang-sa-antás na huling output. Sabay nitong sinusuri ang trace, eval, repo, at skills:

• Siyasatin ang pipeline: Suriin ang mga source package, extraction schema, asal ng mapper, at mga code path upang matukoy kung ang isyu ay hindi suportadong field, napalampas na extraction pattern, problema sa pagpili ng source, kakulangan sa mapper, o isyu sa grader.
• Magpatupad ng mga naka-target na pag-aayos: Palawakin ang extraction schema, pahusayin ang pagpili ng source para sa mga dokumento ng rental property, i-update ang tax-engine mapper, o pinuhin ang grader kung ang inaasahang ingay ng workflow ay binibilang bilang failure.
• I-validate at magmungkahi: Patakbuhin muli ang naka-target na eval, magpatakbo ng mas malawak na regression suite, at maglabas ng kandidatong pull request para sa engineering review.
• Isara ang loop: Gawing nasusukat na engineering task ang paulit-ulit na pagwawasto ng practitioner. Kung hindi malinaw ang ebidensya o hindi ligtas na i-automate, ibinabalik ang kaso sa product team sa halip na piliting ipadaan sa loop.

Ang halimbawa ng rental property ay sumasagisag sa mas malawak na reusable pattern: paggamit ng mga production artifact at trace upang mapahusay ang mga kakayahan ng isang agent. Kapag ibinigay ang mga nasuring natuklasan mula sa production data, mga source trace, inaasahang output ng tax engine, kaugnay na mga halimbawa ng code, at mga eval command bilang isang hanay ng input, maaaring makapaghatid ang Codex ng makabuluhang pagbuti sa performance at accuracy sa loob ng mga linggo at buwan. Nakabatay ito sa mga prinsipyong inilarawan sa aming gawain sa harness engineering at Symphony, na nagpapakita kung paano gawing malinaw sa Codex ang mga gawain, magbigay ng scoped na konteksto at mga tool, at panatilihing bahagi ng kapaligiran ang validation at human review. 

Ang ebidensyang iyon ay hindi awtomatikong nagiging gawain para sa Codex. Maaaring magpakita ang pagwawasto ng practitioner ng extraction miss, isyu sa mapping, hindi suportadong asal ng produkto, paghuhusga sa buwis, o inaasahang ingay ng workflow. Pagkatapos lamang masuri ang mga paulit-ulit na pagkakaiba at mapangkat sa isang natuklasang maaaring aksyunan saka ito ginagawang bounded task ng system na may malinaw na kondisyon ng tagumpay.

Inilalapat namin ang automation na ito sa isang bounded na layer ng produkto. Ang layer na ito ang nagsasagawa ng extraction at nagmamapa ng mga source document sa mga tax workflow. Nananatiling responsable ang mga engineer sa architecture, mga desisyon sa produkto, at pagpapadala. Ginagabayan ng mga practitioner ang improvement loop sa pamamagitan ng gawaing ginagawa na nila: pagwawasto ng mga na-extract na value, pagrerepaso ng mga return, at pag-apruba sa mga huling filing.

Para sa Codex, ang resulta ay hindi malabong alerto kundi isang scoped na engineering task na may ebidensya, nae-edit na mga surface ng produkto, at tahasang mga validation gate. Maaaring ibuod ang konteksto para sa isang kinatawang gawain sa rental property gaya ng sumusunod:

Nalalapat ang parehong loop lampas sa rental properties. Umabot nang humigit-kumulang anim na linggo at malaking engineering oversight ang rental properties upang maabot ang 90% precision at recall, ngunit ang gawaing iyon ay lumikha ng mga reusable abstraction, review artifact, eval convention, at implementation pattern na nagpadali sa pagsuporta sa mga kahalintulad na kumplikadong schedule gaya ng Schedule C at Schedule A.

Pinatutunayan ng Tax AI ang isang landas tungo sa pagbuo ng mga self-improving agent. Lumilikha ang mga practitioner ng mahahalagang feedback signal sa pamamagitan ng paghahatid ng serbisyo. Pinananatili ng mga workflow ng produkto ang mga signal na iyon bilang structured na ebidensya. Vina-validate ng mga engineering system na suportado ng eval ang mga pagpapabuti bago makarating ang mga ito sa production, at pinananatili ng loop na pinapagana ng agent ang system sa isang tuloy-tuloy na daloy ng self-improvement. 

Pinahihintulutan kami ng istruktura ng Thrive Holdings na ulitin ang kapaligirang ito sa mga partikular na industriya. Ang Holdings ay parehong owner at Operator, kaya nagagawa ng aming pinagsamang engineering team na direktang makipagtulungan sa mga practitioner at production data mula sa loob ng mga negosyo tulad ng Crete, hindi bilang vendor kundi bilang mga partner. Ibig sabihin nito, ang teknolohiya, ang produkto, at ang serbisyo ay nasa iisang bubong upang matulungan kaming kumilos nang mas mabilis at bumuo ng mga natatanging produkto.

Isang senior accountant na gumugol ng 180 oras sa tax prep noong nakaraang taon ay 15 oras na lamang ang ginugol dito ngayong taon. Ginamit niya ang bahagi ng oras na iyon sa pagtawag sa bawat isa sa kanyang mga kliyente at paggabay sa kanila sa kanilang mga return, isang antas ng mataas na pag-aasikaso na hindi posible isang taon na ang nakalipas. Ang natitirang oras ay ginamit niya upang tumanggap ng mga bagong kliyente at palawakin sa mga bagong alok na serbisyo.

Magkakasama, ginagamit na ngayon ng aming mga team ang parehong tatlong-bahaging disenyo mula sa Tax AI bilang blueprint para sa pagbuo ng mga workflow sa iba pang domain sa buong Thrive Holdings⁠(magbubukas sa bagong window); mga accounting workflow tulad ng bookkeeping at audit, at mga operational workflow tulad ng automation ng IT help desk. Sa iba’t ibang domain at industriya, nananatili ang mas malawak na pangako ng mga self-improving agent. Ang pinakamahuhusay na agent ay ginagabayan ng mga tao upang matutong maging mas may kakayahan, mas pinagkakatiwalaan, at mas mahalaga sa paglipas ng panahon.

Para matuto pa tungkol sa OpenAI team na nagtrabaho sa proyektong ito, makipag-ugnayan.