Eine fixe Sequenz durch eine agentische Schleife ersetzen.

Wie die alte Sequenz aussah

Die Pre-April-Pipeline war ein vernünftiges v1: Jede Kampagne hatte eine feste 5-Schritt-E-Mail-Sequenz mit Template-Slots zur Personalisierung, zwei oder drei Template-Varianten pro Schritt und einem Job, der die antwortstärkere Variante auf Plan beförderte. Versand und Drafting waren entkoppelt — der SequenceRunnerService führte jeden Lead nach Kadenz durch Stufe 1 → 2 → 3 → 4 → 5, der SequenceDraftingAgent + der PersonalizationAgent füllten die Template-Slots, und der ReplyTriageAgent reichte positive Antworten zur Ein-Klick-Freigabe in die AI-Inbox zurück.

Es funktionierte. Es belog sich auch an drei Stellen.

Erstens: „Stufe 3" war kein echtes Signal. Zwei Leads auf demselben Template in derselben Stufe konnten völlig unterschiedliche Gesprächszustände haben — einer war gebounct, einer hatte zweimal geöffnet, einer hatte einen Link geklickt, aber nicht geantwortet — und der Sequence-Runner sah nichts davon. Die Next-Send-Entscheidung wurde gefällt, indem gezählt wurde, wie viele E-Mails rausgegangen waren, nicht indem gelesen wurde, was passiert war.

Zweitens: Der A/B-Winner-Picker beförderte das Falsche. Antwortrate als einziges Signal kollabiert positive Antworten, negative Antworten und „Sprechen wir später" in eine Zahl. Der Winner-Picker beförderte fröhlich die Variante mit mehr Abmeldungen. Wir bekamen es mit, weil wir die Inbox lasen, nicht weil das System es kennzeichnete.

Drittens: Die Templates waren ein Einweg-Spiegel. Der Käufer (ein B2B-SaaS-Gründer, der selbst Outbound macht) sah seinen Namen in der Absenderzeile, konnte aber nicht nachvollziehen, warum eine bestimmte E-Mail an einen bestimmten Lead ging. „Das war Schritt 2 von Sequenz B" ist keine Antwort, die er gegenüber seinem eigenen Interessenten verteidigen kann.

Die Form, mit der wir sie ersetzt haben

Die neue Schleife ist ein einzelner Agent — der LeadOutreachAgent — der einmal pro Lead und Entscheidungsmoment läuft, mit dem vollen Lead-Zustand im Kontext. Er tut eines von vier Dingen: jetzt senden (welcher Kanal, welcher Text), warten (bis wann und warum), halten (an die AI-Inbox eskalieren) oder beenden (suppress, Lead-Ziel erreicht oder kein Weg vorwärts).

Der Executor ist Claude Sonnet 4.6. Er liest die Discovery-Signale des Leads, vorherige Outreach-Versuche (gesendet + Antworten), die Versuchszahl pro Kanal, das Kampagnenziel und die Markenstimme sowie eine kleine Memory-Zusammenfassung, die der Agent selbst zwischen Entscheidungen pflegt. Er liefert eine strukturierte Entscheidung plus eine einzeilige Begründung, beide auf der Outreach-Historie des Leads gespeichert.

Für Grenzfälle — eine heiße Antwort, die sorgfältig beantwortet werden muss, ein Lead, von dem gebouncet wurde, aber für den ein frischer Role-Account-Treffer existiert, eine Entscheidung, bei der ein falscher Versand teuer wäre — ruft der Agent vor dem Handeln einen Opus-4.7-Advisor für eine zweite Meinung. Die Trennung ist Absicht: Sonnet erledigt das Volumen (günstig, schnell, gut genug), Opus reviewt, wenn es teuer wird (langsam, teuer, lohnt sich).

Der MessageVerifier: Cite-or-Discard

Das Trust-Loop-Primitiv mit dem größten Hebel war der MessageVerifier. Nachdem der Executor einen Body gedraftet hat, aber bevor irgendetwas versandt wird, liest der Verifier den Draft als Klartext und fragt: Lässt sich jede konkrete Aussage in dieser E-Mail aus den tatsächlichen Signalen des Leads belegen? „Wir haben gesehen, dass Sie auf padelclub-berlin.com kein Buchungs-Widget haben" — belegbar, wenn die Discovery-Probe diese Absenz erfasst hat. „Mir ist aufgefallen, dass Sie einen Sales Lead suchen" — belegbar, wenn ein Hot-Lead-Trigger das Greenhouse-Listing erfasst hat. „Ich fand Ihren letzten Launch großartig" — nicht belegbar, sofern der Discovery-Datensatz nicht tatsächlich ein Launch-Event hat.

