So werden Steuer-Agenten mit Codex besser

Tax AI von Thrive Holdings und OpenAI zeigt ein Muster, das viele Teams unterschätzen: Ein Agent wird nicht durch ein großes Prompt stabil, sondern durch eine Produktions-Schleife, die echte Korrekturen in messbare Tests und daraus wieder in gezielte Verbesserungen übersetzt.

Übersicht:

Was Tax AI heute leistet

Tax AI ist ein Steuer-Assistenzsystem, das in einer Pilotphase in der Crete Professionals Alliance eingesetzt wurde, einem Verbund von Accounting-Firmen. Der Kernnutzen liegt nicht nur in Automatisierung, sondern in nachweisbarer Qualitätssteigerung über die Zeit, weil das System aus echter Nutzung lernt, ohne dass jede Verbesserung als Einzelfall von Engineers „nachgebaut“ werden muss.

Im Pilotbetrieb wurden laut den Projektteams rund 7.000 Steuererklärungen verarbeitet, unter anderem für die US-Formulare 1040 und 1041. Der Workflow ist so gedacht, dass Praktiker Quelldateien und Mandantenhinweise hochladen, Tax AI daraus eine Einreichung für die Tax-Engine vorbereitet und die Fachkräfte anschließend prüfen, korrigieren und freigeben.

Bemerkenswert ist der Verlauf: Zu Beginn wurden eher einfache Dokumenttypen wie W-2 und 1099 zuverlässig übernommen, später kamen komplexere Konstellationen dazu, etwa K-1, zusätzliche Schedules und Sonderfälle. Genau dieser Schritt in die „unangenehmen“ Fälle entscheidet, ob ein Agent im Alltag wirklich Nutzen stiftet.

Mehr Kontext zu den beteiligten Organisationen: Crete Professionals Alliance ist der Praxis-Partner im Accounting, Thrive Holdings beschreibt die Zusammenarbeit mit OpenAI unter Thrive Holdings x OpenAI, OpenAI selbst skizziert die Partnerschaft in OpenAI takes an ownership stake in Thrive Holdings.

Warum Produktion anders scheitert als ein Laborsetup

Im Labor wirken Agenten oft stabil, weil Daten sauber sind, Randfälle fehlen und das Team die Testinputs kennt. In echter Steuerpraxis sieht es anders aus: heterogene Scans, E-Mails, Tabellen, handschriftliche Notizen, Vorjahresunterlagen und widersprüchliche Quellen prallen in einem Fallpaket zusammen.

Die typische Reaktion nach dem Go-live ist ein mühsamer Kreislauf: Fehler tauchen erst nach dem Einsatz auf, dann werden Ausnahmen gesammelt, Prompts nachjustiert, Parser und Mapping-Regeln geändert und das Ganze erneut deployt. Das Problem ist weniger „das Modell“, sondern dass Produktionsfeedback häufig unstrukturiert bleibt und damit nicht zuverlässig in Produktarbeit übersetzbar ist.

Die zentrale Designfrage lautet deshalb: Kann das System komplexe Fehler so sichtbar machen, dass daraus eine klare, überprüfbare Verbesserung wird, statt einer langen Debatte darüber, ob es ein Extraktionsfehler, ein Mapping-Problem, fehlende Produktunterstützung oder schlicht erwartbares Workflow-Rauschen war?

Der Drei-Signale-Loop für Selbstverbesserung

Tax AI wurde um eine Schleife gebaut, die drei Signalarten zusammenführt. Das Ziel ist nicht „autonom alles“, sondern ein schneller, eval-gestützter Weg von beobachteter Korrektur zu belastbarer Produktänderung, mit klaren Stopps für menschliche Entscheidung.

• Praktiker-Feedback: Die Fachkräfte im Alltag entscheiden, welche Abweichungen wirklich relevant sind. Sie unterscheiden echte Fehler von Präferenzen, Vorjahresübernahmen oder Änderungen, die an anderer Stelle im Prozess entstehen.

• Produktions-Traces: Statt nur Input und Output zu speichern, hält das System den Weg dazwischen fest, also Dokument-Splitting, Klassifikation, extrahierte Felder mit Belegen, Mapping in die Tax-Engine und die späteren Korrekturen. Ein „Trace“ ist damit eine nachvollziehbare Ereigniskette, die Debugging möglich macht.

• Codex-Iteration über Evals: Wiederkehrende Muster werden in zielgerichtete Evaluations-Sets überführt. Erst dann wird daraus ein klar begrenzter Task, den Codex bearbeiten kann, inklusive Validierung über gezielte und Regression-Evals.

Für Teams, die diesen Teil nachbauen wollen, lohnt ein Blick auf zwei Bausteine: OpenAI beschreibt den Ansatz „Harness Engineering“ als Interface für Agents unter Harness engineering, und „Symphony“ als Orchestrierungs-Spezifikation unter Symphony sowie im Repo openai/symphony. Für Evals sind die Einstiege Evals API und Getting Started mit OpenAI Evals hilfreich.

Praxisbeispiel Mietobjekte und Schedule E

Mieteinnahmen und Kosten aus Immobilien landen bei US-Returns typischerweise auf Schedule E. Die Aufgabe klingt simpel, ist aber in der Praxis ein Minenfeld, weil die Informationen über viele, oft unsaubere Quellen verteilt sind und mehrere Objekte in einem Paket vermischt sein können.

