Belegen oder verwerfen als Produkt-Primitiv.

Der Fehlerfall, um den man designen muss

Der kategorie-definierende Fehlerfall für einen KI- Vertriebsagenten ist keine niedrige Antwortrate. Es ist eine E-Mail — eine — die das Postfach des Nutzers mit einer erfundenen Behauptung verlässt. „Ich habe gesehen, dass Ihr Team gerade eine Serie B aufgebracht hat", wenn es keine Serie B gibt. „Glückwunsch zur Eröffnung des Berliner Büros", wenn das Berliner Büro ein alter, nie aktualisierter Footer ist. „Ihr Wettbewerber X hat gerade mit uns unterschrieben", wenn X das nicht hat. Der Lead antwortet „woher haben Sie das?" oder, häufiger, gar nicht und markiert die E-Mail als Spam, weil das ist, was Menschen tun, wenn eine offensichtliche Lüge in ihrem Posteingang auftaucht.

Der Nutzer — unser Käufer, der B2B-SaaS-Gründer, der sein eigenes Outbound macht — wird das nicht einmal tolerieren. Seine Domain ist die Domain seines Unternehmens. Die E-Mail-Signatur trägt seinen Namen. Er wird die Kampagne pausieren und uns pausieren, und er hat damit recht. Die Frage ist also nicht „wie minimieren wir Halluzinationen". Sondern „wie machen wir Halluzinationen unmöglich auszuliefern" — in dem Wissen, dass diese unmögliche Latte andere Kosten erzwingt, die wir tragen müssen.

Warum kein Qualitäts-Score

Der erste Reflex, und der Reflex, den das meiste LLM-Eval- Tooling fördert, ist, den Draft zu bewerten. Gib ihm eine 0-bis-1 Halluzinations-Wahrscheinlichkeit. Setze einen Schwellenwert. Sende alles darunter. Das Problem mit einem kontinuierlichen Score ist, dass ein Schwellenwert immer irgendwo falsch ist. Eng setzen — und du wirfst Drafts weg, die in Ordnung waren. Locker setzen — und du verschickst Drafts, die es nicht waren. Der Schwellenwert wird zu einem Knopf, und der Knopf wird zu etwas, das man justiert, und ihn zu justieren bedeutet, die Fehler zu messen — was bedeutet, einige durchzulassen, um sie messen zu können.

Das Belegen-oder-Verwerfen-Reframe umgeht den Knopf komplett. Jede Aussage im Draft zeigt entweder auf einen konkreten Abschnitt des Lead-Kontextes — einen Absatz auf der Website, eine Zeile einer Stellenanzeige, einen Fund einer Discovery-Probe — oder eben nicht. Wenn ja, gut. Wenn nicht, ist der Draft kaputt; wirf ihn weg und bitte den Executor, mit den Begründungen des Verifiers neu zu schreiben. Ein- oder zweimal neu zu schreiben schließt die Lücke meistens. Wenn nicht, gibt der Agent diese Entscheidung auf und eskaliert — nicht stillschweigend, sondern mit einem Eintrag im Decision-Log, den der Nutzer sehen kann.

Was „Aussage" in der Praxis bedeutet

Der Verifier-Prompt ist unspektakulär und absichtlich so. Er liest den Draft, listet jede konkrete Behauptung über den Lead auf — seine Firma, sein Produkt, sein Team, sein Markt, seine jüngste Aktivität — und fragt für jede: woher im Kontext stammt das? Akzeptable Antworten sind Textabschnitte des Quellmaterials, das der Executor bekommen hat. Alles andere gilt als unbelegt.

Generische Copy ist per Konstruktion ausgenommen. „Ich melde mich, weil wir Teams wie deinem helfen" macht keine faktische Aussage über den Lead jenseits von „wir existieren und helfen Teams" — das ist eine Selbst-Aussage, keine Lead-Aussage. „Ich habe auf eurer Karriereseite gesehen, dass ihr drei SDRs sucht" ist eine Lead-Aussage, und der Text der Karriereseite belegt das entweder oder eben nicht. Der Verifier kontrolliert keinen Stil. Er kontrolliert Fakten.