Drafts, deren Aussagen den Cite-Check nicht bestehen, gehen mit redigierten Aussagen und einem Retry-Budget von eins zurück zum Executor. Schlägt auch der zweite Draft fehl, taucht der Lead als MESSAGE_VERIFICATION_FAILED-Aufgabe in der AI-Inbox auf, statt zu senden. Der ganze Punkt: Ein selbstbewusster, flüssiger Draft, der außerdem nicht stimmt, ist die Fehlersituation, die dieses Produkt nicht ausliefern kann — weil die Domain-Reputation des Käufers den Preis zahlt.

Das Pro-Lead-Entscheidungs-Log

Jede Agenten-Ausführung hängt einen Eintrag an die Outreach-Historie des Leads. Jeder Eintrag ist ein kleiner strukturierter Datensatz — Richtung (outbound / inbound), Kanal (E-Mail / Manual-Dispatch), Entscheidung und Begründung, Kosten in Tokens, das produzierende Modell und eine Referenz auf die gesendete oder empfangene Nachricht. Hold- und Terminate-Entscheidungen werden ebenfalls angehängt, mit dem Grund und der ggf. erzeugten AI-Inbox-Aufgabe.

Das Log ist das Trust-Artefakt. In der Campaign-Detail-Ansicht kann ein Käufer jeden Lead öffnen und in Klartext lesen, was passiert ist und warum — nicht „Schritt 3 lief planmäßig", sondern „OUTBOUND #2 gesendet, weil der vorige Versand 4 Tage her war und zweimal geöffnet, aber nicht geklickt wurde; zitiert auf die Missing-Booking-Widget-Probe aus der Discovery." Wenn ein Empfänger zurückschreibt und fragt, woher wir seine E-Mail haben, hat der Gründer eine echte Antwort.

Die Kosten-Obergrenze, weil Agenten driften

Eine Schleife, die pro Lead entscheidet, kann sich drehen. Wir haben das auf zwei Wegen gedeckelt. Pro Lead hat der Agent eine tägliche Kosten-Obergrenze (LLM-Tokens + bezahlte Anreicherung + Verifier-Calls); wenn die Obergrenze erreicht ist, gibt er eine WAIT-Entscheidung mit dem Cost-Cap-Grund zurück, und der Scheduler greift nach dem Tageswechsel wieder auf. Pro Projekt erhebt eine tägliche Budget-Obergrenze im Billing-Layer eine DailyBudgetExhaustedException am Orchestrator-Chokepoint — das gesamte Projekt pausiert Outreach mit einer CAMPAIGN_AUTO_PAUSED-Aufgabe, und der Nutzer kann sie per Klick aufheben.

Wir haben überlegt, die Obergrenze als reine Warnung zu gestalten. Wir bereuen nicht, sie hart gemacht zu haben. Drift ist real, und eine $400-Rechnung aus einer Run-Away-Schleife in Woche eins eines $99-Plans ist die Art Vertrauensverlust, aus der man sich nicht herausentschuldigen kann.

Was wir gelöscht haben

Das Rewrite ermöglichte es, einen sinnvollen Komplexitäts-Anteil zu verwerfen:

• EmailTemplate-Entität und ihre CRUD-Endpunkte — Templates existieren nicht mehr als First-Class-Objekt; der Agent draftet pro Entscheidung aus Markenstimme + Signalen.
• SequenceRunnerService, SequenceDraftingAgent, PersonalizationAgent, ReplyTriageAgent — ihre Aufgaben kollabierten in die einzelne Agenten-Schleife.
• WinnerPickerService und das A/B-Test-Modul — mit Per-Decision-Drafting ist „Winner" eine Pro-Lead-Frage, keine Template-Promotion auf Kampagnenebene.
• Campaign.tone, Campaign.templates, Lead.sequenceState — alle weg. Der neue Zustand lebt auf der Outreach-Historie des Leads; Kampagnen beschreiben Ziele und erlaubte Kanäle, keine Skripte.
• Drei Activity-Event-Typen, die an die Template-Promotion gebunden waren — es gibt dort nichts mehr zu protokollieren.

