Agenten

Was sind Agenten?

Ein Agent ist ein persistenter digitaler Kollege: eigene Identität (Name, Emoji, Beschreibung), eigene Wissensdatei (AGENTS.md), eigene Referenz-Dateien und eine eigene Kostenbegrenzung. Du kannst einen Agenten per Chat ansprechen (interaktive Runs) oder ihn autonom laufen lassen (zeitgesteuert per Cron oder als Reaktion auf einen Webhook).

Im Unterschied zu den früheren Assistenten bleibt ein Agent zwischen Sitzungen “wach”:

• Er lernt dazu, indem er seine eigene AGENTS.md editiert
• Er kann mehrere parallele Threads führen
• Er hat eine eigene Run-Historie (was hat er wann getan, was hat es gekostet)
• Er kann ohne deine Anwesenheit Arbeit erledigen, innerhalb klarer Leitplanken

Hinweis: Agenten sind in der Business- und Max-Lizenz enthalten. Bestehende Assistenten wurden automatisch zu Agenten migriert, Konfiguration, Freigaben und Dateien bleiben erhalten.

Agenten-Homebase

Du erreichst deine Agenten über die Seitenleiste → Agenten. Pro ausgewähltem Agent siehst du eine dreispaltige Ansicht:

• Mitte: Der aktuell ausgewählte Thread oder Run, mit Chat-Eingabe darunter
• Rechts (Kontext-Panel): Status, Auslastung der Kostenbegrenzung, Trigger-Block (Cron-Plan oder Webhook-URL), aktivierte Integrationen, gesamte Run-Historie
• Links: Navigation zwischen Chat, Projekten, Agenten, Suche und Einstellungen

Über den Button „Agent konfigurieren” im Kontext-Panel öffnest du die Vollseiten-Konfiguration mit allen Tabs (siehe unten).

Einen Agenten erstellen

Klicke im Agenten-Tab auf „Neuer Agent”. Es öffnet sich ein normaler Chat mit der Anfangsnachricht „Ich möchte einen neuen Agent erstellen”. Die KI klärt die offenen Punkte mit dir:

1. Rolle: was soll der Agent tun, woran erkennt er gute Arbeit?
2. Name & Emoji: wie heißt er, wie erkennst du ihn auf einen Blick?
3. Trigger: Chat-only, Cron-Plan, Webhook-Endpunkt, oder Kombination?
4. Integrationen: auf welche deiner Tools soll der Agent zugreifen dürfen?
5. Freigabe: wer soll den Agenten nutzen dürfen, und mit welcher Rolle (verwenden, bearbeiten, administrieren)?

Du kannst auch direkt loslegen: „Erstelle einen Agenten, der jede Stunde meine Mails prüft”, die KI fragt nur die Lücken nach. Alle Angaben landen am Ende in der AGENTS.md des Agenten und können dort später frei editiert werden.

Konfiguration im Detail

Über „Agent konfigurieren” erreichst du sechs Tabs: Allgemein, Anweisungen, Datei-Anhänge, Werkzeuge & Zugänge, Trigger und KI-Modell. Die Freigabe, das Duplizieren und die Gefahrenzone sitzen im Tab Allgemein.

Welche Tabs du siehst, hängt von deiner Rolle ab: Wer den Agenten nur verwenden darf, sieht Allgemein, Anweisungen und KI-Modell. Datei-Anhänge und Werkzeuge & Zugänge kommen mit dem Recht zum Bearbeiten dazu, Trigger nur mit dem Recht zum Administrieren.

Tab: Allgemein

Name, Beschreibung, Emoji und der Schalter „Agent aktiv” zum manuellen Pausieren bzw. Fortsetzen. Bei automatisch pausierten Agenten (Kostenbegrenzung erreicht, drei Fehler in Folge) wird der Grund hier angezeigt.

Den Schalter bedienen der Besitzer, alle mit der Rolle „Agent administrieren” und Workspace-Administratoren. Wer den Agenten nur bearbeiten darf, sieht den Status samt Grund, kann ihn aber nicht umlegen: Einen Agenten stillzulegen oder wieder scharf zu schalten wirkt auf alle, die ihn nutzen.

Weiter unten im selben Tab stehen die Freigabe (siehe Teilen: wer darf was?), die Schaltfläche zum Duplizieren und die Gefahrenzone zum endgültigen Löschen. Die Gefahrenzone erscheint nur, wenn du den Agenten administrieren darfst. Den Besitzer siehst du hier immer, auch wenn du den Agenten nur verwenden darfst.

Tab: Anweisungen

Hier steht die AGENTS.md des Agenten, seine natürlichsprachige Wissens- und Verhaltensdatei. Du kannst sie direkt bearbeiten (Inline-Markdown-Editor) oder den Agenten im Chat bitten, etwas zu ergänzen. Beide Wege schreiben in dieselbe Datei. Speicherung passiert automatisch beim Verlassen des Editors.

Über „Versionshistorie anzeigen” siehst du alle vorherigen Versionen mit Timestamp, einem Diff-Vergleich zwischen zwei Versionen deiner Wahl und einem Restore-Button. Die Versionshistorie wird automatisch für 90 Tage geführt.

Tipp: Die AGENTS.md ist natürliche Sprache, keine Programmierung, kein Pseudocode. Beschreibe Logik in Prosa: „Wenn eine neue Mail von einem bekannten Kunden kommt, fasse sie zusammen und schlage eine Antwort vor.”

Tab: Datei-Anhänge

Referenz-Dateien, die der Agent bei jedem Run „im Kopf hat” (max. 25 Dateien). Praktisch für Tone-of-Voice-Dokumente, Styleguides, Vorlagen, Preislisten. Mehr Details im Abschnitt Dateien & Wissen pro Agent.

Tab: Werkzeuge & Zugänge

Hier stehen die Zugänge: die Konten, mit denen der Agent arbeitet, jeweils mit Anbieter, Adresse des Kontos und der Person, die es beigesteuert hat. Du wählst das Konto aus, die zugehörigen Werkzeuge kommen mit, du musst nichts doppelt ankreuzen. Gruppiert ist die Liste nach Beisteuernden, deine eigenen Konten stehen oben. Jedes Konto erscheint genau einmal, auch wenn es auf mehreren Wegen angebunden wurde.

Ein Satz über der Liste sagt dir, woran der Agent gerade ist: Ist kein Konto eingeschaltet, arbeitet er mit den Konten der Person, die ihn gerade benutzt. Ist mindestens eines eingeschaltet, arbeitet er nur noch damit. Ausführlich unter Zugänge: Mit welchen Konten ein Agent arbeitet.

Diesen Tab bedient jeder, der den Agenten bearbeiten darf, also auch Empfänger mit der Rolle „Agent bearbeiten”. Einschalten kannst du dabei nur Konten, die dir selbst gehören: Ein fremdes Konto lässt sich nicht in einen Agenten hineinlegen. Wer ein Konto beisteuert, steht danach in der Liste dabei.

