🤖 AI

LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents

LedgerAgent ist eine Methode zur Inferenzzeit, die richtlinienkonforme Tool-Calling-Agenten im Kundenservice-Bereich verbessert, indem sie Aufgabenzustände in einem separaten Ledger verwaltet, um eine konsistente Entscheidungsfindung zu gewährleisten und Richtlinienverstöße vor der Tool-Ausführung proaktiv zu blockieren.

Ursprüngliche Autoren: Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

Veröffentlicht 2026-06-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Kundenservice-Mitarbeiter für eine Fluggesellschaft oder ein Einzelhandelsgeschäft. Ihre Aufgabe ist es, Kunden dabei zu helfen, Flüge zu stornieren, Artikel zurückzugeben oder Pläne zu ändern. Um dies zu tun, verfügen Sie über einen „Werkzeugkasten“ aus digitalen Werkzeugen, mit denen Sie Datensätze prüfen, Konten aktualisieren oder Rückerstattungen bearbeiten können.

Das Problem ist laut dieser Arbeit, dass Standard-KI-Agenten wie Amnesiker mit einem sehr langen Gedächtnis sind. Sie können die gesamte Konversationshistorie (das „Transkript“) lesen, aber sie haben kein spezielles Notizbuch, um die wichtigen Fakten, die sie gerade gefunden haben, aufzuschreiben.

Hier ist die Aufschlüsselung der Lösung der Autoren, LedgerAgent, unter Verwendung einfacher Analogien:

Das Problem: Der „im Rauschen verloren gehende“ Agent

In einem Standard-Setup wird jedes Mal, wenn die KI eine Flugreservierung oder einen Bestellstatus prüft, diese Information in ein riesiges, scrollendes Chat-Protokoll geworsten.

Die Analogie: Stellen Sie sich vor, Sie müssten eine bestimmte Telefonnummer in einem Stapel von 500 Seiten handgeschriebener Notizen finden. Sie müssen den ganzen Stapel jedes Mal neu lesen, wenn Sie entscheiden müssen, was als Nächstes zu tun ist.
Das Versagen: Da die KI das Chat-Protokoll „neu lesen“ muss, um sich an Fakten zu erinnern, kommt sie oft durcheinander. Sie könnte:
1. Ein entscheidendes Detail vergessen (wie das Flugdatum).
2. Nach veralteten Informationen handeln (denken, ein Flug sei noch buchbar, obwohl er es nicht ist).
3. Einen „technisch korrekten“ Schritt machen, der gegen die Regeln verstößt (wie den Versuch, eine Zahlungsmethode zu erstatten, die nicht existiert), weil sie die aktuellen Fakten nicht gegen die Richtlinien geprüft hat.

Die Lösung: Das „Ledger“ und der „Bouncer“

Die Autoren haben LedgerAgent entwickelt, das zwei einfache, aber leistungsstarke Funktionen in den Workflow der KI einfügt.

1. Das Ledger (Das organisierte Notizbuch)

Anstatt die Fakten einfach im Chat-Protokoll schwimmen zu lassen, verfügt die KI nun über ein strukturiertes Ledger (ein Hauptbuch).

Wie es funktioniert: Jedes Mal, wenn die KI erfolgreich ein Werkzeug verwendet, um Daten zu lesen (wie „Flugdetails abrufen“), lässt sie diese Daten nicht einfach im Chat stehen. Sie kopiert die wichtigsten Fakten sofort in ein sauberes, organisiertes „Notizbuch“ (ein typisiertes Dictionary).
Die Metapher: Denken Sie an das Chat-Protokoll als eine unordentliche Küchenarbeitsplatte, auf der Zutaten überall verstreut liegen. Das Ledger ist ein beschriftetes Gewürzregal. Wenn die KI den Preis eines Fluges wissen muss, wühlt sie nicht in der unordentlichen Arbeitsfläche; sie schaut einfach in das Glas „Flugpreis“ im Regal.
Der Vorteil: Die KI weiß immer genau, was sie weiß, ohne raten oder in altem Text suchen zu müssen.

2. Das Policy Gate (Der Türsteher)

Bevor die KI eine Änderung in der realen Welt vornehmen darf (wie einen Flug zu stornieren oder eine Rückerstattung zu leisten), muss sie ein Policy Gate (eine Richtlinien-Schranke) passieren.

