LedgerLou Docs ist für Desktop optimiert.

Bitte öffne diese Seite auf einem Gerät mit breiterem Bildschirm.

LedgerLou Docs

Agenten-Patterns

Die folgenden Patterns haben sich in der Praxis bewährt, wenn Agenten über MCP mit dem Hauptbuch arbeiten. Sie basieren alle auf einem zentralen Grundsatz: erst lesen, dann vorschlagen, dann bestätigen lassen, dann schreiben. Das minimiert Fehlbuchungen und hält jeden Schritt nachvollziehbar.

Bewährte Patterns

Pattern 1 Lesen → Vorschlagen → Bestätigen → Schreiben

Der Standardablauf für jeden buchenden Agenten. Bevor irgendetwas ins Hauptbuch geschrieben wird, lädt der Agent reale Daten (Konten, Perioden, Belege), formuliert einen Vorschlag und holt eine explizite Freigabe ein. Erst dann wird geschrieben. Dieses Pattern macht Entscheidungen transparent und verhindert, dass der Agent „im Dunkeln rät".

  1. 1 Kontext laden: Kontenplan, offene Perioden und – soweit relevant – bestehende Buchungen (read-Tools)
  2. 2 Buchungsvorschlag formulieren – mit echten Kontonummern und Perioden aus dem Mandanten, nicht aus dem Training des Modells
  3. 3 Vorschlag dem Nutzer zeigen und eine explizite Freigabe einholen
  4. 4 Erst nach Bestätigung schreiben (post_booking oder post_booking_with_document)
Pattern 2 Bankabgleich in zwei Stufen

Banktransaktionen sollten nie vollautomatisch und intransparent abgeglichen werden. Das Pattern teilt den Prozess in zwei Phasen: zunächst Vorschläge laden und dem Nutzer zeigen, dann selektiv abgleichen. So bleibt ein Mensch in der Entscheidungsschleife und der Abgleichstatus jederzeit nachvollziehbar.

  1. 1 Offene Transaktionen laden: get_unreconciled_transactions + get_reconciliation_suggestions
  2. 2 Vorschläge mit Confidence-Scores dem Nutzer zeigen – was passt sicher, was braucht eine Prüfung?
  3. 3 Nach Freigabe selektiv abgleichen: reconcile_bank_transaction pro freigegebenem Match
Pattern 3 Buchung mit Beleg in einem Schritt

Wenn Beleg und Buchungsdaten aus derselben Pipeline stammen – zum Beispiel eine Ausgangsrechnung direkt aus einem Dokumenten-Workflow – können beide in einem einzigen Tool-Aufruf kombiniert werden. Das erspart eine separate Upload-Phase und hält Beleg und Buchung von Anfang an verknüpft.

  1. 1 Beleg (PDF, Bild) und Buchungsdaten gemeinsam vorbereiten
  2. 2 MCP: post_booking_with_document – Beleg und Buchung werden atomar gespeichert
  3. 3 Alternativ per REST: POST /v1/bookings/with-document – identisches Verhalten
Pattern 4 Skill-getriebener Workflow

Für wiederkehrende High-Level-Aufgaben (Rechnung verarbeiten, Bank abstimmen, Monat abschließen) liefert der MCP-Server fertige Playbooks als Prompts. Statt den Workflow jedes Mal neu zu erfinden, lädt der Agent den passenden Skill und folgt dessen Schritten. Skills bauen auf den vorherigen Patterns auf – sie kodifizieren dieselbe Lesen-Vorschlagen-Bestätigen-Schreiben-Disziplin mit aufgaben-spezifischen Tool-Sequenzen und Steuer-/Scope-Gates.

  1. 1 prompts/list – verfügbare Skills für die Scopes des Aufrufers entdecken (scope-gated)
  2. 2 prompts/get <skill_name> – Playbook laden. Der Server wählt EN/DE automatisch anhand der Mandanten-Locale; Override via args.locale
  3. 3 Workflow gemäß Schritt-Liste des Playbooks ausführen, dabei Bestätigungs-Gates und Escape-Hatches respektieren
  4. 4 Auf Pattern 1 zurückfallen, wenn kein Skill passt – oder Skill-Markdown als Ressource lesen (ledgerlou://skills/<slug>) für Clients ohne Prompt-Unterstützung

Anti-Patterns (vermeiden)

Diese Patterns führen zu Fehlbuchungen oder Compliance-Problemen
  • Direktes Buchen ohne vorherige Prüfung – immer zuerst Kontenplan und Perioden laden. Konten, die das Modell aus dem Training kennt, existieren im Mandanten eventuell gar nicht oder sind gesperrt.
  • Schreibrechte für Analyse-Agenten – ein Agent, der nur liest, erhält nur read-Scopes. Breite Schreibrechte für reine Lese-Agenten sind ein Sicherheitsrisiko ohne Nutzen.
  • Sensitive Tools automatisch ohne Bestätigung ausführen – Tools wie post_booking oder reconcile_bank_transaction sollten immer eine explizite Nutzerfreigabe erfordern, bevor sie ausgeführt werden.
  • Hauptbuchbuchungen auf Basis von Modelltraining – SKR-Kontonummern, Perioden und Mandantendaten immer live aus dem Hauptbuch laden, nie aus dem Kontextfenster des Modells. Trainingsdaten können veraltet oder unvollständig sein.
Grundprinzip

Jedes dieser Patterns folgt demselben Kern: Der Agent lädt zunächst Fakten aus dem realen Hauptbuch, schlägt dann etwas vor und schreibt erst nach expliziter Bestätigung. So bleibt das Verhalten deterministisch, prüfbar und GoBD-konform – unabhängig davon, welches Modell oder welche KI-Anwendung verwendet wird.