Tab: Trigger

Cron-Plan und/oder Webhook konfigurieren. Details im Abschnitt Trigger weiter unten.

Oben im Tab steht, wer die so ausgelösten Läufe bezahlt: Sie gehen auf das Guthaben des Workspaces, nicht auf dein persönliches Kontingent. Ist das Guthaben leer, wird daraus eine Warnung, und Administratoren finden dort direkt den Weg zum Nachkaufen. Mehr dazu unter Was zählt als Verbrauch des Agenten?.

Diesen Tab sehen nur der Besitzer, alle mit der Rolle „Agent administrieren” und Workspace-Administratoren. Grund: Ein Auslöser lässt den Agenten unbeaufsichtigt mit den Konten aus seiner Kontenliste arbeiten, das ist eine Entscheidung über fremde Zugänge und nicht bloß eine inhaltliche Änderung.

Tab: KI-Modell

• Basis-Modell: das KI-Modell, das der Agent standardmäßig nutzt
• Erlaubte Modelle: optionale Whitelist (z. B. nur sparsame Modelle für High-Volume-Crons)
• Monatliche Kostenbegrenzung: Sicherheitsnetz, das verhindert, dass ein Agent mehr Kontingent verbraucht als gewollt. Voreingestellt sind €10/Monat; den Wert kannst du pro Agent jederzeit erhöhen oder absenken
• Frühwarnung bei Auslastung: Mail an Owner/Admin bei z. B. 80 % Verbrauch

Details: Kostenbegrenzung pro Agent.

Teilen: wer darf was?

Im Tab Allgemein legst du fest, wer den Agenten sieht und was er damit tun darf. Die Freigabe ist eine Liste mit einer Zeile je Person oder Gruppe, rechts daneben ein Auswahlfeld für die Rolle. Steht niemand in der Liste, hast nur du Zugriff.

Über „Gruppe oder Person hinzufügen …” öffnest du die Auswahl. Sie zeigt dir sofort alle vorhandenen Gruppen und Personen, nach Art gruppiert; du musst also nichts eintippen, sondern nur auswählen. Tippen filtert die Liste, wenn du gezielt nach einem Namen suchst. Einträge, die schon Zugriff haben, sind ausgegraut und mit „Bereits vergeben” markiert. Bei sehr vielen Einträgen zeigt die Liste je Bereich nur die ersten an und weist dich darauf hin, die Suche einzugrenzen.

Sollen alle im Workspace Zugriff bekommen, wähle in der Liste den Eintrag „Alle Mitglieder”. Das ist die Systemgruppe, die jedes Mitglied deines Workspace umfasst, du musst also nicht jede Person einzeln eintragen.

Du kannst die Freigabe auch im Chat aussprechen, während der Assistent den Agenten baut: „gib ihn für alle frei” genügt. Bestimmte Personen kann der Assistent nur eintragen, wenn er sie aus einer vorherigen Freigabe schon kennt; ansonsten nimmst du dafür die Liste in diesem Tab.

Jede Zeile bekommt genau eine von drei Rollen:

Rolle	Was damit möglich ist
Agent verwenden	Darf den Agenten im Chat aufrufen und ausführen, aber nichts an ihm ändern.
Agent bearbeiten	Darf zusätzlich Anweisungen, Datei-Anhänge sowie Werkzeuge und Zugänge des Agenten ändern.
Agent administrieren	Darf zusätzlich Freigaben ändern, den Besitzer wechseln, Auslöser einrichten, den Agenten pausieren oder fortsetzen und ihn löschen.

Bestehende Freigaben funktionieren unverändert weiter, du musst nichts nachziehen. Zwei Dinge ändern sich:

• Löschen ist kein Bearbeiten mehr. Wer einen geteilten Agenten bisher bearbeiten durfte, darf ihn weiterhin bearbeiten, ihn aber nicht mehr löschen. Löschen gehört jetzt zu Agent administrieren.
• Workspace-Administratoren bearbeiten nicht mehr automatisch mit. An fremden Agenten bekommen sie keine Bearbeitungsrechte mehr von allein. Wollen sie etwas ändern, tragen sie sich selbst als Bearbeiter in die Liste ein, und dieser Eintrag ist für alle in der Liste sichtbar.

Die Administration behalten Workspace-Administratoren dagegen vollständig, auch bei Agenten, die ihnen nicht gehören: Freigabe ändern, Besitzer wechseln, automatische Auslöser einrichten, den Agenten pausieren oder fortsetzen und ihn löschen.

Zu sehen bekommen sie deswegen aber nicht mehr: In der Agenten-Liste und im Chat steht nur, was ihnen gehört oder freigegeben wurde. Ein persönlicher Agent einer Kollegin taucht dort nicht auf, auch nicht, wenn die KI im Gespräch nach deinen Agenten gefragt wird.

Wenn du einen bisher rein persönlichen Agenten das erste Mal freigibst, fragt dich ein Dialog, ob er deine Zugänge mitnehmen soll. Voreingestellt ist ohne, dann arbeitet im Chat jeder mit seinen eigenen Konten. Siehe Zugänge: Mit welchen Konten ein Agent arbeitet.

Über der Zugriffsliste steht der Besitzer des Agenten, mit Namen und E-Mail-Adresse. Den siehst du immer, auch wenn du den Agenten nur nutzen darfst, so weisst du sofort, wen du ansprechen musst. Ein Agent behält seinen Besitzer dauerhaft, auch wenn du ihn für den gesamten Workspace freigibst.

Besitzer wechseln: Der Besitzer, alle mit der Rolle „Agent administrieren” und Workspace-Administratoren können den Agenten über die Schaltfläche „Besitzer wechseln” an eine andere Person übergeben. Der Dialog listet die Personen deines Workspace direkt auf: Person auswählen, fertig, sie hat ab sofort alle Rechte des Besitzers. Tippen musst du nur, wenn du die Liste eingrenzen willst.

Wer den Agenten ursprünglich erstellt hat, steht danach nicht mit leeren Händen da: Das Recht, den Agenten zu bearbeiten (Anweisungen, Datei-Anhänge, Werkzeuge und Zugänge), bleibt dauerhaft beim Ersteller. Was wegfällt, ist die Administration, also Freigabe ändern, Besitzer wechseln, Auslöser einrichten, pausieren und löschen. Typische Fälle: Du wechselst die Rolle und gibst deinen Agenten ab, oder ein Administrator ordnet einen viel genutzten Agenten einer neuen zuständigen Person zu.

Agenten löschen

Ganz unten im Tab Allgemein liegt die Gefahrenzone, dort löschst du einen Agenten endgültig. Der Bereich erscheint nur für den Besitzer, für Personen mit der Rolle „Agent administrieren” und für Workspace-Administratoren. Wer den Agenten bearbeiten darf, sieht ihn nicht.

