Basis entwickelt KI-Agents speziell für Buchhalter. Sie erledigen komplexe Buchhaltungs-Workflows mit langem Horizont autonom im Hintergrund und liefern review-fertige Ergebnisse, damit sich Buchhaltungsteams auf fachliche Beurteilung und Mandantenbetreuung konzentrieren können.

Diese Agents übernehmen mehrstündige, folgenreiche Aufgaben für führende Buchhaltungsteams: Monatsabschluss, Körperschafts- und Personengesellschaftssteuererklärungen, Audit-Planung und Prüfungsarbeit vor Ort. Basis hat das Unternehmen vom ersten Tag an auf Cursor aufgebaut. Den Kontext, den der Agent liest (Prompts, Skills, Anweisungen, Tool-Beschreibungen), behandeln sie mit derselben Sorgfalt wie Code – und in Cursor lesen und überarbeiten sie ihn.

#Arbeit, die sich nicht auf einen einzigen Prompt reduzieren lässt

Ein langer Horizont bedeutet nicht bloß, dass der Agent mehrere Stunden läuft. Er bedeutet Hunderte von Entscheidungen entlang einer Trajektorie, wobei spätere Schritte oft von früheren abhängen. Das System muss den relevanten Zustand bewahren, die Ergebnisse von Tool-Aufrufen einbeziehen und sich von Fehlschlägen erholen – mitunter über mehr Informationen hinweg, als in ein einzelnes Kontextfenster passen. Fehler können sich aufschaukeln. Ein früher Fehler kann spätere Recherchen, Berechnungen, Tool-Aufrufe und Artefakte beeinträchtigen, während das Endergebnis womöglich nicht erkennen lässt, wo das Problem seinen Ursprung hatte.

Im Rechnungswesen ist das aus drei Gründen noch schwieriger:

1. Für viele Ergebnisse gibt es keinen günstigen, objektiven Test.
2. Ground-Truth-Beispiele aus echter Produktivarbeit sind teuer zu erstellen und schwer zu skalieren.
3. Ein Endergebnis zu erzeugen und zu prüfen kann Stunden oder Tage dauern.

Selbst ein korrektes Endergebnis kann einen unzuverlässigen Prozess verbergen. Ein Agent könnte zur korrekten Steuererklärung gelangen, ohne sich auf eine Rechtsquelle zu stützen, die korrekte Zahl extrahieren, ohne ihre Quelle festzuhalten, oder eine brauchbare Arbeitsmappe über einen Prozess erzeugen, der sich nicht verallgemeinern lässt. Die Ergebnisbewertung bleibt wichtig, doch sie ist teuer in der Durchführung und kann nicht jede folgenreiche Entscheidung innerhalb einer langen Trajektorie erklären.

#Kontext ist eine Produktionseingabe

Die endgültige Ausgabe des Agents ist nur ein Teil des Systems. Sein Verhalten hängt vom Kontext ab, den er während der gesamten Arbeit erhält: Anweisungen, Domänenwissen, Beispiele, Tool-Beschreibungen, Skills, Memory und weitere Laufzeitinformationen. Dieser Kontext liegt in natürlicher Sprache vor – Ingenieure müssen ihn also lesen.

Ein herkömmliches Programm interpretiert denselben gültigen Code immer gleich, unabhängig davon, wie sauber die Dateien organisiert sind. Bei Sprachmodellen verändern Aufbau und Formulierung des Kontexts, was das Modell als Nächstes tut. Ein vager Satz, eine versteckte Ausnahme oder ein irreführendes Beispiel können das Verhalten in der Produktion verändern. Eine Kontextdatei zu generieren und auszuliefern, ohne sie gelesen zu haben, ist ein Produktionsrisiko.

#Verhaltensspezifikationen machen den Standard explizit

Eine Verhaltensspezifikation ist eine Markdown-Datei, die wiederkehrendes Verhalten definiert, das von einem Agent in einer bestimmten Situation erwartet wird. Sie richtet sich an die Personen und Judges, die eine aufgezeichnete Trajektorie prüfen. Sie ist kein Prompt und wird dem Agent nicht angezeigt.

Eine nützliche Spec macht deutlich, wann das Verhalten greift, welche Belege der Agent prüfen soll, welche Entscheidung er treffen soll, welche Aktion daraus folgt, was bei unvollständigen Belegen zu tun ist und wie ein Fehlschlag aussieht. Ziel ist es, das Verhalten beurteilbar zu machen, ohne jeden Schritt vorzuschreiben.