Der interessante Fehlerfall, den der Verifier in der Praxis fängt, ist nicht der offensichtliche. Es ist die plausibel klingende Folgerung. Der Executor sieht einen Lead in der Veranstaltungsbranche und schreibt „ich stelle mir vor, ihr jongliert gerade mit ein paar Sommerfestivals". Der Lead-Kontext sagt nichts über Sommerfestivals. Die Aussage ist plausibel — Events, Mai — aber sie ist unbelegt, und der Verifier wirft sie weg. Gut. Plausibel-aber-unbelegt ist genau die Klasse von Aussagen, die Vertrauen langsam zersetzen, weil eine von zehn in einer Art falsch sein wird, die der Nutzer nicht vorhersagen kann.

Was es uns kostet

Drei reale Kosten, keine davon theoretisch:

Niedrigere Sende-Rate pro Entscheidung. Manche Drafts lassen sich für einen bestimmten Lead nicht belegbar erzeugen — der Lead-Kontext ist dünn (eine Website mit einem Absatz und ohne Signal). Der Executor versucht es, der Verifier wirft es weg, der Executor versucht es mit engerem Scope erneut, und manchmal gibt es nach dem Retry-Cap einfach keinen Draft, den man verschicken sollte. Die Entscheidung wird zu einem WAIT oder, in Nicht-E-Mail-Kanälen, zu einer manuellen Outreach-Aufgabe. Der Nutzer sieht weniger Sendungen pro Kampagne als bei einem Tool, das nicht so hart gated. Das ist der Trade.

Zusätzliche LLM-Kosten pro Entscheidung. Drafter-Pass plus Verifier-Pass sind grob 2× die Token- Ausgaben pro akzeptiertem Draft, plus die Kosten der verworfenen Drafts, die einen Retry bekamen. Wir budgetieren das in der Pro-Lead-Kostenobergrenze, und die Kampagne pausiert automatisch, wenn sie anfängt, Kosten zu verbrennen, ohne akzeptierte Drafts zu produzieren. Diese Zeile ist es wert.

Eine Klasse cleverer Drafts, die wir nicht ausliefern können. Wenn der cleverste mögliche Opener für diesen Lead eine Schlussfolgerung erfordert, die der Kontext nicht trägt, liefern wir ihn nicht aus. Ein Mensch, der stundenlang schreibt, könnte diese Schlussfolgerung landen, weil er Dinge weiß, die der Agent nicht weiß. Der Agent kann das nicht. Die Decke der Draft-Cleverness ist „was der Kontext stützt". Wir haben entschieden, dass das die richtige Decke ist.

Warum „Verifier" und nicht „Evaluator"

Die Namensgebung war bewusst. Ein Evaluator impliziert einen Score und einen Schwellenwert. Ein Verifier impliziert bestehen oder durchfallen. Team, Prompt und API benutzen alle „verifizieren". Ein Draft ist entweder verifiziert oder nicht. Wenn er es nicht ist, gehen die Gründe direkt zurück an den Executor, der Nutzer sieht sie in der AI Inbox, wenn die Verifikation wiederholt scheitert, und die Kampagne zeichnet das Scheitern in ihrem Activity-Feed auf.

Einer der AI-Inbox-Aufgabentypen heißt buchstäblich MESSAGE_VERIFICATION_FAILED. Wenn ein Draft die Verifikation öfter als der Retry-Cap erlaubt nicht besteht, sieht der Nutzer den Draft, die Begründungen des Verifiers und den Lead-Kontext nebeneinander. Er kann manuell freigeben (falls der Verifier zu streng war — selten, aber real), bearbeiten oder verwerfen. Der Notausgang ist sichtbar, weil die Alternative — den Lead still fallenzulassen — sich schlechter anfühlte als den Nutzer eine Frage zu stellen.