Einen geteilten Agenten ausblenden

Wenn dir jemand einen Agenten freigibt, den du nicht brauchst, kannst du ihn für dich ausblenden. Der Befehl sitzt in der Agentenliste in der linken Seitenleiste, im Abschnitt „Geteilt mit mir”: Fahre mit der Maus über den Agenten, rechts erscheint ein Augen-Symbol mit dem Befehl „Für mich ausblenden”. Für deine eigenen Agenten (Abschnitt „Meine Agenten”) gibt es den Befehl nicht, ausblenden kannst du nur, was dir jemand anderes freigegeben hat.

Was danach gilt:

• Der Agent verschwindet aus deinen Listen und wird der KI im Chat nicht mehr angeboten
• Für den Besitzer und alle anderen ändert sich nichts, der Besitzer bekommt darüber auch keine Nachricht
• Der Agent bleibt ausgeblendet, auch wenn er dir später erneut freigegeben wird
• Unten in derselben Seitenleiste erscheint der Abschnitt „Ausgeblendet”, dort holst du ihn jederzeit wieder zurück

Ausblenden räumt also nur deine eigene Ansicht auf, es ist keine Änderung an der Freigabe. Wenn du gar keinen Zugriff mehr haben möchtest, sprich den Besitzer an.

Threads: mehrere Konversationen pro Agent

Mit einem Agenten führst du beliebig viele parallele Threads, wie in Teams oder Slack mit einem Kollegen. Jeder Thread hat einen automatisch generierten Titel und eine eigene Historie. Der Agent kennt den Kontext pro Thread, aber seine Wissensdatei (AGENTS.md) und Identität gelten thread-übergreifend.

• Geteilte Agenten: Threads sind pro Nutzer privat, wenn du und ein Kollege denselben Agenten nutzen, seht ihr jeweils nur eure eigenen Threads.
• Autonome Runs (Cron, Webhook) sind ausgenommen, die sehen alle Nutzer mit Zugriff, weil sie kein menschliches Gegenüber haben. Wer Zugriff auf den Agenten hat, kann den Verlauf eines solchen Laufs wie jeden anderen Chat teilen (per Link oder gezielt mit Personen), siehe Chat teilen.

Trigger: wann läuft der Agent?

Ein Agent läuft auf vier mögliche Auslöser:

Chat-Trigger

Du schreibst dem Agenten, der klassische Fall. Der Agent bekommt zusätzlich deinen persönlichen Kontext (Name, Sprache, Zeitzone, Du-/Sie-Form).

Welche Konten er dabei benutzt, hängt an seiner Kontenliste: Ist dort nichts eingeschaltet, arbeitet er mit deinen Konten, also zum Beispiel in deinem Postfach. Ist mindestens ein Konto eingeschaltet, arbeitet er nur mit diesen, auch wenn du ihn fragst. Details unter Zugänge: Mit welchen Konten ein Agent arbeitet.

Cron-Trigger (Zeitplan)

Der Agent läuft regelmäßig, z. B. stündlich, jeden Montag um 09:00 oder am 1. jedes Monats. Pro Agent ist ein Cron-Plan möglich, in IANA-Zeitzonen (z. B. Europe/Berlin); Sommerzeit-Umstellungen werden korrekt behandelt.

Optional kann ein Guard-Script vorgeschaltet werden, ein kleiner Vorfilter, der ohne KI-Aufruf prüft, ob überhaupt Arbeit anliegt. Beispiele: „Sind seit dem letzten Lauf neue Mails reingekommen?”, „Hat sich die Webseite verändert?”, „Liegen offene Tickets im CRM?”

Wenn der Guard nichts findet, läuft kein KI-Run, keine Kosten, keine leere Mail-Zusammenfassung. Wenn er etwas findet, übergibt er das Ergebnis direkt an den Agenten und der startet mit dem passenden Kontext.

Das Guard-Script arbeitet mit denselben Zugängen wie der Agent selbst. Jedes eingeschaltete Konto steht ihm als Umgebungsvariable zur Verfügung, und die Datei /home/user/.credentials listet auf, welches Konto hinter welcher Variable steckt. Hat dein Agent mehrere Konten desselben Anbieters, zum Beispiel zwei Microsoft-365-Postfächer, musst du im Script über diese Variable sagen, welches gemeint ist: Ohne diese Angabe kann die Plattform nicht raten und bricht ab.

So sparst du bei stündlichen oder häufigeren Triggern messbar Kontingent und verhinderst, dass der Agent über unveränderte Daten Bericht erstattet.

Webhook-Trigger

Jeder Agent bekommt auf Wunsch eine eindeutige HTTPS-URL, die externe Systeme (CRM, Monitoring, eigene Anwendungen) aufrufen können, um einen Run anzustoßen. Die gültige URL steht im Tab Trigger und wird dort zum Kopieren angezeigt. Sie hat die Form https://chat.9brains.de/api/v1/agents/{agent-id}/webhook, setze sie aber nie von Hand zusammen, sondern kopiere sie aus der Oberfläche.

Konfigurierbar:

• Authentifizierung: Bearer-Token (Standard), HMAC-Signatur mit Timestamp-Schutz, oder offen (nur für Test-Setups)
• Antwortmodus: Fire-and-forget (sofort HTTP 202, Run läuft im Hintergrund) oder Synchron mit Timeout (das aufrufende System wartet auf das Ergebnis, Standard 30 Sekunden, maximal 120)
• Rate-Limit: Standard 60 Anfragen/Minute, anpassbar
• Guard-Script: wie beim Cron-Trigger, optional

Token und Secrets werden einmalig im Klartext angezeigt und können jederzeit rotiert werden.

Was der Agent von der Anfrage mitbekommt

Rufe die URL per POST auf und schicke alles, was der Agent wissen soll, im Body mit. Meist ist das JSON, es geht aber genauso Text, XML oder CSV. Der Inhalt landet unverändert im Kontext des Agenten, bis 1 MB vollständig, größere Inhalte gekürzt und zusätzlich als Datei in seinem Posteingang. Bilder, PDFs und andere Binärdateien kommen nie in den Kontext, sondern immer als Datei.

Der Body ist damit der Weg, dem Agenten Parameter mitzugeben. Beschreibe in der AGENTS.md, welche Felder du schickst und was er damit tun soll, dann kann er sie zuverlässig auswerten.

Zusätzlich sieht der Agent die verwendete HTTP-Methode und einige Kopfzeilen der Anfrage (Content-Type, User-Agent, X-Source). Ein Guard-Script bekommt darüber hinaus die vollständige Anfrage inklusive aller Kopfzeilen.

