Basis entwickelt KI-Agenten für die Buchhaltung, die Fachkräfte bei komplexen Aufgaben unterstützen. Diese autonomen Systeme übernehmen zeitintensive Workflows und liefern Ergebnisse zur Überprüfung. Dabei setzt das Unternehmen von Beginn an auf die Entwicklungsumgebung Cursor. Lesen Sie, wie das Team langfristige Prozesse meistert und Qualität sicherstellt.

KI-Agenten für die Buchhaltung: Die Basis-Mission

Basis hat sich vollständig auf die Entwicklung von KI-Agenten für Buchhalter spezialisiert. Diese Agenten arbeiten autonom im Hintergrund und erledigen komplexe, langfristige Buchhaltungsworkflows. Das Ergebnis sind ausgereifte Deliverables, die von menschlichen Teams nur noch überprüft werden müssen. Dadurch können sich Fachkräfte auf wichtige Aspekte wie Urteilsvermögen und Kundenservice konzentrieren.

Die Agenten übernehmen anspruchsvolle Aufgaben für führende Buchhaltungsteams. Dazu gehören der Monatsabschluss, Unternehmens- und Partnerschaftssteuererklärungen sowie die Planung und Durchführung von Audits. Basis nutzt die Entwicklungsumgebung Cursor bereits seit dem ersten Tag, um diese Systeme zu bauen und zu verfeinern.

Warum langfristige Workflows nicht auf einen Prompt reduzierbar sind

Long-Horizon bedeutet nicht nur, dass ein Agent mehrere Stunden läuft. Es bedeutet, dass Hunderte von Entscheidungen über einen gesamten Prozess getroffen werden. Spätere Schritte hängen dabei oft von früheren Ergebnissen ab. Das System muss den relevanten Zustand bewahren, Ergebnisse von Tool-Aufrufen integrieren und sich von Fehlern erholen. Dabei kann die Menge an Informationen die Kapazität eines einzelnen Kontextfensters überschreiten.

Fehler können sich kumulieren. Ein früher Fehler beeinflusst spätere Recherchen, Berechnungen, Tool-Aufrufe und Artefakte. Das Problem dabei: Das Endergebnis verrät nicht immer, wo der Fehler begann.

Die drei Herausforderungen der Buchhaltung

Die Buchhaltung erschwert die Entwicklung zusätzlich aus drei Gründen. Erstens haben viele Ergebnisse keinen billigen, objektiven Test. Zweitens sind Ground-Truth-Beispiele aus der realen Produktionsarbeit teuer und schwer skalierbar. Drittens kann die Erstellung und Überprüfung eines Endergebnisses Stunden oder Tage dauern.

Sogar ein korrektes Endergebnis kann einen unzuverlässigen Prozess verbergen. Ein Agent kann die richtige Steuererklärung ohne Rechtsgrundlage erstellen, die korrekte Zahlung ohne Quellenangabe extrahieren oder eine brauchbare Arbeitsmappe durch einen nicht generalisierbaren Prozess erzeugen. Die Bewertung des Ergebnisses bleibt wichtig, ist aber teuer und kann nicht jede wichtige Entscheidung innerhalb einer langen Trajektorie erklären.

Kontext als entscheidender Produktionsfaktor

Die finale Ausgabe eines Agenten ist nur ein Teil des Systems. Sein Verhalten hängt vom Kontext ab, den er während der Arbeit erhält. Dazu gehören Anweisungen, Fachwissen, Beispiele, Tool-Beschreibungen, Fähigkeiten, Speicher und andere Laufzeitinformationen. Da dieser Kontext in natürlicher Sprache verfasst ist, müssen Ingenieure ihn lesen und verstehen.

Ein traditionelles Programm interpretiert denselben validen Code unabhängig davon, wie ordentlich die Dateien organisiert sind. Bei Sprachmodellen ändert die Organisation und Formulierung des Kontexts das nächste Verhalten des Modells. Ein unklarer Satz, eine vergrabene Ausnahme oder ein irreführendes Beispiel können das Produktionsverhalten verändern. Ein Kontextfile ohne vorherige Prüfung zu generieren und zu veröffentlichen, stellt ein erhebliches Risiko dar.

Behavior Specs definieren den Qualitätsstandard

Eine Behavior Spec ist eine Markdown-Datei, die wiederkehrendes Verhalten eines Agenten in einer bestimmten Situation definiert. Sie ist für Menschen und Bewertungssysteme geschrieben, die eine aufgezeichnete Trajektorie überprüfen. Es handelt sich nicht um einen Prompt, und der Agent sieht sie nicht.

Eine nützliche Spec macht klar, wann das Verhalten gilt, welche Beweise der Agent prüfen sollte, welche Entscheidung er treffen muss, welche Aktion folgt und was bei unvollständigen Beweisen zu tun ist. Zudem definiert sie, wie ein Fehler aussieht. Das Ziel ist es, das Verhalten beurteilbar zu machen, ohne jeden Schritt vorzuschreiben.