Belegen-oder-verwerfen komponiert

Das Stück, das das Primitiv jenseits eines einzelnen Drafters nützlich macht, ist, dass es mit jedem anderen Generator komponiert, den wir ausliefern. Antwort-Drafts laufen durch. Manuelle Outreach-Skripte für Nicht-E-Mail- Kanäle laufen durch. Der Brand-Voice-Extractor, wenn er ein Markenstimmen-Beispiel aus dem Gesendet-Ordner des Nutzers vorschlägt, läuft durch einen verwandten Cite-Check gegen die Quell-E-Mail. Alles, was der Agent produziert und was vor einem Menschen landet, läuft durch dasselbe Gate.

Das war kein Feature, das wir geplant haben. Wir haben mit dem Drafter angefangen, den Verifier für den Drafter gebaut, und dann wollte jede nachfolgende Fläche, die Text erzeugte, dasselbe Gate. Das ist der Test eines guten Primitivs — wenn das nächste, was du baust, danach greift, ohne dass du es ihm sagen musst.

Was wir immer noch falsch machen

Der Verifier ist nicht perfekt. Zwei reale Klassen von Treffern, die er verpasst:

Überdehnung durch Assoziation. Der Lead- Kontext erwähnt „wir bedienen Enterprise-Kunden" und der Draft sagt „ich habe gesehen, dass ihr drei Fortune-500- Logos unterschrieben habt". Der erste Teil ist belegt; der zweite erfindet Spezifität. Der Verifier fängt die meisten davon. Er verpasst manche, wenn die Spezifität subtil ist. Wir beobachten das Fehler-Log und ziehen den Prompt nach, wenn Muster auftauchen.

Veralteter Kontext. Die Website des Leads sagte vor sechs Monaten etwas Wahres, das nicht mehr stimmt. Der Verifier kann das nicht wissen. Der Draft zitiert die Website und geht raus. Der Lead antwortet „das machen wir nicht mehr". Das ist kein Verifier-Bug — die Quelle war real. Es ist ein Frische-Bug im Discovery-Layer, und wir behandeln ihn als solchen: auf TTL neu scrapen, Fetched-At- Zeitstempel speichern, einen Draft als low-confidence markieren, wenn die Quelle älter als 60 Tage ist.

Falls dich eine erfundene E-Mail schon einmal verbrannt hat

Du bist der Nutzer, der eines der Kategorie-Tools ausprobiert hat, und der erste Batch ging mit zwei E-Mails raus, die selbstbewusst einen Wettbewerber von dir namentlich erwähnten, als wäre der Lead bereits dessen Kunde. Du hast das Tool pausiert und vertraust der Kategorie nicht. Der Reflex ist, weniger Sendungen, engeren Scope, mehr manuelle Prüfung zu verlangen. Das funktioniert, aber es macht das Tool nicht zu einem Tool.

Das Belegen-oder-Verwerfen-Primitiv ist, was das Tool gleichzeitig autonom und vertrauenswürdig macht. Der Agent kann allein laufen, weil das Gate „eine erfundene Aussage ausliefern" per Konstruktion unmöglich macht. Der Nutzer muss nicht jeden Draft lesen. Er muss die AI Inbox lesen, wenn die Verifikation scheitert oder wenn etwas anderes ihn braucht. Den Rest erledigt der Agent.

Wenn du den Verifier in Aktion an einem echten Lead sehen willst — inklusive einem Draft, der scheitert, und dem Agent, der neu schreibt — legt die 14-Tage-Testphase das Pro-Lead- Decision-Log unter jedem Lead in einer Kampagne offen. Du kannst jeden Drafter-Pass, jeden Verifier-Pass, jede Ablehnungsbegründung lesen. Der Agent versteckt seine Arbeit nicht.

— Tobias Duelli, Gründer · tobias@overwise.com