Was nicht ankommt: An die URL angehängte Parameter wie ?kunde=Meier werden verworfen, der Agent sieht sie nicht. Ein Aufruf per GET liefert ihm deshalb überhaupt keinen Inhalt. Verwende POST mit Body.

Inhalte aus Webhooks behandelt der Agent grundsätzlich als Information und nicht als Anweisung, siehe den Abschnitt Sicherheit & Datensouveränität weiter unten.

Manueller Trigger

In der Agenten-Homebase gibt es den Button „Ausführung jetzt starten”, startet den Agenten so, als wäre er per Cron oder Webhook ausgelöst worden. Inkl. Guard-Script. Praktisch für Tests.

Achtung: Manuelle Test-Runs haben dieselben Seiteneffekte wie echte Runs, wenn der Agent normalerweise Mails versendet, tut er das auch beim Test.

Zugänge: Mit welchen Konten ein Agent arbeitet

Ein Agent hat nur dann eine eigene Kontenliste, wenn ihm jemand Konten gegeben hat. Die Liste steht im Tab Werkzeuge & Zugänge. Pro Konto gibt es genau zwei Möglichkeiten: Es ist eingeschaltet, weil eine Person es bewusst hergegeben hat, oder es steht nicht auf der Liste. Halbe Zustände, etwa ein Eintrag, der noch auf eine Bestätigung wartet, entstehen nicht mehr.

Eine getrennte „autonome Freigabe” gibt es ebenfalls nicht mehr. Ein eingeschaltetes Konto ist die Freigabe, für den Chat und für automatische Läufe gleichermaßen.

Solange der Agent nur dir gehört

Du musst nichts einrichten. Ein Agent, den du noch nie geteilt hast, folgt deinen Zugängen. Legst du eine neue Verbindung an, steht sie ihm ohne Zutun zur Verfügung.

Beim Teilen wirst du gefragt: mit deinen Zugängen oder ohne

Teilst du einen bisher persönlichen Agenten das erste Mal, fragt dich ein Dialog, ob er deine Zugänge mitnehmen soll. Er zeigt dir dabei, um welche Konten es ginge:

• Ohne meine Zugänge (die Voreinstellung): Es wird kein Konto eingetragen, der Agent startet ohne Kontenliste. Im Chat arbeitet dann jeder mit seinen eigenen Konten, bei automatischen Läufen hat der Agent keine.
• Mit meinen Zugängen: Deine eigenen Konten kommen auf die Liste. Jede Person, die den Agenten danach benutzt, arbeitet damit unter deinem Namen und in deinen Daten, also zum Beispiel in deinem Postfach.

Wie du dich auch entscheidest, von allein wächst die Liste danach nicht mehr: Legst du später eine neue Verbindung an, bekommt der geteilte Agent sie nicht automatisch dazu. Ändern kannst du die Liste jederzeit im Tab Werkzeuge & Zugänge.

Ist kein Konto eingeschaltet, folgt der Agent seinem Gegenüber

Eine leere Liste wirkt im Chat wie gar keine Liste: Der Agent arbeitet mit den Konten der Person, die ihn gerade bedient. Fragst du ihn nach deinen Mails, schaut er in dein Postfach; fragt deine Kollegin, schaut er in ihres. Das ist der passende Zustand für Agenten, die jeder für seine eigene Arbeit benutzen soll, etwa einen Schreib-Assistenten fürs eigene Postfach.

Bei automatischen Läufen über Zeitplan oder Webhook gilt das nie. Dort sitzt niemand davor, dessen Konten gelten könnten, also bekommt der Agent auch keine. Ein Agent, der ohne dich arbeiten soll, braucht deshalb mindestens ein eingeschaltetes Konto.

Ein eingeschaltetes Konto genügt, und nur noch die Liste zählt

Sobald ein einziges Konto eingeschaltet ist, arbeitet der Agent ausschließlich damit, und zwar für alle, die ihn nutzen, im Chat genauso wie bei automatischen Läufen. Er ist dann wie ein Kollege mit eigenem Schlüsselbund: Fragst du ihn nach deinen Mails, schaut er in das Postfach aus seiner Liste, nicht in deins.

Das ist auch der Grund, warum beim Einschalten nachgefragt wird. Wer ein eigenes Konto hergibt, gibt es allen, die den Agenten benutzen dürfen.

Ein Konto beisteuern

Beisteuern kannst du nur Konten, die dir selbst gehören. Ein fremdes Konto lässt sich nicht in einen Agenten hineinlegen, auch nicht von einer Administratorin. Es gibt genau zwei Wege, und beide fragen dich vorher:

• Agent → Werkzeuge & Zugänge: Du schaltest ein Konto ein.
• Einstellungen → Sicherheit → Verbindungen: Du wählst bei einer Verbindung unter Zugriff einen Agenten aus.

In beiden Fällen erscheint derselbe Dialog. Er nennt namentlich, wer diesen Agenten nutzen darf (Personen und Gruppen, nicht bloß eine Anzahl) und sagt, dass der Agent auch ohne dich arbeitet: im Chat anderer Personen und bei automatischen Läufen. Läuft für den Agenten bereits ein Zeitplan, steht das ausdrücklich dabei. Erst wenn du zustimmst, bekommt der Agent das Konto.

Deine Zustimmung wird gespeichert: wer zugestimmt hat, wann, für welchen Agenten, für welches Konto, und wer den Agenten zu diesem Zeitpunkt nutzen durfte. Bei einer Prüfung ist das die Antwort auf die Frage, warum ein Agent an dein Postfach durfte.

Ein Konto wieder auszuschalten braucht keine Zustimmung, dabei wechselt ja nichts den Besitzer. Wer den Agenten administrieren darf, kann außerdem ein fremdes Konto von der Liste nehmen, aber nie eines einschalten. Zurückholen kann es danach nur die Person, der das Konto gehört; deshalb warnt dich ein Hinweis, bevor du das tust.

Aus dem Chat heraus geht das nicht. Bittest du den Assistenten, einem geteilten Agenten ein Konto zu geben, lehnt er ab und verweist auf den Tab Werkzeuge & Zugänge. Eine Zustimmung muss von einem Menschen kommen, der den Empfängerkreis gesehen hat.

Mehrere Konten desselben Anbieters

Das ist ausdrücklich erlaubt. Jedes Konto steht als eigene Zeile mit seiner Adresse in der Liste, damit du zwei Google-Konten auseinanderhalten kannst. Kommen für eine Aufgabe mehrere Konten infrage, wählt der Agent nie stillschweigend eines aus, sondern benennt das verwendete.

Dasselbe Konto erscheint dabei genau einmal. Früher konnte eine Anmeldung doppelt in der Liste stehen, einmal als Integration und einmal als Verbindung, mit zwei Schaltern, von denen das Ausschalten des einen nichts bewirkte.