Wie es funktioniert: Dieses Gate ist ein strenger Regelprüfer. Es betrachtet die vorgeschlagene Aktion der KI und gleicht sie mit den Fakten im Ledger und den Unternehmensregeln ab.
Die Metapher: Stellen Sie sich einen Türsteher in einem Club vor. Die KI (der Gast) sagt: „Ich möchte diesen Flug stornieren.“ Der Türsteher (das Gate) prüft das Ledger (die Gästeliste) und das Regelwerk (die Richtlinie).
- Szenario: Die Regel besagt: „Sie können nur innerhalb von 24 Stunden stornieren.“ Das Ledger zeigt, dass der Flug vor 48 Stunden gebucht wurde.
- Ergebnis: Der Türsteher stoppt die KI. „Kein Einlass. Sie verstoßen gegen die 24-Stunden-Regel.“ Die KI sagt dann zum Kunden: „Es tut mir leid, das kann ich nicht tun“, anstatt blindlings zu versuchen zu stornieren und dabei zu scheitern.

Warum das wichtig ist

Die Autoren haben dieses System in vier verschiedenen Kundenservice-Welten getestet: Airlines, Einzelhandel, Telekommunikation und Telemedizin. Sie verwendeten verschiedene KI-Modelle (sowohl Open-Source als auch große kommerzielle Modelle).

Die Ergebnisse: LedgerAgent war viel besser darin, Aufgaben korrekt auszuführen, insbesondere wenn die Aufgabe eine Änderung in der realen Welt erforderte (wie eine Rückerstattung oder eine Stornierung).
Konsistenz: Der größte Gewinn war die Konsistenz. Wenn Sie die Standard-KI bitten würden, dieselbe Aufgabe 4 Mal zu erledigen, würde sie vielleicht einmal Erfolg haben und dreimal scheitern, weil sie durch ihre eigene Chat-Historie verwirrt wurde. LedgerAgent war über alle 4 Versuche hinweg wesentlich konsistenter erfolgreich.
Keine Zusatzkosten: Im Gegensatz zu anderen Methoden, die versuchen, die KI „schlauer“ zu machen, indem sie sie mit mehr Daten trainieren oder mehrere KI-Gehirne verwenden, verändert LedgerAgent das Gehirn der KI überhaupt nicht. Es gibt ihr nur eine bessere Möglichkeit, ihre Notizen zu organisieren und einen Türsteher, der ihre Arbeit überprüft.

Zusammenfassung

LedgerAgent ist wie ein chaotischer, vergesslicher Assistent, dem man einen strukturierten Aktenschrank (das Ledger) und einen strengen Vorgesetzten (das Policy Gate) gibt.

Der Aktenschrank stellt sicher, dass der Assistent immer die aktuellen Fakten kennt, ohne in alten E-Mails wühlen zu müssen.
Der Vorgesetzte stellt sicher, dass der Assistent niemals versucht, gegen die Regeln zu verstoßen, bevor er die Aktion tatsächlich ausführt.

Das Paper behauptet, dass diese einfache Änderung KI-Agenten viel zuverlässiger, genauer und höflicher macht, wenn sie komplexe Kundenservice-Aufgaben bewältigen.

Technisches Resümee: LedgerAgent: Strukturierter Zustand für richtlinienkonforme Tool-Calling-Agenten

Problemstellung

In Kundenservice-Domänen müssen Sprachagenten Aufgabenzustände über mehrere Interaktionsrunden hinweg aufrechterhalten, während sie mit Nutzern interagieren, Datensätze abrufen und Tools ausführen. Diese Agenten müssen strikte Domänenrichtlinien einhalten (z. B. Erstattungsberechtigung, Stornierungsfenster), die vom aktuellen Zustand der Interaktion abhängen.

Standardmäßige Tool-Calling-Agenten verlassen sich auf ein Prompt-basiertes Design, bei dem Beobachtungen, Tool-Rückgaben und Richtlinienanweisungen in einem wachsenden Konversationsprotokoll miteinander verwoben sind. Dieses Design führt zu zwei primären Fehlermodi:

Implizite Zustandsverankerung: Agenten müssen relevante Fakten bei jeder Entscheidung über eine Aktion erneut aus dem rohen Transkript rekonstruieren. Dies führt zu Entscheidungen auf Basis veralteter, fehlender oder fehlerhaft rekonstruierter Informationen, selbst wenn die korrekten Datensätze zuvor abgerufen wurden.
Verletzung von Richtliniengrenzen: Agenten können syntaktisch valide Tool-Aufrufe generieren, die gegen Domänenrichtlinien verstoßen, weil die Richtlinienprüfung nicht vom aktuellen Zustand entkoppelt ist. Beispielsweise könnte ein Agent versuchen, eine Reservierung außerhalb des zulässigen Zeitfensters zu stornieren, weil er versäumt hat, das aktuelle Datum mit dem im Verlauf gespeicherten Reservierungsdatum abzugleichen.

Bestehende Lösungen konzentrieren sich oft auf die Verbesserung des Modells selbst (durch Fine-Tuning oder Reinforcement Learning) oder auf die Hinzufügung von Scaffolding zur Inferenzzeit (Planung/Reflektion). Diese Ansätze bewahren jedoch weitgehend die implizite Natur der Zustandsrepräsentation innerhalb des Prompts, wodurch der Agent den Zustand aus einem unstrukturierten Transkript wiederherstellen muss.