Der Judge erhält die Spec, die beobachtbare Trajektorie und die Belege (Tool-Aufrufe, Artefakte, herangezogene Quellen, Entscheidungsprotokolle). Er gibt true, false oder NA zurück. So kann das Team ausgewählte Teile des Prozesses bewerten, ohne eine vollständige Ground-Truth-Antwort für die gesamte Aufgabe zu haben.

#In Cursor überarbeiten sie den Agent

Basis nutzt Cursor, um seine Agents zu erstellen und zu verfeinern. Ein Engineer hat eine Verhaltensspezifikation in Markdown geöffnet, prüft einen Satz, fragt ein Modell, ob er zu vage oder zu fragil ist, überarbeitet die Passage und sieht sich das fertige Dokument im selben Fenster in der Vorschau an. In derselben Umgebung verfeinert das Team die Prompts und den Kontext, die der Agent tatsächlich sieht: Skills, Anweisungen, Tool-Beschreibungen.

Was Cursor zum richtigen Ort für diese Arbeit macht:

• Ein echter Editor, in dem sich die Formulierungen von Kontext und Spezifikationen lesen und überarbeiten lassen.
• Markdown-Vorschau (Bearbeiten und Live-Vorschau nebeneinander). Mitch Troyanovsky, Mitgründer von Basis, bezeichnet das als unterschätztes Unterscheidungsmerkmal beim Iterieren an Spezifikationen, Skills und anderen Markdown-Dokumenten.
• Direkt mit einem Modell arbeiten, in derselben Umgebung wie der Text.
• Einfach das Modell wechseln, während man iteriert.
• Nebeneinander: die Datei und das Agent-Fenster als Kreislauf. Ein Agent-Fenster hat jeder. Der Unterschied liegt darin, den Kontext prüfen und ändern zu können.

#Der Entwicklungszyklus

Die Ingenieure von Basis schreiben und verfeinern Verhaltensspezifikationen in Cursor. Der Agent läuft in der Basis-Laufzeitumgebung, und ein Judge bewertet die aufgezeichnete Trajektorie anhand der Spezifikation.

1. Das Team einigt sich auf ein wiederkehrendes Verhalten, dessen Messung sich lohnt.
2. Ein Ingenieur schreibt oder verfeinert die Verhaltensspezifikation in Cursor.
3. Der Agent verrichtet seine Arbeit in der Produktion und erzeugt dabei eine aufgezeichnete Trajektorie.
4. Ein Judge bewertet jedes Verhalten anhand der Spezifikation und gibt true, false oder NA zurück.
5. Ein Urteil „false“ deckt eine Lücke zwischen dem beabsichtigten Verhalten und der Implementierung zur Laufzeit auf.
6. Das Team passt Laufzeitkontext, Tools, Prompts oder das Ausführungsframework an. Die entsprechenden Formulierungen werden in Cursor überarbeitet.
7. Das Team führt den Agent erneut aus und misst, ob sich das Verhalten verbessert.

Spezifikation und Laufzeitumgebung bleiben getrennt. Die Spezifikation ist der Maßstab. Die Implementierung ändert sich so lange, bis der Agent ihn konsistent erfüllt.

Der Ansatz der Verhaltensspezifikationen ist aus der Erfahrung von Basis beim Erstellen von Produktionsagenten für die Buchhaltung entstanden. Basis und Braintrust haben ihn als offenen Standard veröffentlicht, damit andere Teams Agentenverhalten in einem einheitlichen allgemeinen Format definieren und bewerten können.

#Die Arbeit selbst ist der Beweis

So sieht diese Arbeit im Produktivbetrieb aus.

• Basis-Agents leisten mehr als 5 Stunden Arbeit an einem einzigen Deliverable.
• Bei einer Personengesellschaftserklärung nach Form 1065 erledigt ein Basis-Agent in rund 6 bis 7 Stunden Arbeit, für die Menschen etwa 30 bis 40 Stunden brauchen.
• 40 % der Top-25-Kanzleien vertrauen auf Basis – und darüber hinaus auch viele weitere führende Wirtschaftsprüfungs- und Steuerkanzleien.

Der stärkste Beweis ist die Arbeit selbst: Agents, die über lange Trajektorien hinweg viele Entscheidungen treffen und Ergebnisse liefern, die professionelle Buchhalter prüfen und nutzen.

Je länger und folgenreicher die Aufgaben werden, die Agents übernehmen, desto mehr wird ihr Kontext zu einer Produktionseingabe. Ingenieure müssen ihn prüfen, verstehen und überarbeiten.

In Cursor pflegt Basis diesen Kontext. Verhaltensspezifikationen machen ausgewählte Erwartungen explizit. Braintrust bewertet, ob diese Verhaltensweisen in echten Trajektorien tatsächlich auftraten. Fehlschläge zeigen dem Team, was in der Laufzeitumgebung zu ändern ist.