Hinweis für ältere Agenten: Konten, die ein Agent nicht durch eine bewusste Entscheidung bekommen hat, sondern automatisch, nutzt er nicht mehr. Im Chat fällt das nicht auf, dort folgt er der Person, die ihn bedient. Ein Agent mit Zeitplan braucht dagegen mindestens ein eingeschaltetes Konto: Schau im Tab Werkzeuge & Zugänge nach und schalte das Konto ein, mit dem er arbeiten soll. Alte Einträge, die nie jemand bestätigt hat, sind dort als nicht in Benutzung gekennzeichnet.

Was der Agent in SharePoint und auf dem Fileserver findet

Für Datenquellen mit Rechteprüfung gilt dieselbe Regel wie für die Konten: Ein Agent findet immer nur die Dateien, die ein bestimmter Mensch sehen darf. Im Chat ist das die Person, die ihn gerade bedient. Steht ein Microsoft-Konto auf seiner Liste, sind es die Rechte dieses Kontos, im Chat wie bei automatischen Läufen. Läuft er nach Zeitplan oder über einen Webhook, ohne dass ein Microsoft-Konto eingeschaltet ist, sind es die Rechte seines Besitzers.

Damit findet ein Agent auch nachts das, was er tagsüber findet, ohne dass jemand die Rechteprüfung an der Datenquelle abschalten muss.

Dateien & Wissen pro Agent

Jeder Agent bringt drei Sorten Inhalte mit, die über alle Runs hinweg erhalten bleiben:

• Wissensdatei AGENTS.md: Rolle, Anweisungen und alles, was der Agent über seine Aufgabe gelernt hat. Du und der Agent könnt sie editieren; jede Änderung wird versioniert (90 Tage Historie).
• Referenz-Dateien: Dokumente, die der Agent bei jedem Run „im Kopf hat” (Tone-of-Voice, Styleguides, Vorlagen, Preislisten). Max. 25 Dateien pro Agent. Verwaltung im Tab Datei-Anhänge.
• Run-Ergebnisse: Artefakte, die der Agent während eines Runs erzeugt (Berichte, Exporte, Mail-Entwürfe). Pro Run getrennt abgelegt und in der Run-Historie verlinkt.

Verschlüsselung: Alle Inhalte werden client-seitig verschlüsselt gespeichert (Client-Side Encryption mit per-Tenant-Schlüsseln), selbst Betreiber der Plattform können den Klartext nicht lesen. Dieselbe Verschlüsselung gilt auch für Chat-Anhänge.

Run-Historie

Im rechten Kontext-Panel siehst du alle Runs des Agenten, Chat-Runs, Cron-Runs, Webhook-Runs und manuelle Test-Runs, in chronologischer Reihenfolge mit Gruppierung nach Heute / Gestern / Letzte 7 Tage / Älter.

Pro Eintrag zeigt das Label, was den Run ausgelöst hat: „Du · 09:30”, „Cron · 08:00”, „Webhook · 11:17”. In einen Run hineingeklickt siehst du den vollständigen Verlauf inkl. aller Tool-Aufrufe, das Ergebnis und die Kosten.

Administratoren können für jeden einzelnen Tool-Aufruf bis zum auslösenden Run zurückspringen, die Antwort auf “Warum hat der Agent gestern um 03:00 diese Mail an den Kunden geschickt?” liegt damit immer einen Klick entfernt.

Einen laufenden Run stoppen

Solange ein Run noch läuft, steht auf seiner Seite der Knopf „Run stoppen”. Er hält den Agenten auch dann wirklich an, wenn dieser im Hintergrund per Zeitplan oder Webhook gestartet wurde. Der Run wird als abgebrochen verbucht, und die bis dahin angefallenen Kosten stehen wie gewohnt im Verlauf. Den Knopf sieht, wer den Agenten bearbeiten darf.

Was der Agent bis zum Stopp bereits getan hat, bleibt getan: eine verschickte Mail kommt dadurch nicht zurück. Ein gestoppter Run gilt nicht als Fehlschlag und bringt den Agenten deshalb auch nicht näher an die automatische Pause nach mehreren Fehlern.

Kostenbegrenzung pro Agent

Damit ein Agent, gerade ein autonom laufender, niemals unbemerkt davonläuft, hat jeder Agent eine eigene monatliche Kostenbegrenzung als Sicherheitsnetz. Wird sie erreicht, pausiert der Agent automatisch und du wirst per Mail informiert. So weißt du immer, was du maximal pro Monat ausgibst, bevor jemand eingreift.

Voreingestellt sind €10/Monat, was für die meisten Anwendungsfälle (Postfach-Check, SEO-Watch, gelegentlicher Chat) komfortabel ist. Den Wert kannst du pro Agent jederzeit anpassen, nach oben, wenn dein Agent mehr leisten soll, nach unten, wenn du noch enger absichern willst. Administratoren können den Wert für jeden Agenten im Workspace überstimmen.

Zusätzlich gibt es:

• Frühwarnung bei Auslastung: Mail an Owner und Admin bei z. B. 80 % des autonomen Verbrauchs
• Erlaubte Modelle: Whitelist pro Agent (z. B. nur sparsame Modelle), um Premium-Modelle für High-Volume-Crons auszuschließen
• Auto-Pause nach drei Fehlern in Folge: verhindert, dass ein konfigurationsbedingter Fehler unbemerkt Kontingent aufzehrt

Was zählt als Verbrauch des Agenten?

In der Seitenleiste des Agenten und in der Admin-Übersicht steht der autonome Verbrauch: Zeitplan, Webhook und über „Jetzt ausführen” gestartete Läufe, samt der dabei entstehenden Subagenten. Chat zählt dort nicht mit.

Die Trennung geht bis auf die einzelne Nachricht. Wenn du einen Faden öffnest, den ein Zeitplan-Lauf erzeugt hat, und dort selbst weiterschreibst, dann bleibt der autonome Teil beim Agenten und dein geschriebener Teil zählt als dein eigener Verbrauch. Wer tippt, zahlt für das, was er getippt hat, unabhängig davon, wie der Faden entstanden ist.

Die Kostenbegrenzung rechnet mit derselben Zahl, also nur mit dem autonomen Verbrauch. Sie ist die Notbremse gegen einen Agenten, der nachts von allein hochdreht und den niemand bemerkt. Was du im Chat selbst tippst, bremst deinen Agenten deshalb nicht aus: Dieser Verbrauch läuft gegen dein eigenes Kontingent, und der Workspace-Topf bremst unabhängig davon weiter.

Bei einem Agenten, der ausschließlich im Chat genutzt wird, blendet die Seitenleiste die Status- und Verbrauchskarte aus. Der Verbrauch stünde dauerhaft auf 0,00 €, und Pausieren bewirkt bei einem solchen Agenten nichts, weil eine Pause nur Zeitplan- und Webhook-Läufe blockiert. Die Karte erscheint, sobald du einen Zeitplan oder Webhook einrichtest, und bleibt für den Rest des Monats sichtbar, wenn bereits autonomer Verbrauch angefallen ist.

