Zurück zu Technology

Die halbe Antwort liegt immer in einem anderen System

Norman ist jetzt MCP-Client, der Agent kann also aus den Tools lesen, die dein Business ohnehin nutzt: Zahlungsdienstleister, Postfach, Dokumentenspeicher, dein eigener interner Server. Was das freischaltet, mit den Fragen, die Leute wirklich stellen, und der einen Regel, die alles prägt: außen lesen, innen schreiben.

Kategorie
Allgemein
Aktualisiert
Autor:in
Stan Kharlap

Unser Agent ist gut in einer engen Sache. Rund hundertzwanzig Tools, grob hundertvierzigtausend getracte Runs pro Monat, über einem Bestand von fast einer Million Transaktionen und weit über hunderttausend Dokumenten. Rechnung anlegen, Transaktion kategorisieren, USt-Meldung ziehen, Steuernummer prüfen.

Und er lief immer gegen dieselbe Wand. Fast jede wirklich schwierige Buchhaltungsfrage braucht etwas, das Norman nicht hat. Die Bankzeile nennt eine Zahl. Der Grund für diese Zahl liegt in einem Zahlungsdienstleister, einem Postfach, einer geteilten Ablage oder einem System, das sich jemand selbst gebaut hat.

Also ist der Agent jetzt MCP-Client. Du verbindest die Tools, die dein Business ohnehin nutzt, und er liest daraus, in derselben Unterhaltung, die deine Umsatzsteuer einreicht. Läuft in Produktion, als Beta markiert, und schlafend, bis du etwas verbindest.

Und das bringt konkret Folgendes.

Eine Tabelle mit fünf Beispielanfragen, dem, was der Agent aus einer verbundenen Quelle liest, und dem, was in Norman landet. Die Frage, woraus eine Sammelauszahlung besteht, liest die Auszahlungsdetails aus einem Zahlungsdienstleister und erzeugt Bruttoumsatz, Gebühren und Erstattungen als getrennt gebuchte Zeilen. Die Bitte, die Rechnung zu einer Kartenzahlung zu finden, durchsucht ein Postfach oder einen Dokumentenspeicher und erzeugt Dokumenten-Kandidaten mit Import-Aktion, angehängt an die Transaktion. Die Frage, warum ein Betrag abgebucht wurde, liest den Streitfall oder die Erstattung und erzeugt eine Transaktion, gebucht als das, was sie wirklich ist. Die Frage, welche offenen Rechnungen zu abgeschlossenen Projekten gehören, fragt deinen eigenen internen Server und erzeugt eine Antwort im Chat und, mit Zustimmung, einen zurückgeschriebenen Status. Die Frage, was vor der Quartalsmeldung noch fehlt, liest gar nichts Externes und bleibt vollständig in Normans eigenen Tools.
Das Muster in jeder Zeile: eine externe Quelle beantwortet die Frage, und Normans eigene Tools erledigen die Buchung.

Die Regel, die alles prägt: außen lesen, innen schreiben

Eine Design-Entscheidung trägt jeden Use Case hier unten, deshalb steht sie vor den Beispielen.

Quellen aus unserem Katalog sind read-only. Sie beantworten Fragen. Sie verändern nichts, weder in Norman noch auf ihrer eigenen Seite. Jeder Schreibvorgang, der aus der Unterhaltung folgt, wird von Normans eigenen Tools auf Normans eigenen Daten ausgeführt, mit derselben Validierung und demselben Audit-Trail, als hättest du die Buttons selbst geklickt.

Die Ausnahme ist ein Server, auf den du uns selbst zeigst, denn der gehört dir. Dort können Schreib-Tools eingeschaltet werden, aber nur von der Company-Ownerin, ausdrücklich, und wir halten fest, wer es war.

Das ist nicht nur eine Sicherheitsposition. Es macht die Sache überhaupt erst benutzbar: du kannst einen Zahlungsdienstleister anbinden, ohne einem Assistenten die Fähigkeit zu geben, dort Geld zu bewegen.

