Multi-Agent-Orchestrierung im Finanzwesen – und wann man sie besser lässt

Ein Finanz-Workflow profitiert von mehreren Agenten, wenn zwei Teilaufgaben unterschiedliche Tools, unterschiedliche Berechtigungen oder Kontext benötigen, der nicht in ein Fenster passt – und wenn das, was zwischen ihnen übergeben wird, aufgeschrieben und geprüft werden kann. Überall sonst kostet ein einzelner Agent mit einem guten Tool-Set weniger, bleibt leichter zu auditieren und verliert selten eine Zahl auf dem Weg.

Die meisten Multi-Agent-Demos lösen ein Problem, das die Demo selbst erfunden hat. Ein „Researcher” übergibt an einen „Writer” übergibt an einen „Critic”, und das Ganze sieht schön organisiert aus. In einem echten Finanzsystem passieren die interessanten Fehler selten innerhalb eines Agenten. Sie passieren an der Naht zwischen zweien, wo eine Zahl stillschweigend gerundet oder ein „fertig” für Arbeit gemeldet wird, die nie abgeschlossen wurde. Genau diese Naht entwerfen Sie tatsächlich, wenn Sie sich für Orchestrierung entscheiden.

Was eine Übergabe transportieren muss

Eine Agenten-Übergabe ist ein Datenkontrakt, und das Finanzwesen ist bei Datenkontrakten unerbittlich. Wenn ein Agent Arbeit an einen anderen übergibt, braucht die empfangende Seite genug, um für sich allein korrekt zu sein. Ein Absatz Prosa, der den Zustand zusammenfasst, leistet das nicht. Der empfangende Agent braucht den Zustand selbst.

Bei einer Abstimmungsaufgabe heißt das: Der empfangende Agent erhält die Ledger-Zeilen, das Quellsystem, aus dem jede stammt, den As-of-Zeitstempel und die bereits angewandten Toleranzen. Für eine Exposure-Berechnung erhält er die Positionen mit ihren Point-in-Time-Marks – nicht Marks, die der vorgelagerte Agent zufällig in einer anderen Sekunde abgerufen hat. Ist die Übergabe Prosa, haben Sie einen verlustbehafteten Kompressionsschritt zwischen zwei Systeme geschoben, die beide die exakten Zahlen brauchten.

Der erste Test, den wir bei jeder vorgeschlagenen Aufteilung durchführen, ist deshalb langweilig: Kann die Übergabe ein typisiertes Artefakt sein, das Sie speichern und erneut abspielen würden? Wenn ja, ist die Grenze wahrscheinlich real. Wenn das Einzige, was die Grenze überquert, eine Zusammenfassung ist, die der nächste Agent neu interpretiert, haben Sie eine Stelle geschaffen, an der Zahlen still abdriften, ohne irgendeine Fähigkeit hinzuzufügen. Lassen Sie sie zusammenfallen.

Wo eine Aufteilung sich wirklich auszahlt

Es gibt einige Grenzen, an denen separate Agenten ihre Kosten verdienen, und sie teilen tendenziell eine Eigenschaft: Die beiden Seiten haben unterschiedliche Autorität oder unterschiedliche Failure-Modes.

• Unterschiedliche Tool-Berechtigungen. Ein entwerfender Agent, der ein Data Warehouse liest, und ein buchender Agent, der Journalbuchungen schreibt, sollten nicht derselbe Akteur sein. Die Trennung erlaubt es, Credentials eng zu scopen und einen Menschen oder ein Regelwerk-Gate auf den Schreibpfad zu setzen. Das ist Autorisierung, als Architektur ausgedrückt.
• Unterschiedlicher Kontextbedarf. Entity Resolution über eine unsaubere Liste von Gegenparteien ist eine eigene Aufgabe mit eigenen Referenzdaten. Sie zu isolieren hält hunderttausend Token an Alias-Tabellen aus dem Fenster des Agenten heraus, der nur die aufgelösten IDs braucht.
• Unterschiedliche Eval-Sets. Ein Klassifikator, der Transaktionen zur Prüfung markiert, und ein Summarizer, der die Markierung erklärt, haben getrennte Qualitätsmaßstäbe. Den ersten messen Sie gegen ein False-Positive-Budget, den zweiten gegen faktische Genauigkeit. Sie getrennt zu halten erlaubt jedem sein eigenes Eval-Set und sein eigenes Drift-Monitoring, statt einer vermischten Metrik, die beides verdeckt.
• Echte Parallelarbeit. Filings für vierzig Portfolio-Unternehmen zum Quartalsende zu ziehen, ist peinlich parallelisierbar. Das über Worker-Agenten auszufächern ist eine Durchsatzentscheidung, keine Intelligenzentscheidung, und das ist in Ordnung, solange der Fan-in-Schritt abstimmt, was zurückkam.