Wohin der Verbrauch gebucht wird, hängt davon ab, was passiert ist, nicht davon, wem der Agent gehört:

• Autonome Läufe zahlt das Guthaben des Workspaces
• Was du im Chat tippst, zählt zu deinem eigenen Kontingent, in welchem Agenten auch immer

Ist das Guthaben leer, startet kein autonomer Lauf mehr, chatten kannst du weiterhin. Du musst nicht warten, bis ein Lauf danebengeht, um das zu merken: Sobald das Guthaben aufgebraucht ist, steht der Agent in der Agentenliste, auf seiner Startseite und in der Seitenleiste auf „Kein Guthaben” statt auf „Aktiv”, und „Jetzt ausführen” ist gesperrt. Ein manuell gestarteter Lauf ist ebenfalls ein autonomer Lauf und würde genauso abgewiesen.

Der Agent bleibt dabei absichtlich eingeschaltet. Sobald jemand Guthaben nachkauft, läuft er nach seinem Zeitplan von allein weiter; niemand muss ihn wieder anschalten.

Mehr zum Kontingent-System: Budget & Kontingent.

Admin-Sicht auf alle Agenten

Administratoren sehen unter Einstellungen → Nutzungsanalyse → Agenten eine Übersicht aller Agenten im Workspace, persönlich oder geteilt, mit Owner, autonomem Verbrauch, Kostenbegrenzung, Auslastung, Top-Modell, Anzahl autonomer Läufe und Status. Pro Agent stehen dort drei Aktionen zur Verfügung:

• Kostenbegrenzung & Modelle bearbeiten als Admin-Override (unabhängig vom Owner)
• Pausieren / Fortsetzen für sofortigen Stop bzw. Re-Aktivierung
• Löschen inkl. Stop aller Trigger, Invalidierung der Webhook-URL und Aufräumen der Agent-Inhalte

Detaillierte Beschreibung der Spalten und Aktionen: Nutzungsanalyse, Agenten-Übersicht (Admin).

Sicherheit & Datensouveränität

Die bestehenden Datenschutz-Garantien gelten auch für Agenten, siehe Datenschutz & Datensouveränität. Zusätzlich:

• Client-seitige Verschlüsselung: Wissensdatei, Referenz-Dateien und Run-Ergebnisse werden verschlüsselt abgelegt; selbst Plattform-Betreiber können den Klartext nicht lesen.
• Markierung untrusted Content: Inhalte aus eingehenden Webhooks, Mail-Bodies oder Web-Scrapes werden im KI-Kontext explizit als Information (nicht als Anweisung) gekennzeichnet. Das senkt das Risiko, dass versteckte Befehle in solchen Inhalten vom Agenten ausgeführt werden, eine vollständige Absicherung gegen Prompt-Injection ist nach heutigem Stand der Technik nicht möglich, deshalb gilt: behandle alle Integrationen mit Vorsicht und prüfe regelmäßig, welche Zugänge deine geteilten Agenten in ihrer Liste haben.
• Isolierte Code-Ausführung: Guard-Scripts und sonstige Code-Tools laufen in einer sandboxed Umgebung, die nur freigegebene Ziele im Internet erreichen darf.
• Vollständiger Audit-Trail: jeder Tool-Aufruf eines Agenten ist mit dem auslösenden Run verknüpft. Administratoren können für jede Aktion bis zum Trigger und Payload zurückspringen.

Drei konkrete Beispiele

Damit das Konzept greifbarer wird, hier drei realistische Agenten, wie sie in der Praxis aufgesetzt werden. Du kannst sie als Vorlage übernehmen und im Chat sagen „Erstelle mir einen Agenten wie dieses Beispiel, aber mit …”.

Beispiel 1: Daily Briefing

Ein Agent, der dir jeden Morgen das Tagesbriefing aufbereitet, so wie es eine persönliche Assistentin am Schreibtisch vorbereiten würde.

Konfiguration:

• Trigger: Cron, Werktags 06:30 Europe/Berlin
• Guard-Script: „Ist heute Werktag und nicht im hinterlegten Urlaubskalender?”, falls nein, kein KI-Run
• Integrationen: Microsoft 365 (Mail + Kalender), Datawarehouse-Anbindung (Databricks oder PostgreSQL via On-Premise Connector), Web-Recherche

Ablauf jedes Runs:

1. Posteingang sichten: Liest ungelesene Mails seit dem letzten Briefing, klassifiziert nach „heute beantworten”, „kann warten”, „nur zur Kenntnis” und entwirft für die Top-3 dringenden Mails Antwortvorschläge im Tonfall des Owners (aus AGENTS.md).
2. Termine vorbereiten: Listet alle heutigen Kalendertermine mit Teilnehmern und Ort. Pro Termin eine Vorbereitungsnotiz aus eurer Wissensbasis (frühere Notizen zum Kunden, letzter Mailverkehr, offene Tickets).
3. Unternehmens-KPIs: Holt den aktuellen Stand aus eurem Datawarehouse, zum Beispiel Umsatz gestern vs. Vortag und gleicher Wochentag der Vorwoche, neue Leads, abgeschlossene Deals, kritische offene Tickets. Auffällige Abweichungen werden kurz eingeordnet. Die Anbindung kann direkt über die Databricks-Integration laufen oder bei On-Premise-Datawarehouses (PostgreSQL, MS SQL und andere) über den On-Premise Connector.
4. Marktradar: Recherchiert über die Web-Tools der Plattform aktuelle Meldungen zu den in AGENTS.md hinterlegten Themen (Branche, Wettbewerber, Trendthemen). Liefert die Top 3 als 2-Satz-Zusammenfassung mit Quelle und einer kurzen Einordnung „Was bedeutet das für uns?”.
5. Auslieferung in zwei Wegen gleichzeitig:
   • Mail an den Owner: Kompakter Überblick zum schnellen Scannen auf dem Weg ins Büro
   • Bericht in 9brains: Ausführliche Version mit allen Details und Quellenlinks, abgelegt in einer persönlichen Wissensbasis „Daily Briefings” zum späteren Nachlesen

Was der Agent über die Zeit lernt: Er pflegt seine AGENTS.md selbst weiter. Welche Mail-Absender du als wichtig markierst, welche KPIs du regelmäßig kommentierst, welche News du als „nicht relevant” abwinkst, all das nimmt er in seine Anweisungen auf und macht das nächste Briefing präziser.

Beispiel 2: Ticket-Triage per Webhook

Ein Agent, der bei eingehenden System-Alerts entscheidet, ob ein Ticket angelegt werden muss, und die richtige Person informiert.