Was im Workflow technisch passieren muss

• Quelle verstehen: E-Mails, Tabellen, Notizen und Scans werden eingeordnet und in handhabbare Dokumentteile zerlegt.

• Felder extrahieren: Das System zieht relevante Werte heraus, versieht sie mit Belegen, und hält fest, aus welcher Quelle die Zahl stammt.

• In die Tax-Engine mappen: Extrahierte Felder werden auf konkrete Felder der nachgelagerten Tax-Engine abgebildet, damit der Return als Entwurf vorliegt.

• Review und Korrektur: Praktiker passen Werte an, und genau diese Eingriffe werden als strukturierte Daten gespeichert.

Wie aus einer Korrektur ein „Hill to climb“ wird

Angenommen, Tax AI trifft ein Feld wiederholt nicht, etwa „fair rental days“, während Praktiker es konsistent nachtragen. Ein einzelner Fall ist noch kein Engineering-Signal. Erst wenn sich das Muster über mehrere Returns bestätigt, wird es als „Finding“ klassifiziert und als Eval-Ziel paketiert.

1. Differenz erfassen: Vorhersage und final eingereichter Wert werden als Feldzeile gegenübergestellt, inklusive Einschätzung, ob die Abweichung voraussichtlich „actionable“ ist.

2. Muster bündeln: Ähnliche Abweichungen werden gruppiert, damit wiederkehrende Produktfehler von erwartbarem Workflow-Rauschen getrennt werden.

3. Eval bauen: Repräsentative Quellpakete plus erwartete Outputs ergeben ein Testset, das eine klare Erfolgskondition definiert.

4. Codex tasken: Codex untersucht Trace, Schema, Mapper und Grader, setzt gezielte Änderungen um und muss die neuen Evals plus Regression-Tests bestehen.

Wichtig ist die Begrenzung: Codex arbeitet in einem „writable“ Produktbereich, während Produktionsbelege, Traces und finale Returns als schreibgeschützter Kontext dienen. So kann die Ursache analysiert werden, ohne die Evidenz zu verändern. Wenn die Evidenz nicht eindeutig ist oder eine Änderung fachliches Steuerurteil erfordern würde, wird der Fall bewusst zurück an Produktteam und Engineers geroutet.

Bauplan für andere Branchen und Workflows

Das Muster ist übertragbar, weil es nicht steuer-spezifisch ist. Übertragbar sind vor allem die Artefakte: Review-Zeilen, Trace-Konventionen, Eval-Suites, Grader-Logik und der kulturelle Prozess, dass Praktiker die Signale liefern, während Engineers den Rahmen und die Releases verantworten.

Die Teams berichten, dass das Mietobjekt-Modul mehrere Wochen und spürbare Engineering-Aufsicht brauchte, bis es stabil auf hohem Niveau lief. Der Ertrag ist ein Set wiederverwendbarer Abstraktionen, das spätere Erweiterungen wie weitere Schedules beschleunigt, weil die nächste Domäne nicht wieder bei null beginnt.

Genau hier liegt die strategische Idee hinter dem Thrive-Modell als Owner-Operator: Zugriff auf echte Arbeit, echte Datenflüsse und echte Verantwortlichkeit im Betrieb. Dadurch entsteht eine Lernkurve, die reine „Vendor-Projekte“ oft nicht erreichen, weil Signale zu spät, zu gefiltert oder zu unvollständig ankommen.

Konkreter Praxisnutzen aus dem Projekt: Eine Senior-Accountant reduzierte ihren tax-prep Aufwand in einer Saison von 180 Stunden auf 15 Stunden. Den Gewinn steckte sie nicht in „weniger Arbeit“, sondern in mehr Mandantengespräche und zusätzliche Fälle, also in Umsatz und Bindung statt in Dateneingabe.

Entscheidungsregeln und Markteinordnung

Entscheidungsregel: Automatisierte Selbstverbesserung nur dann, wenn ein Fehlerbild (1) wiederholt auftritt, (2) als „actionable“ eingeordnet wurde, (3) ein eindeutiger Sollwert im Eval existiert und (4) eine Regression-Suite sicherstellt, dass der Fix nicht an anderer Stelle Schaden anrichtet. Alles andere gehört in menschliche Klärung, weil sonst „Automatisierung“ nur schneller falsche Entscheidungen produziert.

Für die Markteinordnung hilft ein kompaktes Modell, das man als Signal Tempo Risiko lesen kann:

• Signal: Ohne strukturierte Korrekturen und Traces bleibt ein Agent blind, egal wie stark das Modell ist.

• Tempo: Evals machen Verbesserungen wiederholbar und schnell, statt jede Saison erneut „Prompt-Archäologie“ zu betreiben.

• Risiko: Domänen wie Steuern verlangen klare Grenzen, Auditierbarkeit und menschliche Freigaben, damit Vertrauen entsteht.

Wer das nachbauen will, sollte zuerst nicht über „mehr Autonomie“ sprechen, sondern über eine bessere Produktionsbeobachtung. Sobald Traces, Review-Artefakte und Evals stehen, wird Codex von einem reinen Coding-Tool zu einem Beschleuniger für gezielte, überprüfbare Produktentwicklung. Einstiegspunkte sind die Codex-Grundlagen in Introducing Codex und praktische Hinweise im Help Center Codex CLI Getting Started.