Methodik: LedgerAgent

Die Autoren führen LedgerAgent ein, eine Methode zur Inferenzzeit, die das Zustandsmanagement vom rohen Prompt-Verlauf entkoppelt. Sie führt zwei deterministische Komponenten ein, die ohne Modifikation der Modellgewichte oder zusätzliche LLM-Aufrufe zur Zustandsrekonstruktion operieren:

1. Schema-verankerter Ledger (Kontobuch)

Der Agent führt einen separaten, typisierten Dictionary (den Ledger), der beobachtete Aufgabenzustände speichert.

Mechanismus: Wenn ein Read-Tool erfolgreich zurückgibt, wird der Rückgabewert basierend auf einer vordefinierten, domänenspezifischen Tool-Pfad-Map (z. B. orders.1234, reservations.UX789) analysiert und in den Ledger projiziert.
Eigenschaften: Der Ledger ist eine kompakte, typisierte Repräsentation beobachteter Fakten, Identifikatoren und Bedingungen. Er ist keine Zusammenfassung oder Langzeitgedächtnis, sondern eine strukturierte Sicht auf den Zustand des externen Systems, wie er vom Agenten beobachtet wurde.
Update-Regel: Der Ledger aktualisiert sich nur durch erfolgreiche Rückgaben von Read-Tools. Write-Tool-Rückgaben aktualisieren den Ledger nicht; der Agent muss einen nachfolgenden Read-Aufruf tätigen, um den neuen Zustand zu beobachten, wodurch sichergestellt wird, dass der Ledger im externen System verankert bleibt.
Integration: Vor jeder Modellgenerierung wird der vollständige Ledger deterministisch gerendert und in den Prompt injiziert. Dies ermöglicht es dem Modell, den aktuellen Zustand über stabile Pfade aufzusuchen, anstatt im Transkriptverlauf zu suchen.

2. Policy Gate (Richtlinien-Tor)

Ein Policy Gate operiert unmittelbar vor der Ausführung eines umweltverändernden Tool-Aufrufs (z. B. Erstattungen, Stornierungen, Aktualisierungen).

Funktion: Das Gate evaluiert den vorgeschlagenen Tool-Aufruf gegen eine Menge von ausführbaren Prädikaten ( $\Pi$ ), die über die Felder des aktuellen Ledgers definiert sind.
Ausgänge:
- ALLOW (Zulassen): Der Aufruf ist konsistent mit dem Ledger und der Richtlinie; er wird unverändert ausgeführt.
- REVISE (Überarbeiten): Der Aufruf verletzt eine Richtlinie (z. B. fehlende Belege). Der Aufruf wird entfernt und das Modell erhält eine Rückmeldung, die das verletzte Prädikat identifiziert.
- BLOCK (Blockieren): Der Aufruf ist explizit untersagt (z. B. Versuch einer richtlinienwidrigen Aktion). Die Aktion wird abgelehnt und der Agent wird daran gehindert, die Umgebung zu verändern.
Implementierung: Richtlinien werden als Code-Prädikate über Ledger-Felder kodiert (z. B. Prüfung, ob ein Flugdatum innerhalb von 24 Stunden der aktuellen Zeit liegt), anstatt sich auf natürliches Sprachverständnis innerhalb des Prompts zu verlassen.

Agenten-Schleife

Die Methode umschließt die Standard-Agenten-Schleife. Sie absorbiert Tool-Rückgaben in den Ledger, rendert den Ledger in den Prompt, generiert eine Antwort und filtert umweltverändernde Aufrufe durch das Policy Gate. Entscheidend ist, dass dies keine zusätzlichen LLM-Aufrufe im Inferenzprozess verursacht; der Overhead beschränkt sich auf deterministische String-Formatierung und Prädikatsevaluierung.

Zentrale Beiträge

Identifizierung der Zustandsverankerung als Fehlerquelle: Das Paper identifiziert, dass Agenten oft nicht scheitern, weil sie Datensätze nicht abrufen können, sondern weil sie auf einem veralteten oder falsch rekonstruierten Zustand agieren, wenn dieser Zustand implizit im Prompt verbleibt.
LedgerAgent-Framework: Eine neuartige Methode zur Inferenzzeit, die die Zustandsrepräsentation (via typisiertem Ledger) von der Aktionsausführung (via Policy Gate) trennt und sicherstellt, dass zustandsabhängige Richtlinien vor Umgebungsveränderungen gegen beobachtete Evidenz geprüft werden.
Empirische Validierung: Nachweis, dass LedgerAgent die konsistenzorientierten Metriken ( $pass^k$ ) über diverse Kundenservice-Domänen und Backbone-Modelle hinweg verbessert, ohne die Modellgewichte zu verändern.

