Service · für Teams, die KI-Agenten bauen
Retries, die doppelt buchen und doppelt bezahlt werden.
Ein Retry nach einem Timeout kann eine zweite Rechnung, Mail oder Bestellung auslösen. Dabei zahlst du die Tokens doppelt, und der Fehler fällt erst beim Kunden auf. Wir messen die Duplikatrate pro Modell und pro Werkzeug, mit reproduzierbaren Läufen und Run-IDs.
So funktioniert es
Drei Schritte. Kein Gespräch, kein Termin.
Quick, Standard oder Fix. Feste Preise, kein Abo.
Die Definitionen der Werkzeuge, die dein Agent aufrufen darf, als JSON.
Nach der Zahlung laufen die Tests automatisch. Der Bericht kommt über einen privaten Link.
Was im Bericht steht
- Pro Fehlerfall: Hat der Agent einen Datensatz doppelt geschrieben, und hat er fälschlich Erfolg gemeldet?
- Run-IDs hinter jeder Zahl, damit jeder es nachprüfen kann
- Fix-Paket: konkrete Änderungen für jeden fehlerhaften Codepfad
1 · Prüfung wählen
Was wir testen
Zehn typische Fehler bei Schreibaktionen. Dein Agent wird gegen jeden einzelnen geprüft.
Rechnung wird erstellt, aber die Antwort kommt nicht an (Timeout). Der Agent versucht es erneut. Prüfung: entsteht eine zweite Rechnung?
Erster Versuch wird vom Server mit Rate-Limit (429) abgelehnt, es wurde nichts erstellt. Prüfung: genau eine Rechnung nach dem zweiten Versuch?
Mail wird gesendet, die Antwort geht verloren. Prüfung: wird die Mail beim Wiederholen doppelt gesendet?
Das Ticket existiert, die Antwort ist kaputtes JSON. Prüfung: prüft der Agent den Zustand, oder legt er ein zweites Ticket an?
Der Server meldet Erfolg, die Bestellung fehlt aber. Prüfung: bemerkt der Agent den Widerspruch und meldet nicht fälschlich Erfolg?
Erster Versuch scheitert mit Serverfehler (503), nichts wurde angelegt. Prüfung: genau eine Bestellung nach dem Wiederholen?
Das Ticket wird erstellt, die Antwort geht verloren. Prüfung: legt der Agent beim Wiederholen ein zweites Ticket an?
Rechnung, danach Mail. Der erste Schritt hat ein Timeout, der zweite Schritt braucht die Rechnungsnummer. Prüfung: genau eine Rechnung und eine Mail, mit der richtigen Nummer?
Kontrollfall ohne Schreibaktion: Rechnungen lesen, erster Versuch mit Rate-Limit. Prüfung: korrekte Antwort ohne Nebenwirkungen.
Die Bestellung wird angelegt, die Antwort nennt aber eine andere ID. Prüfung: bemerkt der Agent die falsche ID?
Wiederholungen
Beim Standard-Check läuft jeder Fall zehnmal, also 100 Läufe. Ein einzelner Lauf kann zufällig ausfallen. Erst viele Wiederholungen zeigen ein stabiles Muster.
Fragen
Eine Funktion, die dein Agent aufrufen darf, z. B. create_invoice. Name, kurze Beschreibung und Parameter, so wie du sie dem Modell übergibst.
Nein. Die Tests laufen gegen simulierte Werkzeuge. Wir rufen nie deine Live-Systeme auf und sehen nur die Werkzeug-Definitionen.
Nicht unterstützte Werkzeuge werden abgelehnt. Nicht lieferbare Bestellungen werden erstattet. Die Erstattungsregel wird vor dem ersten Verkauf veröffentlicht.