Das Problem mit der einfachen Auto-Reply
Die naive Implementierung einer Auto-Reply ist trivial: E-Mail kommt rein, ein LLM schreibt zurück, fertig. Damit haben in den vergangenen achtzehn Monaten Hunderte Firmen erlebt, was passiert, wenn man so etwas in Produktion lässt:
- Der Bot antwortet einer Beschwerde mit "Danke für deine positive Rückmeldung!"
- Der Bot antwortet jedem Phisher und jedem Spam-Bot in einer Loop, bis das eigene IP-Reputation-Score im Keller ist.
- Der Bot trifft eine rechtsverbindliche Aussage, die das Unternehmen nicht halten kann.
- Der Bot antwortet einem Bestandskunden zwölfmal in einer Stunde, weil derselbe Thread mehrere Trigger auslöst.
Wir haben die Auto-Reply-Engine in ORCONIC deshalb so gebaut, dass sie im Zweifel nicht antwortet. Hier ist, wie.
Schritt 1: Klassifikation als harte Vorbedingung
Bevor irgendetwas geschrieben wird, läuft die eingehende Nachricht durch einen Classifier. Das ist nicht "frag das LLM, ob es eine Antwort schreiben soll" — das ist eine deterministische Pipeline aus mehreren Stufen:
- Source-Whitelist: Stammt der Absender aus einer bekannten Domain oder steht er auf einer Allowlist? Wenn nein, wird die Antwort sofort in die Approval-Queue umgeleitet.
- Intent-Klassifikation über ein kleines, billiges Modell mit Zod-validiertem JSON-Output. 12 Intents:
support.question,support.complaint,support.feature-request,sales.inquiry,sales.objection,billing.question,billing.refund-request,legal.notice,personal,noise,unclear,urgent. - Confidence-Schwelle: Liegt die höchste Wahrscheinlichkeit unter 0,7, wird auf "unclear" gemappt.
- Sensitivity-Tags: Enthält die Nachricht juristische Begriffe ("Anwalt", "Klage", "Beschwerde an die Aufsichtsbehörde")? Wenn ja, automatische Eskalation, niemals Auto-Reply.
Erst wenn diese vier Stufen einen klaren, niedrig-sensitiven Intent ergeben, geht es weiter.
Schritt 2: Cooldown und Rate-Limiting
Selbst wenn die Klassifikation grünes Licht gibt, prüft die Engine als nächstes:
- Thread-Cooldown: Habe ich in den letzten 4 Stunden bereits in diesem Thread geantwortet? Wenn ja, kein automatischer Re-Reply.
- Sender-Cooldown: Wie viele Auto-Replies hat dieser Absender in den letzten 24 Stunden bekommen? Limit: 3.
- Workspace-Cooldown: Wie viele Auto-Replies hat der Workspace insgesamt in der letzten Stunde geschickt? Liegt das über dem Schwellwert, ist da wahrscheinlich etwas falsch konfiguriert — die Engine pausiert sich selbst und alarmiert per Slack.
Wir nutzen Redis für die Cooldown-Counter mit einer Sliding-Window-Implementierung. Die Latenz: unter einer Millisekunde pro Check.
Schritt 3: Draft + Approval-Queue
Die Engine schreibt niemals direkt zurück, wenn die Konfiguration nicht explizit "auto-send" für diesen Intent erlaubt. Stattdessen erzeugt sie einen Draft, der in einer Approval-Queue landet. Ein Mensch sieht in einer dedizierten UI:
- Den ursprünglichen Thread
- Den klassifizierten Intent mit Confidence-Wert
- Den Antwort-Draft mit Markdown-Vorschau
- Die referenzierten Memory-Einträge (welche Kundeninformation hat die Engine zur Personalisierung herangezogen?)
- Die referenzierten Wissensbasis-Snippets (welche Doku-Stellen wurden zitiert?)
- Drei Aktionen: Senden, Bearbeiten und senden, Verwerfen
Nur bei expliziter Bestätigung — oder bei den klar als "auto-send" markierten Intents wie support.faq-easy und noise.thank-you-only — wird tatsächlich gesendet.
Schritt 4: Audit nach dem Versand
Jede tatsächlich gesendete Auto-Reply wird mit einem vollständigen Trace im Audit-Log abgelegt:
{
type: "inbox.auto_reply.sent",
threadId,
senderHash, // SHA-256 of sender address — privacy-preserving
intent: "support.question",
confidence: 0.91,
modelUsed: "claude-3-5-sonnet",
promptTokens, completionTokens, costEUR,
approvedBy: userId | "auto-send-rule",
memoryReferences: [...],
knowledgeBaseReferences: [...]
}Dieser Trace ist nicht nur für Compliance hilfreich. Er ist die Grundlage, auf der wir die Performance der Engine über Zeit messen — Antwortrate, Klick-auf-Edit-Rate, Anteil der von Menschen verworfenen Drafts pro Intent.
Was wir an Daten sehen
Aus drei Monaten Produktivbetrieb in der Beta:
- 89,4 % aller eingehenden Nachrichten werden korrekt klassifiziert (gegen menschliches Gold-Label).
- 62 % der eingehenden Nachrichten erzeugen überhaupt einen Draft — der Rest wird vorher von Klassifikation oder Cooldown abgefangen.
- 94 % der erzeugten Drafts werden vom menschlichen Approver ohne Änderung freigegeben.
- 0,3 % der erzeugten Drafts werden verworfen — die meisten davon, weil der Absender doch ein Bot war.
Die mittlere Zeit von Eingang bis (genehmigtem) Versand: 4 Minuten 12 Sekunden. Das ist deutlich schneller als die SLA-Versprechen unserer Beta-Kunden — und langsam genug, dass ein Mensch im Zweifel eingreifen kann.
Was Auto-Reply niemals sein wird
Wir haben uns früh entschieden, bestimmte Intents niemals zu auto-senden:
- Alles, was rechtsverbindlich klingen könnte (Vertragsänderungen, Garantieaussagen)
- Refund- oder Zahlungsversprechen
- Antworten auf Beschwerden, die auf Bezirksaufsicht oder Datenschutzbehörde referenzieren
- Antworten auf Pressanfragen oder Investor-Kontakte
Wir glauben nicht, dass ein LLM diese Aufgabe heute mit der nötigen Verlässlichkeit übernehmen kann. Wir glauben, dass die Engine ihren Wert genau dann maximiert, wenn sie weiß, wann sie schweigen muss.
Was kommt
Auf der Roadmap für Q3:
- Multi-Channel-Unterstützung über E-Mail hinaus: WhatsApp Business, Instagram DMs, X DMs, LinkedIn InMails.
- Per-Industry-Klassifikatoren: Steuerberatungs-Kanzlei vs. SaaS-Anbieter brauchen andere Intent-Mengen. Wir lassen Workspaces eigene Klassifikatoren trainieren.
- Per-Persona-Voicing: Drafts in der Tonalität des konkreten Senders, nicht in einem generischen "Wir bei Acme GmbH". Modulare Voice-Profiles mit Beispieldialogen.
Bis dahin gilt: lieber eine Antwort weniger als eine Antwort zu viel.