Beachten Sie, was nicht auf dieser Liste steht: „die Aufgabe ist kompliziert”. Komplexität allein ist ein Argument für bessere Tools und mehr Kontext, nicht für mehr Agenten. Eine einzelne Planner-Executor-Schleife bewältigt einen Großteil der Finanzarbeit, weil der Plan meist kurz ist und Sie ihn lesen können, bevor irgendetwas läuft.

Wo eine einzelne Schleife sicherer ist

Das Planner-Executor-Muster ist die Stelle, an der Teams verführt werden. Ein Planner schreibt einen mehrstufigen Plan, Executoren führen ihn aus, und es fühlt sich an, als hätten Sie etwas Autonomes gebaut. Das Problem ist, dass ein Planner selbstbewusst einen Schritt ausgibt, den kein Tool erfüllen kann, und ein nachgelagerter Executor tut trotzdem sein Bestes, ihn zu erfüllen. Jetzt haben Sie eine plausible Aktion, ausgeführt auf eine Anweisung, die nie in einer realen Fähigkeit verankert war.

Im Finanzumfeld zeigt sich das als fabrizierte Zwischenwerte. Der Planner entscheidet, Schritt drei sei „Bereinigung um Intercompany-Eliminierungen”, kein Tool führt diese Bereinigung tatsächlich durch, und der Executor erzeugt eine Zahl, die wie eine Bereinigung aussieht, aber eine Vermutung ist. Nichts wirft einen Fehler. Der Audit-Trail verzeichnet einen abgeschlossenen Schritt. Sie finden es zum Quartalsende – falls Sie es finden.

Aus diesem Grund halten wir an einem einzelnen Agenten, einer einzelnen Schleife fest, wenn:

• Die Arbeit ein einziges zusammenhängendes Urteil ist, das nicht in Schritte zerhackt werden sollte, die jeder für sich vertretbar aussehen. Eine Kreditbeurteilung schließt über das Gesamtbild; sie aufzuteilen lädt dazu ein, dass jedes Teilstück lokal vernünftig und gemeinsam falsch ist.
• Lineage mehr zählt als Durchsatz. Ein Akteur mit einem Tool-Log lässt sich weit leichter rekonstruieren als ein Baum von Agenten, deren Interaktionen Sie im Nachhinein wieder zusammenflicken müssen.
• Die Kosten von False Positives hoch sind und Latenz nicht die Einschränkung ist. Koordination zwischen Agenten fügt eine eigene Fehlerfläche hinzu, und für eine Compliance-Entscheidung ist diese Fläche keine paar gesparte Sekunden wert.

Der ehrliche Default ist ein Agent mit einem gut entworfenen Tool-Set und einem strengen Schema auf der Ausgabe jedes Tools. Greifen Sie zur Orchestrierung, wenn Sie an eine Wand stoßen, die mehr Tools nicht überwinden können: eine Berechtigungsgrenze, die Sie durchsetzen müssen, ein Kontext, den Sie nicht unterbringen, oder eine Parallelität, die Sie ausnutzen wollen.

Für die Naht bauen

Wenn Sie aufteilen, entwerfen Sie zuerst die Naht. Geben Sie jeder Übergabe eine Version, ein Schema und einen Validator, der fehlerhafte oder außerhalb der Toleranz liegende Artefakte zurückweist, bevor der nächste Agent sie berührt. Machen Sie die Entscheidungen des Orchestrators selbst zu protokollierten Aktionen, sodass „Agent A hat entschieden, an Agent C zu routen” ein Datensatz ist, den Sie erneut abspielen können, und kein emergentes Verhalten, das Sie aus Zeitstempeln rekonstruieren.

Halten Sie die Topologie flach. Tiefe Ketten von Agenten, die Agenten aufrufen, verstärken zwei Probleme auf einmal: Latenz, die Sie messen können, und Fehlerfortpflanzung, die Sie nicht messen können, weil eine kleine Verzerrung ganz oben den ganzen Weg nach unten als Grundwahrheit behandelt wird. Ein flacher Graph mit starken Kontrakten an jeder Kante schlägt eine clevere Hierarchie fast jedes Mal.

Und messen Sie das Ganze end-to-end, nicht pro Agent. Eine Orchestrierung, bei der jede Komponente ihr eigenes Eval besteht und die gemeinsame Ausgabe trotzdem falsch ist, ist der normale Fehler, nicht der exotische. Die Zahl, die zählt, ist, ob das finale Artefakt gegen die Quelle abstimmt, den Replay übersteht und seine Point-in-Time-Korrektheit hält. Tut es das nicht, wird keine noch so große interne Agenten-Höflichkeit den Abschluss retten.