Der Bewerter erhält die Spec, die beobachtbare Trajektorie und die Beweise wie Tool-Aufrufe, Artefakte, abgerufene Quellen und Entscheidungsprotokolle. Er gibt wahr, falsch oder nicht zutreffend zurück. Das Team kann so ausgewählte Teile des Prozesses bewerten, ohne eine vollständige Ground-Truth-Antwort für die gesamte Aufgabe zu benötigen.

Cursor ist die zentrale Umgebung zur Agenten-Entwicklung

Basis verwendet Cursor, um die Agenten zu bauen und zu verfeinern. Ein Ingenieur hat eine Behavior Spec in Markdown geöffnet. Er prüft einen Satz, fragt ein Modell, ob er zu vage oder zu brüchig ist, überarbeitet die Passage und sieht eine Vorschau des fertigen Dokuments im selben Fenster. Dieselbe Umgebung dient der Verfeinerung von Prompts und Kontext, die der Agent tatsächlich sieht.

Was Cursor für diese Arbeit besonders macht:

• Ein echter Editor: Man kann die Formulierung von Kontext und Specs lesen und überarbeiten.
• Markdown-Vorschau: Bearbeiten und Live-Vorschau nebeneinander. Mitch Troyanovsky, Mitbegründer von Basis, nannte dies einen unterschätzten Vorteil für die Iteration von Specs und anderen Markdown-Dokumenten.
• Direkte Modellzusammenarbeit: Das Arbeiten mit einem Modell direkt in derselben Umgebung wie der Text.
• Einfacher Modellwechsel: Während der Iteration kann das Modell schnell gewechselt werden.
• Nebeneinander: Die Datei und das Agent-Fenster als Schleife. Jeder hat ein Agent-Fenster. Der Unterschied besteht darin, den Kontext inspizieren und ändern zu können.

Der Entwicklungszyklus von Basis

Die Ingenieure von Basis schreiben und verfeinern Behavior Specs in Cursor. Der Agent läuft in der Basis-Runtime, und ein Bewerter prüft die aufgezeichnete Trajektorie gegen die Spec.

1. Das Team einigt sich auf ein wiederkehrendes Verhalten, das gemessen werden soll.
2. Ein Ingenieur schreibt oder verfeinert die Behavior Spec in Cursor.
3. Der Agent führt seine Arbeit in der Produktion aus und produziert eine aufgezeichnete Trajektorie.
4. Ein Bewerter wertet jedes Verhalten gegen die Spec aus und gibt wahr, falsch oder nicht zutreffend zurück.
5. Ein negatives Urteil identifiziert eine Lücke zwischen dem gewünschten Verhalten und der Laufzeitumgebung.
6. Das Team aktualisiert den Laufzeitkontext, Tools, Prompts oder das Ausführungsframework. Die Formulierung wird in Cursor überarbeitet.
7. Das Team startet den Agenten erneut und prüft, ob sich das Verhalten verbessert.

Spec und Laufzeitumgebung bleiben getrennt. Die Spec ist der Standard. Die Implementierung ändert sich, bis der Agent sie konsistent erfüllt.

Dieser Ansatz entstand aus der Erfahrung von Basis beim Bau von Produktionsagenten für die Buchhaltung. Basis und Braintrust veröffentlichten ihn als offenen Standard, damit andere Teams Agentenverhalten mit demselben allgemeinen Format definieren und bewerten können.

Eine korrekte Steuerantwort kann immer noch einen schlechten Prozess verbergen. Ich möchte wissen, ob der Agent die primäre Rechtsgrundlage geprüft hat, nicht nur ob die Erklärung richtig ist. Die Spec ist, wie wir das beurteilen.

Mitch Troyanovsky
Mitbegründer von Basis

Die Arbeit selbst ist der Beweis

Basis-Agenten leisten über fünf Stunden Arbeit an einem einzelnen Deliverable. Bei einer Form-1065-Partnerschaftserklärung kann eine Aufgabe, die für Menschen etwa 30 bis 40 Stunden dauert, von einem Basis-Agenten in etwa sechs bis sieben Stunden erledigt werden. 40 Prozent der 25 führenden Unternehmen vertrauen auf Basis, ebenso wie weitere renommierte Buchhaltungsfirmen.

Der stärkste Beweis ist die Arbeit selbst: Agenten treffen viele Entscheidungen über lange Trajektorien und liefern Ergebnisse, die professionelle Buchhalter überprüfen und nutzen. Je länger und folgenreicher die Arbeit wird, desto mehr wird der Kontext zum Produktionsinput. Ingenieure müssen ihn prüfen, verstehen und überarbeiten. Cursor ist die Umgebung, in der Basis diesen Kontext pflegt. Behavior Specs machen ausgewählte Erwartungen explizit. Braintrust bewertet, ob diese Verhaltensweisen in realen Trajektorien auftraten. Fehler zeigen dem Team, was sich in der Laufzeitumgebung ändern muss.

Quelle: https://cursor.com/blog/basis