Konfiguration:

• Trigger: Webhook (Bearer-Token-Auth, Fire-and-forget-Antwortmodus)
• Integrationen: Atlassian (Jira), Microsoft 365 (Mail)

Ablauf eines Runs:

1. Ein externes Monitoring-System (z.B. Grafana, Statuspage-Tool) ruft die Agent-Webhook-URL mit dem Alert-Payload auf.
2. Der Agent prüft im Jira, ob zu diesem Alert bereits ein offenes Ticket existiert (Suche per Komponente, Fehlertext, Service).
3. Falls Ticket existiert: Kommentiert das vorhandene Ticket mit dem neuen Vorfall und einer Korrelations-Notiz „Ähnliches Symptom, möglicher Zusammenhang mit Ticket X”.
4. Falls kein Ticket existiert: Legt ein neues Jira-Ticket an, mit strukturierter Beschreibung, Schweregrad-Vorschlag, vermuteter Komponente und den letzten relevanten Log-Auszügen aus dem Alert.
5. Schickt dem zuständigen Team-Lead per M365-Mail eine kurze Notiz mit Ticket-Link und der eigenen Einschätzung „Sieht aus wie X, kann warten” oder „Bitte heute noch ansehen, kritischer Pfad”.

Warum das in der Praxis hilft: Die First-Level-Triage dauert sonst täglich 15 bis 30 Minuten und wird oft inkonsistent gemacht. Der Agent macht sie sofort, immer im gleichen Schema, und der Team-Lead bekommt nur noch die kuratierten Fälle auf den Tisch.

Beispiel 3: Wettbewerber-Watch

Ein Agent, der für eure Top-Wettbewerber wöchentlich die wichtigsten Webseiten überwacht und nur die echten Änderungen in die Wissensbasis schreibt.

Konfiguration:

• Trigger: Cron, jeden Montag 09:00 Europe/Berlin
• Guard-Script: „Haben sich die hinterlegten Webseiten seit dem letzten Lauf inhaltlich geändert?”, falls nein, kein KI-Run und keine Mail
• Integrationen: Web-Tools der Plattform (Page-Crawl), Wissensmanagement, Microsoft 365 (Mail)

Ablauf jedes Runs:

1. Seiten abrufen: Holt die fünf in AGENTS.md hinterlegten Webseiten der Wettbewerber (Produktseite, Preise, Newsroom, Karriereseite, About-Page) als strukturierten Text.
2. Diff zur Vorwoche: Vergleicht mit dem Stand der letzten Indexierung, die in einer geteilten Wissensbasis „Wettbewerber” liegt.
3. Bewertung: Ignoriert kosmetische Änderungen (Datumsstempel, Cookie-Banner) und schreibt nur die inhaltlich relevanten Änderungen heraus, gegliedert nach Wettbewerber. Pro Änderung eine 2-Satz-Einordnung: „Was ist neu, warum könnte das für uns relevant sein?”.
4. Update der Wissensbasis: Legt einen neuen Eintrag „Wettbewerber-Watch KW XX” an, mit Diff-Zusammenfassung und Links zu den jeweiligen Seiten.
5. Mail an die Geschäftsführung: Kompakter Wochenüberblick mit den Top-Änderungen und einer einzigen Empfehlung „Worauf wir diese Woche reagieren sollten”.

Warum das in der Praxis hilft: Niemand klickt jede Woche zuverlässig durch 25 Wettbewerber-Seiten. Der Agent macht es konsistent, sortiert Rauschen aus und liefert eine handlungsfähige Empfehlung. Das Guard-Script sorgt dafür, dass es keine leeren „Nichts Neues”-Mails gibt.

Troubleshooting

Was tun, wenn ein Agent nicht so läuft wie erwartet.

Agent bricht beim Run mit einer Fehlermeldung ab

Vier häufige Ursachen, in dieser Reihenfolge prüfen:

• Agent-Kostenbegrenzung erreicht: Im Tab KI-Modell siehst du Verbrauch und Begrenzung. Wenn der Verbrauch nahe oder über dem Limit liegt, hebe die Begrenzung an oder warte bis zum 1. des Folgemonats. Hintergrund unter Welche Bremse greift wann?.
• Guthaben des Workspaces aufgebraucht: Autonome Läufe werden aus dem Guthaben bezahlt. Ist es leer, startet kein autonomer Lauf mehr, auch wenn die Lizenzkontingente noch Spielraum haben. Ein Administrator kann Guthaben unter Abrechnung nachkaufen.
• Auto-Pause nach drei Fehlern in Folge: Wenn drei autonome Runs hintereinander mit einem Fehler endeten, pausiert die Plattform den Agenten automatisch, um Kontingent zu schützen. Sieh dir die letzten drei Runs in der Run-Historie an, behebe die Ursache (oft eine veränderte API-Antwort eines externen Tools) und reaktiviere den Agenten im Tab Allgemein.
• Premium-Modelle im Workspace gerade deaktiviert: Wenn der monatliche Workspace-Pool aufgebraucht ist, laufen nur noch die günstigen Modelle. Ein Agent, der auf ein Premium-Modell konfiguriert ist, pausiert dann. Konfiguriere ein sparsames Modell als zulässig im Tab KI-Modell, oder warte auf den nächsten Kontingent-Reset.

Cron-Trigger feuert nicht zur erwarteten Zeit

1. Zeitzone prüfen: Cron-Pläne laufen in der konfigurierten IANA-Zeitzone (Standard Europe/Berlin), nicht in UTC. Sommer- und Winterzeit werden korrekt behandelt.
2. Aktivitätsstatus: Im Tab Allgemein muss „Agent aktiv” gesetzt sein. Bei pausierten Agenten (manuell oder durch Auto-Pause) feuert kein Trigger.
3. Guthaben: Steht bei dem Agenten „Kein Guthaben” statt „Aktiv”, ist das Guthaben des Workspaces aufgebraucht. Der Zeitplan bleibt bestehen, es startet aber kein Lauf, bis ein Administrator Guthaben nachkauft.
4. Guard-Script: Wenn ein Guard-Script konfiguriert ist und beim letzten Lauf nichts gefunden hat, läuft kein KI-Run, das ist absichtlich kein Fehlerzustand. In der Run-Historie taucht der Fall mit dem Hinweis „Guard ohne Treffer” auf.

Webhook-Trigger antwortet mit 401 oder 403

• Bearer-Token: Der Token wird einmalig im Klartext angezeigt und kann jederzeit im Tab Trigger rotiert werden. Format: Authorization: Bearer <token> ohne Anführungszeichen.
• HMAC-Signatur: Falls aktiviert, muss die Signatur über den exakten Body-Payload berechnet werden und der Timestamp-Header innerhalb des Fünf-Minuten-Fensters liegen.
• Rate-Limit: Standardwert ist 60 Anfragen pro Minute. Bei 429-Antworten den Wert im Tab Trigger anpassen.