Use Case 1: die Auszahlung, die eigentlich vierzig Dinge ist

Ein Zahlungsdienstleister zahlt einmal aus. Deine Bank zeigt eine Gutschrift.

Diese Zahl ist ein Netto: Bruttoumsatz, minus Plattformgebühren, minus Erstattungen, minus ein Chargeback, plus eine Auszahlung aus der Vorperiode, die spät ankam. Als Buchungszeile ist das nahezu unbrauchbar, und genau beim Rekonstruieren von Hand geben viele still auf und buchen den ganzen Betrag als Umsatz.

Mit angebundenem Dienstleister ist die Frage einfach: "woraus besteht die Auszahlung vom 14.". Der Agent liest Zahlungen, Rechnungen und Salden aus der Quelle, kommt mit der Aufschlüsselung zurück und benutzt dann seine eigenen Tools zum Buchen: die Bruttoseite, die Gebührenseite, die Erstattungsseite, jede als eigene Zeile an der richtigen Transaktion.

Gelesen wird draußen. Geschrieben wird von Norman.

Use Case 2: der Beleg, den es gibt, nur eben nicht hier

Wir halten weit über hunderttausend Dokumente, und die wichtigsten sind die, die nie jemand hochgeladen hat. Deutsche Buchhaltung läuft auf Belegen. Eine Kartenzahlung ohne Beleg ist am Quartalsende eine offene Frage, und dieses Dokument existiert fast immer, es liegt nur in einem Postfach oder einer geteilten Ablage, auf die Norman nie Zugriff hatte.

Mit angebundenem Postfach oder Dokumentenspeicher wird aus "finde die Rechnung zu dieser Zahlung" eine Suche über Inhalte, die dir ohnehin gehören. Der Agent matcht auf das, was ein Dokument wirklich identifiziert: Betrag, ein Datumsfenster um die Transaktion, den Anbieter, eine Rechnungsnummer, wenn sie sichtbar ist.

Zurück kommt kein Dateihaufen. Wo eine Quelle Dokumente liefert, kommen die Ergebnisse im Chat als Kandidaten an, jeder als Karte mit Import-Aktion. Du wählst den richtigen, Norman holt die Bytes selbst, und das Dokument landet an der Transaktion, kategorisiert, genau dort, wo du es am Quartalsende brauchst.

Der Agent lädt nie von sich aus eine Datei herunter. Er findet Kandidaten. Ein Mensch wählt aus.

Use Case 3: die Abbuchung, die niemand erklären kann

Ein Chargeback sieht aus wie Geld, das das Konto verlässt. Eine Erstattung auch. Eine Gebührenkorrektur, eine Teilrückabwicklung ebenso. Im Bankfeed sehen sie identisch aus, und die richtige Buchung ist bei jedem eine andere.

Mit angebundenem Dienstleister kann der Agent den Streitfall, die Erstattung und die ursprüngliche Bestellung hinter dieser Abbuchung lesen und die Transaktion dann als das buchen, was sie wirklich ist. Erstattungen sind dabei ein eigener kleiner Albtraum, denn eine Erstattung ist kein negativer Umsatz, sondern eine Umkehrung, die auf der Seite landen muss, die sie umkehrt. Die Quelle der Wahrheit eine Frage statt einen CSV-Export entfernt zu haben, ändert, wie oft das richtig gemacht wird.

Use Case 4: der Server, den du selbst geschrieben hast

Das ist der, gegen den ich bauen würde, wenn ich als Entwicklerin eine kleine Firma hätte.

Jeder öffentliche HTTPS-MCP-Server lässt sich als eigene Quelle hinzufügen: dein Projektsystem, dein internes Admin, deine eigene Datenbank hinter einem dünnen Server, irgendein Planungstool, das deine Branche nutzt und sonst niemand kennt. Diese Tools stehen dann neben den Buchhaltungs-Tools, in derselben Unterhaltung:

# was das Modell in einer Unterhaltung sieht
create_invoice                (Norman)
categorize_transaction        (Norman)
list_tax_reports              (Norman)
studio__list_projects         (dein Server, mit Namespace)
studio__get_project_hours     (dein Server, mit Namespace)

Das Präfix ist keine Dekoration. Deine Tools können nie mit unseren verwechselt werden, und unsere liegen deinem Server nie offen.

Damit klingen die Fragen nicht mehr nach Buchhaltung, sondern nach dem Geschäft:

  • "Welche offenen Rechnungen gehören zu Projekten, die schon ausgeliefert sind?"
  • "Ordne die Ausgaben dieses Monats den Kunden zu, für die sie angefallen sind, und sag mir, welche ich nie weiterberechnet habe."
  • "Diese Lieferantenrechnung, existiert die Lieferung, auf die sie sich bezieht, in unserem System?"

Und weil der Server dir gehört, lassen sich auch seine Schreib-Tools einschalten. Nachdem bestätigt ist, dass eine Rechnung bezahlt wurde, kann der Agent den Status dorthin zurückschreiben, wo dein Team ihn sieht. Das erfordert eine bewusste Entscheidung der Company-Ownerin statt einer Voreinstellung, und das ist ungefähr die richtige Menge Reibung für etwas, das den Zustand in einem System ändert, das wir nicht betreiben.

Use Case 5: gar nichts Externes

Gehört gesagt, weil es weiterhin der Normalfall ist. "Was fehlt noch vor der Quartalsmeldung" braucht überhaupt keine verbundene Quelle. Das sind Normans eigene Tools auf Normans eigenen Daten, und da verbringt der Agent nach wie vor die meiste Zeit.

Quellen sind kein separates Produkt, das seitlich angeschraubt wurde. Sie sind der fehlende Kontext für die Arbeit, die der Agent ohnehin macht. Und eine Quelle mit schlechtem Morgen wird als nicht verfügbar markiert und aus dem Run gelassen: du bekommst einen funktionierenden Assistenten, der genau diese eine Quelle gerade nicht sieht, plus eine Karte, die das sagt, statt eines Fehlers an der Stelle, an der eine Antwort stehen sollte.

Was wir bewusst nicht gebaut haben

Kurz, weil es prägt, was du erwarten kannst.

Katalogquellen können nicht schreiben, überhaupt nicht. Entfernte Tools bekommen für das Modell einen Namespace, damit nichts eines unserer Tools imitieren kann. Freigaben sind an die Tool-Liste gepinnt, die wir beim Verbinden inspiziert haben, ein Server kann ein freigegebenes Tool also nicht still umdefinieren. Und was aus einer Quelle zurückkommt, sind Daten, nie eine Anweisung: eine E-Mail, die den Assistenten höflich bittet, Geld zu überweisen, ist Text, und Text hat hier keine Autorität.

Das ist die Kurzfassung. Die Langfassung ist ein eigener Artikel.

Die Grenze war nie die Intelligenz

Woran ich immer wieder hängenbleibe: Bei einem Agenten, der echte operative Arbeit macht, ist die bindende Beschränkung fast nie, wie schlau das Modell ist. Sondern, was das Modell sehen kann.

Unserer konnte immer eine Transaktion kategorisieren. Er konnte dir nicht sagen, warum eine Auszahlung ein paar hundert Euro unter den Umsätzen lag, die sie abdeckte, weil diese Antwort in einem System lag, für das er keine Augen hatte. Am Modell hat sich nichts geändert. Am Zugang schon.

Wenn das richtig funktioniert, wirst du es nicht bemerken. Du fragst, wo ein Beleg ist, und er ist da.

Norman übernimmt die operative Arbeit im Hintergrund

Von Rechnungen bis Buchhaltung: Norman organisiert wiederkehrende Finanzarbeit, damit du Fristen sauber einhältst und weniger manuell nachhalten musst.