KI-Agenten mit Datenzugriff auf das Hauptbuch, über das sie urteilen
Agentenbasierte Produkte entscheiden zur Laufzeit, was sie fragen, und genau das macht sie nützlich und ihre Eingaben tragend. Maesn gibt Ihrem Agenten eine Form für Kunden, Rechnungen, Eingangsrechnungen, Konten und Buchungen, aus welchem Buchhaltungssystem jeder Ihrer Kunden sie auch führt.
Welche Kosten das sind, zu welcher Periode sie gehören, was die Zahl bedeutet, wie die Antwort zu formulieren ist.
- Welche Konten es gibt
- Welche Steuersätze gelten
- Welche Dimensionen es gibt
Ihr Agent fragt zur Laufzeit, der Endpunkt stand lange vorher fest
Der Vorteil eines Agenten ist, dass niemand vorab entschieden hat, welche Frage er stellt. Die Systeme, die er fragt, sind auf der gegenteiligen Annahme gebaut.
Das ist die Zahl hinter einem Satz, zu dem die Plattform immer gestanden hat. Filtern, Sortieren und Paginieren werden unterstützt, wo das System darunter sie unterstützt, und was jeder Endpunkt annimmt, ist veröffentlicht statt angedeutet. Zusammengezählt hatte es niemand, und zusammengezählt sagt es etwas Bestimmtes über agentenbasierte Produkte: für die meisten Objekte ist die einzige Frage, die Sie auf die Leitung geben können, was sich seit Ihrer letzten Abfrage geändert hat. Gesagt zu bekommen statt zu fragen ist noch seltener, denn ein Ereignis gibt es nur dort, wo das System darunter eines sendet, und solche Systeme sind in diesem Markt in der Minderheit.
Für eine klassische Integration ist das ein Ärgernis, um das Sie einmal herumprogrammieren. Für einen Agenten ist es Architektur, denn genau die Flexibilität, die Ihr Produkt verkauft, ist das, was die Leitung nicht tragen kann. Der Ausweg ist keine reichere Abfragesprache, sondern eine andere Aufteilung: breit über ein Modell lesen, das Gelesene halten und den Agenten darauf flexibel sein lassen. Das einheitliche Modell macht den breiten Lesezugriff bezahlbar, denn derselbe Aufruf und dieselben Feldnamen funktionieren auf jedem System, das Ihre Kunden einsetzen, statt auf je einem Dialekt.
Die zweite Hälfte des Problems ist leiser und teurer. Ein Modell, das buchen soll, liefert eine Kontonummer, einen Steuersatz und eine Kostenstelle, ob man ihm nun gesagt hat, welche es gibt, oder nicht, denn eine plausible Antwort zu erzeugen ist seine Aufgabe. In einem Chatfenster ist eine plausible Antwort eine schlechte Antwort. In einem Buchhaltungssystem ist sie eine Buchung.
Jedes Schreibrezept liest zuerst das Vokabular des Kunden selbst
Keine Regel, die wir erfunden hätten. Vier der sechzehn dokumentierten Rezepte beginnen mit denselben drei Lesezugriffen, bevor sie überhaupt einen Schreibvorgang beschreiben, und zwei weitere beginnen mit zweien davon.
Der eigene Kontenrahmen dieses Kunden, kein Standardrahmen
Die Steuersätze, die in genau dieser Installation eingerichtet sind
Kostenstellen und worauf ihre Buchungen sonst zeigen
Ein Schreibvorgang, der das Konto, den Satz und die Dimension trägt, die die Lesezugriffe zurückgaben.
Beginnt mit einem vierten Lesezugriff, den die anderen nicht haben: in welche Journale eine Buchung darf.
Zwei Schreibvorgänge statt einem: einmal die Eingangsrechnung selbst, und einmal die Zahlung darauf.
Die Rechnung oder ein Vorschlag zur Prüfung, dann die Zahlung, die sie ausgleicht.
Als Anforderung gelesen ist das unauffällig, denn es ist, was korrekte Buchführung schon immer gebraucht hat: Sie buchen auf ein Konto, das es gibt, zu einem Satz, den diese Installation verwendet, gegen eine Dimension, die dieser Kunde wirklich führt. Als Anweisung an einen Agenten gelesen ist es das ganze Design. Der Erdungs-Lesezugriff ist der Schritt, der aus dem Vorschlag eines Modells etwas Prüfbares macht, und er ist der Schritt, den ein Produkt unter Zeitdruck weglässt, denn eine fest verdrahtete Kontonummer funktioniert beim ersten Kunden.
Was eine vereinheitlichte Schicht hier ändert, ist nicht, dass es den Schritt gibt, sondern dass es überall derselbe Schritt ist. Ein Aufruf gibt den Kontenrahmen zurück, ob Ihr Kunde in DATEV Rechnungswesen bucht oder in etwas ganz anderem, und die Feldnamen kommen aus einem Datenmodell statt aus dem Vokabular des jeweiligen Herstellers. Ihr Produkt setzt also “die Bücher dieses Kunden lernen” einmal um, und einen Kunden auf einem System anzubinden, das Sie nie gesehen haben, ist eine Verbindung und kein Projekt.
Zu welchem Ihrer Kunden ein Aufruf gehört, ist darunter geklärt, durch die Verbindung, die jeder von ihnen freigegeben hat, und deshalb fasst ein Agent nie die Zugangsdaten von jemandem an und reicht nie weiter, als die Person reichen könnte, die den Zugriff erteilt hat.
Ein anspruchsvoller Client, und eine Anbindung, die ihm standhält
Agentenbasierte Produkte lesen mehr als formularbasierte, und sie lesen stoßweise, weil aus einer Nutzerfrage ein Dutzend Abfragen werden können, bevor eine Antwort dasteht.
Eine einzelne Frage kann sich in viele Lesezugriffe auffächern, und die verlassen Ihr Backend gemeinsam und nicht höflich verteilt.
Anfragen eines Mandanten erreichen das Zielsystem nacheinander, und eine Token-Auffrischung darunter kann deshalb nicht überholt werden.
Das Verhalten rechts ist aus einem bestimmten Grund dokumentiert und nicht als allgemeines Versprechen. Mehrere Zielsysteme brechen die Authentifizierung ab, wenn parallele Anfragen eintreffen, während ein Token erneuert wird, und eine erneute Freigabe ist kein Wiederholungsversuch, sie ist die Bitte an Ihren Kunden, sich noch einmal zu verbinden. Die Reihung je Mandant ist das, was aus einem Stoß keinen solchen Anruf werden lässt. Mehr tut sie nicht: die eigenen Ratenbegrenzungen des Zielsystems gelten weiterhin, und eine Ablehnung erreicht Sie als eigene Kategorie und nicht als allgemeiner Fehlschlag.
Der Rest des Ergebnisses ist das, was Sie nicht mehr bauen. Eine Form für eine Rechnung über jedes System im Verzeichnis, ein Freigabeablauf, eine Stelle, an der die jährliche brechende Änderung eines Herstellers aufgefangen wird. Für ein agentenbasiertes Produkt ist das keine Bequemlichkeit, sondern die Frage, wohin das Team geht: jede Woche, die für fremde Paginierung draufgeht, ist eine Woche, die nicht in das Modell fließt, wegen dem die Kunden das Produkt gekauft haben. Wo ein Schreibvorgang nicht sofort verarbeitet werden kann, wird daraus eine Aufgabe, die Sie zur Bestätigung abfragen, “ist es angekommen” bleibt also eine beantwortbare Frage.
Produkte mit einem Modell im Kern laufen bereits darauf
Finto hat eine produktionsreife DATEV-Integration in Tagen ausgeliefert.
“Maesn hat uns ermöglicht, eine produktionsreife DATEV-Integration innerhalb von Tagen zu starten, und gibt unserer KI damit strukturierte Finanzdaten und unseren Kunden ein reibungsloses Onboarding.”
Rally ist die zweite, und die eigene Seite beschreibt die Form gut genug, dass wir es nicht tun müssen: Belege kommen aus dem Feld, Rally AI zieht die Felder heraus, ordnet Zahlungen zu und korrigiert Fehler, und was das Hauptbuch des Kunden erreicht, ist bereits strukturiert. Wie ihr CTO dorthin gekommen ist, steht in der Rally Case Study, und zu übernehmen ist daraus die Reihenfolge und nicht das Adjektiv: das Modell fällt das Urteil, die Anbindung liefert, und keines von beiden soll die Aufgabe des anderen erledigen.
Beide sind das, was die Branchensicht eine Weiterentwicklung von SaaS nennt und keine Kategorie daneben, und für den Markt vertikaler Software als Ganzes steht dieses Argument auf der Seite für SaaS-Plattformen. Keines von beiden veröffentlicht eine Zahl zu dieser Anbindung, und hier wird keine erfunden.
Was ein Agent erreicht, je Objekt gezählt
Die Zeilen sind die Objekte, die die dokumentierten Rezepte nennen, keine Auswahl. Die Reichweite gilt je Objekt und nicht je System, also entscheidet die schmalste Zeile, auf die Ihr Workflow angewiesen ist, über Ihre Roadmap.
| Was Sie brauchen | Heute | Auf Anfrage | System kann es nicht |
|---|---|---|---|
| Welche Konten dieser Kunde hat | 19 | 8 | 2 |
| Welche Steuersätze diese Installation nutzt | 12 | 14 | 3 |
| Kostenstellen und andere Dimensionen | 3 | 17 | 9 |
| In welche Journale eine Buchung darf | 5 | 15 | 9 |
| Rechnungen, zum Nachdenken | 13 | 14 | 2 |
| Eingangsrechnungen, zum Nachdenken | 8 | 17 | 4 |
| Eine Buchung schreiben | 10 | 11 | 8 |
| Eine Ausgabe buchen | 7 | 19 | 3 |
| Einen Vorschlag zur Prüfung übergeben | 10 | 17 | 2 |
Die Form dieser Tabelle ist das Argument. Die Lesezugriffe, die ein Agent braucht, um geerdet zu sein, sind nicht die breitesten Zeilen, sie gehören zu den schmalsten, und das ist das Gegenteil dessen, was eine Roadmap annimmt, wenn sie die Erdung als Einrichtung behandelt und den Schreibvorgang als den schweren Teil. Zu wissen, welches der Systeme Ihrer Kunden welche dieser Zeilen beantwortet, ist eine Frage der ersten Woche, und sie lässt sich vor dem Bauen beantworten, und das ist der einzig nützliche Zeitpunkt, sie zu stellen. Wo die Installation eines einzelnen Kunden ein Feld trägt, das das Modell nicht hat, ist für dieses eine Feld am Modell vorbeizugreifen ein dokumentierter Weg und keine Abzweigung Ihrer Integration.
Dieselbe Disziplin gilt für das, was Ihr Agent einem Nutzer zurückmeldet. Ein Schreibvorgang kann gelingen und trotzdem nicht alles tun, worum Sie gebeten haben, wenn ein Zielsystem ein Feld still übergeht, das es nicht führt, und die Antwort sagt das über eine Warnung neben dem Ergebnis. Das dorthin zu bringen, wo ein Mensch es sieht, ist der Unterschied zwischen einem Agenten, dem vertraut wird, und einem, der bloß zuversichtlich ist.
Wir machen die Daten lesbar, das Urteil bleibt Ihr Produkt
In diesem Use Case lässt sich die Grenze ungewöhnlich leicht benennen, denn was auf Ihrer Seite liegt, ist der ganze Grund, aus dem Ihre Kunden sich für Sie entschieden haben.
- Anmeldung und Token je Kunde
- Ein Wortschatz für jedes Objekt
- Die Schreibform jedes Systems
- Ihre jährlichen Bruchstellen
- Was das Modell schließt
- Auf welches Konto eine Zeile gehört
- Wann ein Mensch freigeben muss
- Der Nachweis dessen, was Ihr Agent tat
Die letzte Zeile rechts überrascht die Leute, und sie folgt aus der Architektur und nicht aus einer Lücke darin. Weil auf dem Weg nichts gespeichert wird, liegt hier keine Kopie der Bücher Ihrer Kunden und ebenso wenig ein Protokoll dessen, was Ihr Agent vorgeschlagen hat. Was Maesn hält, ist, dass ein Aufruf stattfand, zu welchem System, unter der Anbindung welches Kunden und wann. Die Begründung, der Prompt, die Version des Modells und die Person, die zugestimmt hat, bleiben bei Ihnen, und bei einem Agenten, der auf Finanzdaten handelt, sind sie die Hälfte, nach der ein Prüfer tatsächlich fragt. Die andere Hälfte, wie die Übertragung selbst geschützt und zertifiziert ist, ist dieselbe Haltung, auf der die übrige Plattform läuft, und nichts, was diese Anbindung schwächt.
Die Zeile darüber ist dasselbe Prinzip eine Ebene tiefer. Die Dokumentation legt die Kategorisierungslogik in Ihre Anwendung, und dort muss sie sitzen: nichts Gemeinsames könnte wissen, dass einer Ihrer Kunden einen Tankbeleg gegen ein anderes Konto bucht als der nächste. Das einmal für alle zu entscheiden hieße, an ihrer Stelle zu wählen, wie ihre Bücher geführt werden, und das ist eine Entscheidung, die ihnen und ihrem Steuerberater gehört. Fehler teilen sich entlang derselben Linie, und von welcher Seite eine Ablehnung kam, ist das Erste, worauf die Behandlung eines Agenten verzweigen sollte.
Im Alltag zeigt sich das in der Entwicklungs-Roadmap, und deshalb holen meist Produkt- und Entwicklungsteams diese Anbindung ins Haus, und die Begründung ist jedes Mal dieselbe: die Integrationen waren nie das Produkt. Soll Ihr Agent über einen Assistenten arbeiten, den ein Kunde ohnehin nutzt, und nicht nur über Ihre eigene Oberfläche, dann ist die Protokollseite davon der MCP Server, der auf derselben API läuft.
Häufige Fragen
Worin unterscheidet sich das von Ihrem MCP Server?
Was muss ein Agent lesen, bevor er überhaupt buchen kann?
Können wir die Daten so abfragen, wie unser Agent danach fragt?
Wie bekommt ein Agent Zugriff auf das Buchhaltungssystem unseres Kunden?
Speichern Sie die Finanzdaten unserer Kunden oder trainieren Sie etwas damit?
Können wir hinterher belegen, was unser Agent getan hat?
Was passiert, wenn das Modell etwas vorschlägt, das das System ablehnt?
Welche Agenten-Abläufe deckt das tatsächlich ab?
Wird ein Schreibvorgang bestätigt, oder ist er abgeschickt und vergessen?
Wie viele Systeme erreicht ein Bau?
Einmal bauen, auf der Unified API.
Sehen Sie, wie Datenzugriff für KI-Agenten für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.