Zuletzt aktualisiert: 2026-11-02
KI-Observability in Slack gibt Deinen Agenten, Skripten und Automationen einen gemeinsamen Ort zum Berichten – was passiert ist, was nicht geklappt hat und was Deine Aufmerksamkeit braucht. Statt sieben verschiedene Tools zu prüfen, bekommst Du die wichtigen Updates dort, wo Du ohnehin kommunizierst.
Einen weiteren Workflow zu bauen wird immer einfacher. Den Überblick über alles, was im Hintergrund läuft? Das wird zunehmend eine eigene Aufgabe.
Etwas ist fertig, aber Du hast den Output noch nicht gesehen. Ein anderer Agent braucht Deine Eingabe. Eine Integration ist vor drei Wochen kaputtgegangen – und niemand hat es bemerkt.
Das fehlende Stück ist nicht immer ein weiterer Agent. Es ist ein Ort, an den die Agenten, die Du schon hast, zurückmelden können.
Genau das in meinem Setup einzurichten, war eine der größten Verbesserungen überhaupt. So kannst Du dasselbe tun. [1]
Video ansehen: Das fehlende Glied in Deinem KI-Setup
Warum brauchen KI-Workflows Observability?
Observability hilft Dir zu verstehen, was Deine Workflows tun – und zu erkennen, wenn etwas Deine Aufmerksamkeit braucht. Für einen pragmatischen Einstieg bedeutet das: die richtigen Informationen, in der richtigen Menge, zum richtigen Zeitpunkt.
Stell Dir vor, Du stellst morgen fünf Leute ein.
Du würdest ihnen klare Aufgaben geben und einen Ort zum Kommunizieren. Du würdest nicht erwarten, jeden Nachmittag an fünf verschiedene Schreibtische zu gehen, nur um herauszufinden, ob irgendjemand etwas fertig hat.
Deine Agenten und Skripte brauchen dieselbe grundlegende Struktur.
Für mich ist dieser Ort Slack. Nicht weil Slack zur Datenbank für alles werden soll, sondern weil dort ohnehin kommuniziert wird.
Ein nützlicher Reporting-Loop beantwortet drei Fragen:
- Was ist passiert? Der Workflow ist fertig, fehlgeschlagen oder braucht eine Entscheidung.
- Warum ist das relevant? Es gibt einen Output zu prüfen, ein Problem zu lösen oder einen nächsten Schritt.
- Wo geht es weiter? Die Nachricht zeigt Dir, wo Du nachschaust.
Slack-Benachrichtigungen sind kein Ersatz für detaillierte Logs oder tieferes Monitoring. Sie sind eine erste, einfache Ebene, die Hintergrundarbeit sichtbar macht.
Welche drei Wege gibt es, KI in Slack zu überwachen?
Du kannst einen Agenten nutzen, der direkt in Slack lebt, eine Agenten-Plattform mit eingebautem Slack-Connect verbinden oder eine kleine Reporting-App für eigene Tools bauen. Wahrscheinlich wirst Du am Ende eine Kombination nutzen.
| Ansatz | Passt am besten für | Setup-Aufwand | Hauptkompromiss |
|---|---|---|---|
| Slack-nativer Agent | Arbeit per Konversation delegieren | Gering: Service verbinden und Zugriff konfigurieren | Bequemlichkeit, weniger Einblick in die Implementierung |
| Agent mit Slack-Integration | Fokussierte Workflows in einer Plattform wie Notion | Mittel: Anweisungen, Trigger und Channel-Berechtigungen definieren | Explizitere Konfiguration innerhalb der Plattform-Grenzen |
| Eigene Slack-Reporting-App | Skripte, geplante Jobs und eigene Agent-Workflows | Initial höher: App erstellen und Reporting verdrahten | Mehr Kontrolle, Verantwortung für Sicherheit und Wartung |
Wann solltest Du einen Slack-nativen Agenten nutzen?
Ein Slack-nativer Agent macht Sinn, wenn Du Arbeit per Konversation delegieren willst, ohne die Implementierung selbst zu managen. Du schreibst ihm wie einem Teammitglied – und er meldet sich in Slack zurück.
Ein Beispiel aus meinem eigenen Setup ist der Every Agent. Ich nutze ihn für unkomplizierte delegierte Workflows, zum Beispiel um Notion-Updates zu sammeln und in einen Update-Channel zu liefern. [1]
Der Reiz ist einfach: Du beschreibst das gewünschte Ergebnis, statt jeden Schritt selbst zu bauen.
Der Kompromiss ist Kontrolle. Je nach Service hast Du möglicherweise wenig Einblick, wie er Informationen findet oder die Arbeit ausführt.
Das macht es nicht zur schlechten Wahl. Es macht es zur richtigen Wahl für Arbeit, bei der Bequemlichkeit wichtiger ist als Kontrolle über jeden einzelnen Schritt.
Wann solltest Du Notion Custom Agents nutzen?
Notion Custom Agents eignen sich gut, wenn Du einen fokussierten Workflow in Notion konfigurieren und Slack für Updates oder Interaktion nutzen willst. Du definierst Anweisungen, Trigger und Zugriffsrechte – statt die ganze Implementierung einem Allzweck-Assistenten zu überlassen.
Custom Agents können durch Slack-Channel-Nachrichten, Emoji-Reaktionen oder Erwähnungen ausgelöst werden. Sie können auch Nachrichten und Antworten in den Channels posten, die Du explizit erlaubst. [2]
Du könntest zum Beispiel einen Workflow aufbauen, der (und wenn Du mehrere Agenten zusammen betreibst, gibt Dir Multi-Agent-Orchestrierung in Notion die Koordinationsebene):
- Nach einem Meeting Action Items extrahiert und zur Prüfung vorschlägt.
- CRM-Follow-ups vorschlägt, bevor Du den nächsten Schritt freigibst.
- Einen kurzen Report schickt, nachdem Informationen in Notion aktualisiert wurden.
Das sind Workflows, die Du konfigurierst – keine automatischen Verhaltensweisen, die Du einfach durch das Verbinden von Slack bekommst.
Für persönliches Reporting ist ein dedizierter privater Channel eine sinnvolle Option. Gib dem Agenten Zugriff auf diesen Channel und leg fest, was er dort berichten soll.
Datenschutz beachten: Ein privater Slack-Channel macht die Aktivität des Agenten nicht automatisch privat. Notion weist darauf hin, dass Personen mit Zugriff auf den Agenten seine Outputs sehen können, auch wenn sie keinen Zugriff auf den privaten Slack-Channel haben. Prüfe beide Berechtigungen. [2]
Wann solltest Du eine eigene Slack-Reporting-App bauen?
Eine eigene Slack-App macht Sinn, wenn Deine Skripte oder Agent-Tools keine passende Reporting-Integration mitbringen. Sie gibt ihnen einen gemeinsamen Weg, Benachrichtigungen zu senden, ohne die Workflows selbst nach Slack zu verlagern.
Der entscheidende Unterschied: Slack meldet die Arbeit. Slack muss die Arbeit nicht ausführen.
Ein geplantes Skript kann weiter in seiner gewohnten Umgebung laufen. Dein Agent kann weiter seine gewohnten Tools nutzen. Du fügst nur einen kleinen Reporting-Schritt hinzu, wenn etwas Wichtiges passiert.
Wie funktioniert eine eigene Slack-Reporting-App?
Eine Reporting-App nutzt die Slack-API, um Nachrichten aus Deinen Workflows an ein autorisiertes Ziel zu senden. Eine App kann mehrere verwandte Workflows bedienen – Du brauchst also nicht für jedes Skript eine eigene Slack-App.
Grob sieht das Setup so aus:
- Eine Slack-App für Workflow-Reporting erstellen.
- Die benötigten Berechtigungen vergeben und die App im Workspace installieren.
- Sie zum gewünschten Reporting-Channel hinzufügen.
- Den Token sicher speichern und Deiner Laufzeitumgebung als Secret bereitstellen.
- Reporting zu den Workflows hinzufügen, die Du überwachen willst.
- Sowohl einen erfolgreichen Durchlauf als auch einen Fehler testen.
Für das Posten über chat.postMessage ist der Kernscope chat:write. Slack bietet separat chat:write.customize für angepasste Nachrichtennamen und Avatare, mit Feldern wie username, icon_emoji und icon_url. [3]
Nachrichten senden und ihr Erscheinungsbild anpassen sind separate Fähigkeiten. Das Aussehen einer Nachricht zu ändern erstellt keine separate Bot-Identität oder Berechtigungsgrenze.
Slack knüpft angepasste Autorschaft an Bedingungen, darunter Nutzerberechtigungen und eine auslösende Nutzeraktion. Eine feste Bot-Identität mit klarem Workflow-Label in der Nachricht ist ein einfacherer Ausgangspunkt. [3]
Bewahre den Token in einem Passwort-Manager oder Secrets-Store auf – nicht im Quellcode, in Prompts oder Slack-Nachrichten. Einen Token über mehrere Workflows zu teilen ist praktisch, aber diese Workflows teilen dann auch seine Zugriffsrechte.
Was sollten Deine KI-Workflows melden?
Starte mit Fehlern, Ergebnissen die ein Follow-up brauchen, und Erfolgsmeldungen, solange Du einem neuen Workflow noch vertraust. Du brauchst keine Benachrichtigung für jeden internen Schritt.
Welche Fehler brauchen einen Alert?
Melde Fehler, die das gewünschte Ergebnis verhindern oder menschliches Eingreifen erfordern. Die Nachricht sollte erklären, was schiefgelaufen ist, und Dich zum nächsten Schritt führen.
Der schmerzhafte Fehler ist nicht immer der dramatische Absturz. Es ist die stille Integration, die aufhört zu funktionieren, während alles andere weiterläuft.
Ein nützlicher Fehlerbericht enthält:
- Den Namen des Workflows.
- Was schiefgelaufen ist, in einfacher Sprache.
- Ob die Arbeit gestoppt oder nur teilweise abgeschlossen wurde.
- Wo Du nachschauen oder es erneut versuchen kannst.
Ein wichtiger Vorbehalt: Ein Workflow, der nie startet, kann keine eigene Fehlermeldung schicken. Für wichtige geplante Aufgaben brauchst Du möglicherweise einen separaten Check, ob ein erwarteter Durchlauf tatsächlich stattgefunden hat.
Wann sind Erfolgsmeldungen sinnvoll?
Erfolgsmeldungen sind sinnvoll, wenn es etwas zu prüfen gibt, eine weitere Aktion erforderlich ist oder Du das Verhalten eines neuen Workflows noch beobachtest.
Das ist Deine Trust Battery.
Wenn Du ein neues Teammitglied einarbeitest, schaust Du anfangs genau hin. Wenn sie sich als zuverlässig erweisen, gibst Du ihnen mehr Freiraum.
Dasselbe kannst Du mit Automationen tun: Starte mit sichtbaren Ergebnissen, reduziere dann die routinemäßigen Erfolgsmeldungen, sobald Du das Verhalten des Workflows verstehst. Halte wichtige Fehler und Anfragen für Input sichtbar.
Wie sieht das in der Praxis aus?
Die besten Reports spiegeln wider, was der Workflow tatsächlich tut – statt eine generische „Fertig”-Nachricht zu schicken.
In meiner eigenen Arbeit sind Beispiele:
- Ein Kunden-Wiki: Veröffentlichungsbenachrichtigungen helfen zu prüfen, ob neue Artikel korrekt gerendert wurden – ergänzt durch Fehler-Alerts.
- Ein Notion-Update-Publishing-Flow: Durchlaufberichte zeigen, welche Updates veröffentlicht und welche zusammengeführt wurden.
- Projekt-Onboarding: Leila, der Projektmanagement-Agent, meldet Setup-Arbeit wie Repositories, Slack-Channels und Einladungen. [1]
Du brauchst nicht überall denselben Detailgrad. Du brauchst genug Information, um zu wissen, ob Du handeln musst.
Warum mit einseitigen Slack-Benachrichtigungen starten?
Einseitiges Reporting gibt Dir Überblick, ohne Slack zur Fernsteuerung für Deine Tools zu machen. Es ist ein kleinerer erster Schritt als eine App zu bauen, die auch Anweisungen entgegennimmt und ausführt.
Eine Benachrichtigung kann Dich zurück zum relevanten System führen, wo Du nachschaust, freigibst oder die Arbeit neu startest.
Zweiseitige Kommunikation wirft Fragen auf, die Du beantworten musst:
- Wer darf Befehle geben?
- Welche Aktionen kann eine Antwort auslösen?
- Wie unterscheidest Du eine Anweisung von normalem Gespräch?
- Welche Aktionen brauchen explizite Freigabe?
Das kannst Du später ergänzen. Du brauchst es nicht, nur um aufzuhören, im Dunkeln zu tappen.
Halte die Rollen klar: Slack ist die Kommunikationsebene. Notion ist der Ort für Aufgaben, Projektstatus und dauerhaftes Wissen. Wenn Du einen praktischen Rahmen für die Wissensebene suchst, zeigt Dir einen Notion-Wissensagenten bauen einen Weg.
Ein Report sollte Dir helfen, die Arbeit zu finden – nicht der einzige Nachweis sein, dass die Arbeit existiert.
Wie integrierst Du Reporting in Dein nächstes Build?
Mach Reporting zu einem Teil Deiner Definition of Done. Bevor Du einen Workflow als fertig bezeichnest, entscheide: Wo meldet er Fehler? Welche Ergebnisse brauchen Aufmerksamkeit? Wie testest Du, dass diese Nachrichten ankommen?
Du kannst Deinem Coding-Agenten eine wiederverwendbare Anweisung oder einen Skill mitgeben, damit Du Dir dasselbe Setup nicht jedes Mal neu ausdenken musst.
Der Prompt in meinem Subscriber Hub führt Dich durch das Erstellen der Slack-App, das sichere Speichern des Tokens und das Einrichten eines wiederverwendbaren Notion-KI-Skills für zukünftige Builds. [1]
👉 Hol Dir den Observability-Setup-Prompt im Subscriber Hub
Wenn Du 41 kostenlose Notion-Ressourcen dazu willst, schau im MF Consulting Subscriber Hub vorbei.
Fang mit einem Workflow an, den Du gerade noch manuell kontrollierst. Gib ihm einen Ort zum Berichten. Und mach das dann zum Standard für alles, was Du als nächstes baust.
Häufig gestellte Fragen
Was ist KI-Observability in Slack?
KI-Observability in Slack bedeutet, nützliche Updates über Deine Agenten, Skripte und Automationen in Slack zu erhalten. Diese Updates sagen Dir, was fertig ist, was schiefgelaufen ist und was Deine Eingabe braucht. Es ist eine praktische Kommunikationsebene – kein Ersatz für Logs oder tieferes Monitoring.
Brauchst Du eine eigene Slack-App, um KI-Agenten zu überwachen?
Nein. Ein Slack-nativer Agent oder eine Agenten-Plattform mit eingebauter Slack-Integration bietet möglicherweise bereits das Reporting, das Du brauchst. Eine eigene App ist sinnvoll, wenn Du Benachrichtigungen zu Skripten oder Tools hinzufügen willst, die keine passende eingebaute Option haben.
Können Notion Custom Agents an einen privaten Slack-Channel berichten?
Ja. Notion Custom Agents können ausgewählte private Channels lesen und beschreiben, wenn die entsprechenden Verbindungen und Berechtigungen konfiguriert sind. Prüfe auch die Agent-Freigaben: Personen mit Zugriff auf den Agenten können seine Outputs möglicherweise sehen, auch ohne Zugriff auf den Slack-Channel. [2]
Muss jeder erfolgreiche Workflow-Durchlauf eine Benachrichtigung senden?
Nicht unbedingt. Erfolgsmeldungen sind besonders nützlich beim Testen, beim Onboarding oder wenn das Ergebnis ein Follow-up braucht. Mit wachsendem Vertrauen kannst Du Routine-Nachrichten reduzieren und wichtige Fehler und Anfragen für Input sichtbar halten.
Kann eine Slack-App für mehrere Workflows melden?
Ja. Mehrere Workflows können eine Reporting-App nutzen und sich in ihren Nachrichten identifizieren. Bedenke, dass Workflows mit demselben Token auch dessen Zugriffsrechte teilen – eine gemeinsame App ist also nicht automatisch die richtige Sicherheitsgrenze für unabhängige Systeme.