Experimentelle Ergebnisse

Die Autoren evaluierten LedgerAgent über vier Domänen (Airline, Retail, Telecom, Telehealth) unter Verwendung einer Mischung aus Open- und Closed-Weight-Modellen (einschließlich GPT-4.1, GPT-5.2, Kimi K2.5, GLM-5, MiniMax M2.5 und Qwen3).

Leistungssteigerungen: LedgerAgent verbesserte die durchschnittlichen $pass^1$ $p a s s^{1}$ - und $pass^4$ $p a s s^{4}$ -Werte konsistent gegenüber Standard-Function-Calling-Baselines.
- Bei Nicht-GPT-Backbones (z. B. Kimi-K2.5) verbesserte sich das durchschnittliche $pass^1$ um 3,4 Punkte und das $pass^4$ um 5,6 Punkte.
- Bei GPT-Backbones waren die Verbesserungen noch ausgeprägter, mit durchschnittlichen $pass^1$ -Gewinnen von 12,2 (GPT-4.1) und 15,5 (GPT-5.2) Punkten.
Konsistenz: Die größten Gewinne wurden bei $pass^4$ (Konsistenz über vier unabhängige Versuche) beobachtet, was darauf hindeutet, dass LedgerAgent die Varianz im Agentenverhalten signifikant reduziert.
Umweltverändernde Aufgaben: Die Methode zeigte besondere Stärke bei Aufgaben, die Schreibaktionen erfordern (z. B. Stornierungen, Erstattungen), bei denen die Verhinderung von Richtlinienverstößen kritisch ist. In der Telecom-Domäne (Dual-Control-Setting) steigerte LedgerAgent die Aktionszuverlässigkeit erheblich.
Effizienz: Im Gegensatz zu Context-Engineering-Methoden wie IRMA (die Helfer-Agenten nutzen und >50 % Token-Overhead verursachen), erreichte LedgerAgent eine höhere Performance mit 0,0 % Token-Overhead relativ zur Baseline, da keine zusätzlichen LLM-Aufrufe hinzugefügt werden.

Fehleranalyse

Die Analyse fehlgeschlagener Trajektorien ergab, dass die verbleibenden Fehler in LedgerAgent primär sind:

Versäumte erforderliche Aktionen (70,3 %): Der Agent schließt initiale Abfragen ab, versäumt es aber, die nachfolgenden notwendigen Schritte auszuführen (z. B. vorzeitig an menschlichen Support übergeben, anstatt einen gültigen Teil-Erfüllungsprozess zu versuchen).
Falsche Aktionsargumente (20,4 %): Fehler beim Extrahieren oder Formatieren von Argumenten, insbesondere in Domänen mit komplexen Schemata wie Telehealth.
Domänenspezifität: Fehler variieren je nach Domäne (z. B. Telecom-Fehler sind fast ausschließlich versäumte Aktionen; Telehealth weist höhere Argumentfehlerraten auf), was darauf hindeutet, dass, obwohl der Ledger die Zustandsverankerung löst, domänenspezifische Planung und Schema-Bewusstsein weiterhin Herausforderungen bleiben.

Bedeutung und Ansprüche

Das Paper behauptet, dass LedgerAgent eine fundamentale architektonische Lücke bei Tool-Calling-Agenten adressiert: die Abhängigkeit von einem impliziten Zustand innerhalb eines wachsenden Prompts. Durch die Explizitmachung des beobachteten Zustands und die Prüfung von Aktionen gegen einen strukturierten Ledger vor der Ausführung bewirkt die Methode:

Eine Verschiebung der Fehlergrenze von der Post-hoc-Korrektur (Beheben von Fehlern, nachdem sie aufgetreten sind) zur Prävention (Blockieren von Richtlinienverstößen, bevor sie auftreten).
Einen System-Mechanismus für die Richtlinienkonformität, der die Reasoning-Fähigkeiten des Modells ergänzt, ohne ein Retraining oder komplexes Multi-Agent-Orchestrierung zu erfordern.
Den Nachweis, dass die Zustandsrepräsentation ebenso kritisch für zuverlässiges Tool-Use in dynamischen, richtlinienbeschränkten Umgebungen ist wie die Modellkapazität selbst.

Die Autoren kommen zu dem Schluss, dass LedgerAgent zwar nicht die Notwendigkeit von Planung oder robuster Argumentkonstruktion ersetzt, aber effektiv eine wesentliche Quelle der Unzuverlässigkeit eliminiert: das Agieren auf Basis eines veralteten oder nicht fundierten Zustands. Der Ansatz ist am effektivsten in strukturierten Tool-Use-Domänen, in denen der Zustand auf ein Schema abgebildet und Richtlinien als ausführbare Prädikate kodiert werden können.