Milian Missions: Ereignisgesteuerte KI-Automation mit klaren Grenzen

Famulor erweitert Milian Missions um das Mission Studio. Seit dem Update vom 30. August 2026 können Missions nicht nur manuell oder nach Zeitplan laufen, sondern auch auf Ereignisse im Workspace reagieren. Ein abgeschlossener Anruf, eine neue Nachricht, eine Buchung, ein Lead, ein Webhook oder ein Ereignis aus einem verbundenen System kann damit den Startpunkt für Hintergrundarbeit bilden. Entscheidend ist nicht allein der neue Trigger: Ziel, Kontext, Verbindungen, erlaubte Aktionen und Laufzeitgrenzen werden gemeinsam als veröffentlichte Version festgehalten.

Das Wichtigste in Kürze

• Mission Studio bündelt Trigger, Zugriff, Runs und Versionen in einer Oberfläche.
• Ereignisgesteuerte Missions reagieren auf Workspace-Events; bestehende manuelle und geplante Missions laufen unverändert weiter.
• Jede veröffentlichte Version friert Trigger, Filter, Ressourcen, App-Verbindungen, Aktionsgruppen und Run-Limits ein.
• Runs werden sichtbar protokolliert, nacheinander verarbeitet und mit Status, Credits und Transcript nachvollziehbar gemacht.
• Event Missions sind derzeit eine Workspace-Beta-Funktion.

Was ist neu im Mission Studio?

Eine Mission ist laut Famulors Dokumentation zu Milian Missions eine versionierte Aufgabe für den Workspace-Copiloten Milian. Sie läuft ohne geöffneten Browser-Tab im Hintergrund – auf Abruf, nach Zeitplan oder jetzt auch nach einem Ereignis. Das Mission Studio gliedert die Konfiguration in Overview, Trigger, Access, Runs und Versions. Bestehende, rein zeitgesteuerte Missions werden nicht umgestellt; die erste Bearbeitung im Studio erzeugt einen neuen Entwurf.

Eine veröffentlichte Mission besitzt genau einen Trigger. Neben manuellen und geplanten Starts unterstützt das Studio Ereignisse aus Anrufen, Unterhaltungen, Nachrichten, E-Mails, Buchungen, Leads, eingehenden Webhooks, CRM-Systemen und verbundenen Apps. AND/OR-Filter können den Start anhand geeigneter Ereignisfelder weiter eingrenzen. So wird aus „jeden Morgen prüfen“ beispielsweise „direkt reagieren, wenn ein passendes Ereignis eintritt“.

Das unterscheidet Missions von Mid-call Actions in laufenden Gesprächen: Mid-call Actions erledigen Arbeit, während ein Assistent mit einem Kunden spricht. Missions übernehmen eigenständige Hintergrundarbeit, die manuell, geplant oder durch ein Workspace-Ereignis angestoßen wird.

Vom Zeitplan zum Ereignis: Warum das relevant ist

Zeitpläne bleiben sinnvoll für tägliche Berichte oder wöchentliche Kontrollen. Bei operativen Ereignissen erzeugen sie jedoch zwangsläufig Wartezeit oder unnötige Leerlaufprüfungen. Ein Event-Trigger startet die Mission näher am tatsächlichen Anlass. Gleichzeitig verhindert die veröffentlichte Version, dass eine beiläufige Bearbeitung die aktive Logik sofort verändert.

Auch außerhalb von Famulor wird dieses Muster intensiv diskutiert. Ein stark beachteter Hacker-News-Thread zu dauerhaften Workflows dreht sich um Wiederaufnahme, Retries, Versionierungsaufwand, Transparenz und die reale Betriebslast. Das ist ein Community-Signal, kein Wirksamkeitsnachweis. Die Studie SKILL.nb betont für wiederverwendbare Agenten-Workflows ebenfalls Versionierung, Ausführungsschranken und nachvollziehbare Evidenz als Zuverlässigkeitsmechanismen. Mission Studio setzt diese Richtung in ein Produktmodell für operative Workspace-Aufgaben um.

Drei praktische Muster für ereignisgesteuerte Missions

1. Nach einem Anruf gezielt nachfassen

Ein abgeschlossener Anruf kann eine Mission starten, die den vorhandenen Kontext auswertet und – innerhalb der freigegebenen Aktionen – einen Follow-up-Entwurf, eine Aufgabe oder eine interne Zusammenfassung vorbereitet. Filter sollten den Auslöser auf die Fälle begrenzen, die wirklich Nacharbeit benötigen. Das spart pauschale Batch-Prüfungen und hält den Prozess nah am Kundenkontakt.

2. Neue Leads kontrolliert anreichern

Ein neuer Lead kann eine Mission auslösen, die freigegebene Workspace-Ressourcen und gespeicherte App-Verbindungen verwendet. Sinnvoll ist ein enger Auftrag: relevante Informationen zusammentragen, den Datensatz strukturieren und einen nächsten Schritt vorbereiten. Wer dafür aktuelle Webinformationen benötigt, kann den Prozess mit geeigneten Recherche- und Agent-Tools kombinieren – allerdings nur, wenn diese im Zugriff der Mission ausdrücklich erlaubt sind.

3. Buchungen und Nachrichten in Folgearbeit übersetzen

Eine neue Buchung, eingehende E-Mail oder Nachricht kann Hintergrundarbeit auslösen: etwa eine interne Checkliste vorbereiten, zuständige Teams informieren oder eine Zusammenfassung erstellen. Das Muster ergänzt automatisierte Terminplanung über mehrere Kanäle, ohne den Kundendialog selbst mit zusätzlicher Prozesslogik zu überladen.

Klare Grenzen statt unbegrenzter Agentenrechte