Etwa ~3.000 Zeilen Code sind unter dem Strich entfernt. Das ist nicht die interessante Zahl — die interessante ist, dass die Oberfläche, die ein Gründer verstehen muss, um dem Produkt zu vertrauen, kleiner geworden ist. Fünf weniger Konzepte im Mental Model.

Was wir evaluieren — und was nicht

Wir haben parallel zum Rewrite ein Offline-Eval-Harness gebaut. Der Agent wird gegen 10 handkuratierte Lead-Fixtures aus fünf Vertikalen (Local-Physical, Hospitality, Visual-Brand, Online-B2B, Long-Tail) bewertet. Für jedes Fixture prüfen wir Action-Accuracy (wählt der Agent SEND / WAIT / HOLD / TERMINATE so, wie es ein menschlicher Reviewer täte?), Citation-Disziplin (lässt sich jede Aussage auf ein Fixture-Signal zurückführen?) und Kosten (Per-Fixture-Cap 4¢, Total-Cap 50¢ pro Eval-Lauf).

Was wir bewusst noch nicht veröffentlichen, sind Antwortraten, Hot-Lead-Raten oder Conversion-Zahlen. Zwei Gründe. Erstens: Die agentische Schleife läuft Wochen, nicht Monate — jede Zahl, die wir nennen würden, wäre Small-Sample. Zweitens: Diese Zahlen gehören den Kunden, nicht uns; sie kommen als Kunden-Stories, wenn Kunden sie erzählen wollen und Daten haben, die sie gerne teilen.

Was als Nächstes kommt

Drei Threads seit dem April-Rewrite:

• Source-Routing. Der Agent entscheidet, was gesendet wird; ein Geschwister-Source-Router (ebenfalls Sonnet) entscheidet, wo Leads gefunden werden. Heute neun aktive Discovery-Quellen, pro Kampagne anhand des ICP geroutet.
• Hot-Lead-Trigger. Ein Pro-Projekt-Stündlich-Scanner beobachtet aktive Leads auf Buying-Intent-Signale — Hiring-Spikes, Funding-Ankündigungen, Tech-Stack-Änderungen, Competitor-Churn. Treffer tauchen als HOT_LEAD_BOOST-Aufgaben auf und schieben den Lead an den Anfang der Outreach-Queue.
• Vektor-Ähnlichkeits-Loops. Sobald eine Kampagne fünf Konversionen hat, mitteln wir deren Embeddings und legen 50 Lookalike-Leads als AI-Inbox-Aufgabe vor. Dasselbe Primitiv läuft rückwärts: 3-20 Ihrer besten Kundendomains einfügen, in unter 2 Sekunden 50 Lookalikes zurückbekommen.

Jeder davon komponiert auf die agentische Schleife auf, statt sie zu umgehen. Die Entscheidung, was wann gesendet wird, bleibt an einer Stelle. Die Entscheidung, welcher Lead an die Oberfläche kommt, wird mit der Zeit stärker.

Wenn Sie das hier schon kennen

Sie sind B2B-SaaS-Gründer und machen Ihren Outbound selbst. Sie haben Lemlist oder Instantly ausprobiert. Sie haben gesehen, wie die KI eine selbstbewusste Drei-Absatz-Mail über ein Problem schrieb, das der Lead nicht hat, und gespürt, wie es ankommt: Das ging gerade unter meinem Namen raus.

Dieses Gefühl ist die Design-Vorgabe. Die agentische Schleife, der Cite-or-Discard-Verifier, das Pro-Lead-Entscheidungs-Log, die Kosten-Obergrenze — keines davon existiert, um die KI smarter zu machen. Sie existieren, damit Sie, wenn eine E-Mail Ihr Postfach verlässt, nachlesen können, warum sie ging, sie auf Nachfrage verteidigen und der nächsten vertrauen können, weil die Schleife aus der letzten gelernt hat.

Wenn das das Produkt ist, auf das Sie gewartet haben — die 14-Tage-Testphase beginnt da, wo Sie beginnen. Keine Demo-Pflicht, Karte hinterlegt, jederzeit kündbar.

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