Ein Agent, der eine E-Mail ohne Rückfrage verschickt, ist kein Feature – er ist ein Bug mit Absender.
Der Unterschied zwischen sympathisch und gruselig liegt selten im Modell, sondern im Datenmodell. Wer E-Mail, Kalender und Aufgaben verbindet, sollte zwei getrennte Zustände bauen: Vorschlag und Ausführung.
Was dabei konkret zählt:
- Jeder Vorschlag ist ein eigenes Objekt: Typ (Antwort, Termin, Aufgabe), betroffene Ressource, Diff zum Original, auslösende Nachricht. Ohne Diff kann niemand prüfen, was er freigibt.
- Lese- und Schreibrechte strikt trennen. Erst read-only (IMAP lesen, CalDAV lesen), Schreib-Scopes wie senden oder Termin anlegen erst beim Commit.
- Freigabe ist ein Commit mit Idempotency-Key, damit ein Doppelklick nicht zwei Antworten rausschickt.
- Vorschläge verfallen. Ein Entwurf auf eine drei Wochen alte Mail ist peinlicher als kein Entwurf – also Tabelle mit TTL statt unendlicher Queue.
- Jede Freigabe landet im Log: wer, wann, was, auf Basis welcher Daten. Nicht fürs Dashboard, sondern für den ersten Bugreport.
Das ist unspektakulär, und genau deshalb trägt es. Der Nutzer behält die Kontrolle, das System bleibt debugbar, und niemand muss erklären, warum der Bot gestern Kollegin Müller geschrieben hat.
Welche Aktion in deinem Setup darf niemals ohne Rückfrage rausgehen – und woran erkennst du sie im Code?
Top comments (1)
Bei uns (Auten-Team, wir lassen Agents echte Bildschirme bedienen) ist es der Klick auf Senden, Kaufen, Löschen oder einen Berechtigungsdialog. Auf UI-Ebene gibt es dafür keinen Write-Scope und keinen Diff, nur einen Button, deshalb erkennen wir es am Ziel des Klicks (Button-Text plus App) und unser Plugin weist den Agent an, vorher nachzufragen.
Frage: Wie würdest du den "Diff zum Original" bauen, wenn die Ausführung kein API-Call ist, sondern ein Klick in einer fremden App? Reicht ein Screenshot des Entwurfs direkt vor dem Senden als Freigabe-Objekt?