Die 7 Prinzipien
Operationsmodell: Transient vs. Persistent
Alle Operationen fallen in zwei Kategorien. Die Grenze bestimmt, ob eine formale Bestätigung erforderlich ist.
| Operation | Typ | Confirm? | Audit? |
|---|---|---|---|
| Mails lesen / klassifizieren | Transient | Nein | Ja (Abruf) |
| Inbox-Übersicht sortieren | Transient | Nein | Nein (intern) |
| Kontext-Fragen beantworten | Transient | Nein | Nein (intern) |
| Externe Systeme abfragen (IMAP, API) | Transient | Nein | Ja (Abruf) |
| Workflow starten | Persistent | Ja | Ja (vor + nach Confirm) |
| Mail senden | Persistent | Ja | Ja |
| Zustand außerhalb Alfred ändern | Persistent | Ja | Ja |
Confirmation Barrier
Jede persistente Operation muss die Confirmation Barrier passieren. Das Confirm-Fenster zeigt den vollständigen Kontext: was Alfred verstanden hat, welche Parameter extrahiert wurden, und was der Workflow tun wird.
Scope = Workflow-Katalog
Alfred kann ausschließlich über definierte Workflows handeln. Der Katalog IST das Berechtigungssystem.
| Nutzerwunsch | Workflow vorhanden? | Alfreds Reaktion |
|---|---|---|
| „Mach die Stromanmeldung“ | Ja | Erklärt + Confirm Card → Ausführung |
| „Lösch alle Mails“ | Nein | „Das kann ich nicht — dafür gibt es keinen Workflow.“ |
| „Schreib eine Antwort-Mail“ | Benötigt | Nur möglich wenn write-mail Szenario existiert |
| „Das Angebot für Webstake“ | Manuell | „Die muss manuell bearbeitet werden.“ |
Audit & Logging
Jede Nutzeraktion wird auditiert — wir können später reduzieren, aber jetzt brauchen wir Daten zum Lernen.
- Jeder externe Abruf (IMAP, API) → Audit-Log-Eintrag
- Jede persistente Aktion → Audit (vor und nach Confirmation)
- Jeder LLM-Aufruf → Prompt-Log
- Interne Verarbeitung (Sortierung, Klassifikation gecachter Daten) → kein Audit
- Menschliche Änderungen → immer geloggt
Kontext & Konversation
Alfred nutzt ein Timeout-Modell für Kontext: Context-Slots (überleben Themenwechsel, 30 Min TTL, kein Stack).
| Aspekt | Verhalten |
|---|---|
| Kontext-Lebensdauer | 30 Minuten TTL, gecacht (kein Re-Fetch) |
| Themenwechsel | Erlaubt — erzeugt neuen Session-Kontext |
| Folgefragen zur Inbox | Nutzen gecachte Daten |
| Session-Wiederherstellung | Backlog: Reload per Session-ID aus Dashboard |
Selektion & Matching
Mail-Matching nutzt LLM Intent Detection, keine Keyword-Listen. Der Mail-Body IST die Nutzernachricht für die Intent-Erkennung — gleiche Pipeline wie Chat.
Nutzer wählt per Chat (natürliche Sprache) oder Direktklick (Face-Buttons, Backlog). Bei Mehrdeutigkeit fragt das LLM nach.
Multi-Mail-Handling
| Szenario | Verhalten |
|---|---|
| „Mach alle“ | Abgelehnt — eins nach dem anderen |
| Nach Abschluss eines Workflows | Proaktiv: „Du hast noch 4 offene Mails — soll ich weitermachen?“ |
| Batch-Verarbeitung | Backlog für später |
Sicherheit
Aktueller Stand: Flache Workflows für die berühmten 80%. Verschachtelung, Batch-Verarbeitung und autonome Klassifikation kommen, wenn ein zahlender Kunde da ist.
Backlog:
- Context Pollution Attack — Mail-Inhalt in Session-Kontext könnte zukünftige LLM-Entscheidungen vergiften
- Workflow Cascade — verschachtelte Confirms bei Sub-Workflows
- Autonome Mail-Katalogisierung — Hintergrund-Klassifikation ohne Nutzer, erfordert eigenes Sicherheitsmodell
- Konfidenz-Schwellenwerte — ab wann verweigert Alfred?