Häufige Fragen

Was unterscheidet einen Agenten von einer Wissensbasis oder einem Skill?

Kurz: Ein Agent ist jemand, der Aufgaben übernimmt. Eine Wissensbasis ist Wissen, auf das die KI zugreift. Ein Skill ist eine Fähigkeit, die der Agent nutzt. Eine ausführliche Abgrenzung samt Entscheidungshilfe findest du unter Wissen & Kontext, Was nutze ich wofür?.

Können mehrere Nutzer denselben Agenten bearbeiten?

Ja, wenn du ihnen die Rolle „Agent bearbeiten” gibst. Damit ändern sie Anweisungen (AGENTS.md), Tools, Budget und Datei-Anhänge. Diese Rolle kannst du einzelnen Personen, ganzen Gruppen oder über den Eintrag „Alle Mitglieder” allen Kolleginnen und Kollegen geben. Wer nur „Agent verwenden” hat, kann den Agenten benutzen, aber nichts an ihm ändern.

Auch wer den Agenten ursprünglich erstellt hat, darf ihn dauerhaft bearbeiten, selbst wenn der Agent später an eine andere Person übergeben wurde.

Fünf Dinge bleiben dem Besitzer, allen mit der Rolle „Agent administrieren” und den Workspace-Administratoren vorbehalten:

• Freigabe ändern (wer steht in der Liste, mit welcher Rolle)
• Trigger einrichten (Cron und Webhook), denn damit läuft der Agent unbeaufsichtigt mit den Konten aus seiner Kontenliste
• Agent pausieren oder fortsetzen, weil das alle betrifft, die ihn nutzen
• Besitzer wechseln
• Agent löschen

Workspace-Administratoren haben diese fünf Möglichkeiten also auch bei Agenten, die ihnen nicht gehören. Bearbeiten dürfen sie deshalb aber nicht automatisch mit, dafür tragen sie sich sichtbar als Bearbeiter in die Freigabe ein.

Die Kontenliste gehört dagegen zum Bearbeiten: Wer den Agenten bearbeiten darf, pflegt sie im Tab Werkzeuge & Zugänge. Einschalten kann dort aber jeder nur die Konten, die ihm selbst gehören, ein fremdes Konto lässt sich nicht in einen Agenten hineinlegen. Wer den Agenten administrieren darf, kann ein fremdes Konto herausnehmen, aber keines einschalten.

Kann ich einen Agenten duplizieren?

Ja. Beim Duplizieren werden Konfiguration, AGENTS.md und Referenz-Dateien übernommen. Nicht übernommen werden Trigger-Konfigurationen, die Kontenliste und die Run-Historie. Der Klon startet als manueller, ungeteilter Agent und folgt damit zunächst wieder deinen eigenen Zugängen.

Wie viele Agenten kann ich erstellen?

Es gibt keine harte Obergrenze. Was der Agent autonom verbraucht, zahlt das Guthaben des Workspaces und wird zusätzlich von seiner monatlichen Kostenbegrenzung gedeckelt. Was du im Chat tippst, läuft gegen dein eigenes Kontingent.

Mehrere Cron-Pläne auf einem Agenten?

In dieser Version: nein. Pro Agent ist ein Cron-Plan möglich. Für mehrere unabhängige Zeitpläne legst du mehrere Agenten an, die AGENTS.md lässt sich per Duplizieren leicht teilen.

Können Agenten andere Agenten aufrufen?

Aktuell: nein. Jeder Agent läuft eigenständig. Multi-Agent-Orchestrierung steht auf der Roadmap.

Welche E-Mail-Provider können Agenten nutzen?

Aktuell Microsoft 365 als fertige Integration. Damit kann ein Agent Mails lesen, beantworten und versenden. Aus welchem Postfach, hängt an seiner Kontenliste: Steht dort ein Postfach, nimmt er dieses, im Chat genauso wie bei automatischen Läufen. Steht dort keines, arbeitet er im Chat im Postfach der Person, die ihn gerade fragt, und bei automatischen Läufen gar nicht.

Eine native Gmail- oder IMAP-Integration ist aktuell nicht verfügbar. Wenn du einen anderen Provider anbinden willst, kannst du einen eigenen MCP-Skill bauen, der die API des Providers anspricht. Für eine native Anbindung weiterer E-Mail-Provider melde dich gern bei deinem Ansprechpartner bei 9brains, wir nehmen Bedarf in die Roadmap-Priorisierung auf.

Können Agenten auf interne oder On-Premise-Systeme zugreifen?

Ja, über den On-Premise Connector. Dieser baut einen verschlüsselten WireGuard-Tunnel in dein Firmennetzwerk auf. In Kombination mit einer passenden Integration oder einem Skill kann ein Agent dann zum Beispiel eine interne PostgreSQL-Datenbank abfragen, ein lokal betriebenes Odoo, SAP oder Microsoft Dynamics ansprechen oder gegen interne HTTP-APIs arbeiten. Die Verbindung ist nur ausgehend, dein Netzwerk bleibt von außen unerreichbar.

Interne Fileserver, NAS-Systeme und SMB-Freigaben lassen sich zusätzlich als durchsuchbare Datenquelle anbinden, inklusive automatischer Indexierung. Ein Agent findet diese Dateien dann genauso wie Dokumente aus OneDrive oder SharePoint. Auf Wunsch werden die Windows-Dateirechte übernommen, dann sieht jede Person nur die Dateien, für die sie auch auf dem Laufwerk berechtigt ist.

Kann ich Termine oder Aufgaben erstellen lassen?

9brains hat keine eigene Termin- oder Aufgaben-Verwaltung. Mit angebundener Microsoft-365-Integration kann ein Agent dafür aber direkt in deinem Outlook-Kalender oder in deiner Outlook-Aufgabenliste arbeiten, neue Termine anlegen, Einladungen versenden oder Aufgaben mit Fälligkeit erstellen. Sage dem Agenten zum Beispiel: „Lege einen Termin für Donnerstag um 14 Uhr mit dem Kunden Müller an” oder „Erstelle mir eine Aufgabe für morgen: Angebot prüfen”.

Kann ich meine ChatGPT Custom GPTs migrieren?

Einen automatischen Migrations-Import gibt es derzeit nicht, dafür einen einfachen Workflow im Chat: Sag der KI „Ich möchte ein Custom GPT zu 9brains übertragen” und füge anschließend Name, Beschreibung und den System-Prompt deines Custom GPTs in den Chat ein. Die KI erstellt daraus einen Agenten mit passender Konfiguration und übernimmt die Anweisungen in die AGENTS.md. Etwaige Referenz-Dateien deines Custom GPTs lädst du anschließend im Tab Datei-Anhänge des Agenten hoch.