Mission Studio macht den erlaubten Handlungsspielraum vor der Veröffentlichung sichtbar. Die aktive Version enthält den Trigger, Filter, referenzierte Ressourcen, einzelne gespeicherte App-Verbindungen, erlaubte Aktionsgruppen sowie Obergrenzen für Credits, Tool-Aufrufe und Laufzeit. Milian erhält bei einem Run nur diesen veröffentlichten Scope.

Verbindungen werden unmittelbar vor jedem Run erneut geprüft. Fehlt eine Verbindung, ist sie abgelaufen, deaktiviert oder fehlerhaft, verweigert die Mission die Ausführung. Bei eingehenden Webhooks kann ein Workspace Owner oder Admin ein Secret erzeugen, das nur einmal angezeigt und im Header X-Automation-Secret übertragen wird. Eine Rotation macht das vorherige Secret sofort ungültig.

Diese Grenzen passen zu dem Vorgehen im Famulor-Guide zu Voice-AI-Governance: Erst Zweck und Berechtigungen festlegen, dann den Agenten ausführen und anschließend anhand von Runs und Transcripts prüfen.

Versionierung und Runs: Was im Betrieb nachvollziehbar bleibt

Die Veröffentlichung erzeugt eine unveränderliche Version. Spätere Änderungen bleiben zunächst als Entwurf bestehen, während die aktive Version weiterläuft. Auch das Wiederherstellen einer älteren Version überschreibt die Historie nicht, sondern erzeugt einen neuen Entwurf. Mitglieder dürfen Entwürfe speichern; Workspace Owners und Admins veröffentlichen oder pausieren. Viewer- und Billing-Rollen bleiben schreibgeschützt.

Jeder Trigger erzeugt einen sichtbaren Hintergrund-Run. Ereignisse werden dedupliziert und pro Mission nacheinander verarbeitet; weitere Ereignisse warten in einer FIFO-Warteschlange, statt stillschweigend verloren zu gehen. Das Dashboard zeigt aktive Version, letzten und nächsten Run, Status, Credit-Verbrauch und Attention State. Run-Transcripts werden laut Dokumentation zehn Tage aufbewahrt.

Fehler bleiben sichtbar. Eine potenziell bereits ausgeführte externe Änderung wird nicht automatisch wiederholt. Nach Prüfung des Transcripts kann ein abgeschlossener Run manuell erneut gestartet werden; dabei entsteht ein separat markierter Run mit Verweis auf die ursprüngliche Ausführung. Dieses Verhalten reduziert das Risiko doppelter externer Aktionen.

So startest du eine Mission sinnvoll

1. Ziel eng formulieren: Beschreibe ein überprüfbares Ergebnis statt eines offenen Dauerauftrags.
2. Einen Trigger wählen: Nutze ein Ereignis nur dann, wenn sofortige Reaktion einen Vorteil bringt; für Berichte bleibt ein Zeitplan oft klarer.
3. Filter setzen: Begrenze den Trigger auf relevante Fälle und teste die Felder mit echten Beispielen.
4. Kontext und Aktionen beschränken: Füge mit @ nur benötigte Workspace-Ressourcen hinzu und erlaube nur erforderliche Aktionen und Verbindungen.
5. Limits definieren: Lege maximale Credits, Tool-Aufrufe und Laufzeit passend zum Auftrag fest.
6. Entwurf prüfen und veröffentlichen: Kontrolliere Ziel, Trigger, Filter, Zugriff und Limits als eine Version.
7. Runs beobachten: Prüfe Status, Transcript und Attention State, bevor du den Scope erweiterst.

API und MCP für technische Teams

Missions lassen sich nicht nur im Dashboard verwalten. Die öffentliche REST API deckt Erstellen, Lesen, Aktualisieren, Löschen und Starten von Missions sowie das Auflisten und erneute Starten von Runs ab. Dieselben Funktionen stehen als MCP-Tools mit getrennten routines:read- und routines:write-Scopes zur Verfügung. Wer Agenten über externe Oberflächen betreibt, findet im Beitrag zu Famulor MCP mit ChatGPT und Claude den passenden Architekturkontext.

Häufige Fragen

Ersetzen Event Missions bestehende Zeitpläne?

Nein. Manuelle, stündliche, tägliche, werktägliche, wöchentliche und benutzerdefinierte Zeitpläne bleiben verfügbar. Bestehende geplante Missions laufen unverändert weiter.

Was passiert, wenn Beta Features ausgeschaltet werden?

Ereignisgesteuerte Missions werden pausiert und als aufmerksamkeitsbedürftig markiert. Klassische manuelle und geplante Missions bleiben aktiv.

Kann eine laufende Mission Ereignisse verlieren?

Weitere Ereignisse werden laut Famulor-Dokumentation pro Mission in Eingangsreihenfolge vorgemerkt, wenn bereits ein Run läuft. Zusätzlich werden Ereignis-Runs dedupliziert.

Bleiben alte Versionen nachvollziehbar?

Ja. Veröffentlichte Versionen sind unveränderlich. Änderungen und Wiederherstellungen erzeugen neue Entwürfe und schreiben die Historie nicht um.

Fazit: Ereignisgesteuerte Arbeit braucht einen Betriebsrahmen

Mission Studio macht aus Milian Missions mehr als wiederkehrende Aufgaben. Ereignisse können Arbeit unmittelbar anstoßen, während veröffentlichte Versionen, begrenzte Zugriffe, Run-Limits und Transcripts den Betrieb nachvollziehbar halten. Für den Einstieg empfiehlt sich ein enger, risikoarmer Prozess mit klarer Erfolgskontrolle. Aktiviere Workspace Beta Features, öffne Milian Missions und veröffentliche erst dann, wenn Trigger, Filter, Zugriff und Limits gemeinsam geprüft sind.