Hermes Agent für internen IT-Support: Anleitung für ein sicheres Setup (2026)

Kurzfassung

Hermes Agent für internen IT-Support passt besser als Hermes für den Kundensupport, weil Ihre Nutzer Kollegen sind, die Sie auf eine Allowlist setzen können. Am stärksten ist er als persönlicher Sidekick des IT-Admins: Health-Checks per Cron, Alert-Triage aus Datadog oder Grafana und echte Befehle auf einem Server über SSH.

Der Haken zeigt sich, sobald Sie ihn für die ganze Firma öffnen. Zugriff wird Nutzer-ID für Nutzer-ID vergeben, die Trennung zwischen Admin und Nutzer beschränkt nur Slash-Befehle, und die Freigabe eines riskanten Befehls geht zurück an den Mitarbeiter, der gefragt hat, nicht an die IT. Die Lösung sind zwei Profile: ein schreibgeschütztes „it-desk“-Profil für alle, mit abgeschaltetem Terminal, und ein „ops“-Profil, das nur Admins erreichen.

Wenn Sie den Server lieber überspringen: eesel beantwortet IT-Fragen von Mitarbeitern in Slack aus Ihrem Confluence, arbeitet in Jira Service Management als First Responder und lässt nur Ihre IT-Admins Aktionen freigeben.

Warum ich Hermes für interne IT geprüft habe

Ich baue bei eesel KI-Agenten, und in letzter Zeit kommt die Frage „Können wir nicht einfach Hermes nehmen?“ am häufigsten von IT-Teams statt von Support-Teams. Das ist nachvollziehbar. Ein IT-Team betreibt ohnehin Server, lebt in Slack oder Teams, und meistens gibt es einen Engineer, dem eine YAML-Datei nichts ausmacht.

Ich bin schon länger auf der anderen Seite unterwegs. eesel arbeitet als First Responder am internen IT-Desk von InDebted, wo ein IT-Team aus 5 bis 10 Personen Anfragen von mehr als 250 Mitarbeitern in fünf Märkten bearbeitete. Es hat 15 % der Probleme abgefangen und trainiert weiter mit vergangenen Anfragen in Richtung eines Ziels von 55 %. Der Head of IT hat es klar gesagt:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, Head of IT, InDebted

Diese Arbeit hat mir gezeigt, wo das Risiko im internen IT-Support wirklich sitzt, und es sind nicht Fremde. Es ist der hilfsbereite Kollege, der den Bot bittet, es „einfach neu zu starten“. Also habe ich die Hermes-Docs von vorne bis hinten gelesen, mit einer Frage im Kopf: Was passiert, wenn 200 Mitarbeiter mit einem Agenten reden können, der ein Terminal hat?

Was Hermes Agent einem IT-Team bietet

Hermes Agent ist der Open-Source-Agent von Nous Research zum Selbsthosten. Er steht unter MIT-Lizenz, hat 251,503 GitHub-Sterne, und das neueste Release ist v0.21.5, veröffentlicht am 24. September 2026.

Mein Hermes-Agent-Review behandelt das ganze Produkt, und mein Überblick zu Open-Source-KI-Agenten stellt ihn neben seine Mitbewerber. Für die IT-Arbeit sind vier Bausteine wichtig.

• Sieben Terminal-Backends. Hermes kann Befehle lokal, in Docker, über SSH oder in Modal, Daytona, Vercel Sandbox oder Singularity ausführen (Configuration). Das SSH-Backend hält eine dauerhafte Shell auf einem entfernten Server, und die Docs nennen es „Recommended for security“, weil der Agent seinen eigenen Code nicht ändern kann (Tools).
• Ein Messaging-Gateway. Slack, Microsoft Teams, Google Chat, E-Mail und mehr als 20 weitere Kanäle (Messaging Gateway). So betreiben die meisten Teams ohnehin ITSM in Slack.
• Cron und Webhooks. Geplante Jobs und eingehende Webhooks von Tools wie GitHub, GitLab und Jira, mit HMAC-Signaturprüfung (Webhooks).
• MCP-Server. Ein kuratierter Katalog mit 65 geprüften Servern, standardmäßig deaktiviert (MCP catalog). Wenn MCP neu für Sie ist, erklärt mein Beitrag zum KI-Agent-MCP-Server die Grundlagen.

Es ist also ein echtes Toolkit für ein IT-Team. Offen ist, wer es nutzen darf.

Zwei Aufgaben, ein Agent

Die meisten „Hermes für IT“-Pläne, die ich sehe, werfen zwei sehr unterschiedliche Aufgaben in einen Topf.

Aufgabe 1 ist der Sidekick des IT-Admins. Zwei oder drei Admins schreiben dem Agenten per DM, er führt Checks auf Servern aus, sortiert Alerts und berichtet, was er gefunden hat. Wer hier einen riskanten Befehl freigibt, ist ein Admin, der ihn versteht.

Aufgabe 2 ist die Anlaufstelle für Mitarbeiter. Alle im Unternehmen fragen ihn in #it-help: „Warum ist mein VPN down?“ Diese Aufgabe haben die Leute vor Augen, wenn sie von KI für interne IT-Helpdesks sprechen. Der Agent ist derselbe und die Tools sind es auch, aber das Risiko ist ein ganz anderes.

Jedes IT-Beispiel in den Hermes-Docs gehört zu Aufgabe 1. Ich habe den kompletten Docs-Dump nach „helpdesk“, „IT support“ oder „employee“ durchsucht und null Treffer bekommen. Die Beispiele zeigen stattdessen einen Operator, der seinen eigenen Betrieb steuert, etwa Alert-Triage für einen Bereitschaftskanal, Uptime-Checks und Speicherplatz-Alarme.

Aufgabe 1: Hermes als Sidekick des IT-Admins (das funktioniert)

Hier verdient sich Hermes seinen Platz. Einige der dokumentierten Muster lassen sich fast unverändert auf ein IT-Team übertragen:

• Server-Health-Checks nach Zeitplan. Die Team Telegram Assistant guide enthält einen Prompt, der alle 6 Stunden die Festplattenbelegung mit df -h, den Arbeitsspeicher mit free -h und den Container-Status mit docker ps prüft und das Ergebnis an einen Team-Kanal liefert.
• Reiner Skript-Cron ohne Modellaufruf. hermes cron create "*/15 * * * *" --no-agent --script disk-alert.sh --deliver telegram führt ein einfaches Skript aus und schickt die Ausgabe weiter (Script-only cron). Das ist günstig, und für einen Festplatten-Check verbrennen Sie keine Tokens.
• Alert-Triage aus dem Monitoring. Die Seite Automation Blueprints enthält einen Alert-Triage-Webhook, der eine Eskalationsempfehlung von P1 bis P4 anfordert und mit „This goes to the on-call channel.“ endet.
• Leise Fehler. „A recurring job that keeps failing with the same error alerts you once, not on every run“ (Cron). Wer schon einmal einen lauten Alert-Kanal stummgeschaltet hat, weiß das zu schätzen.

Bei den Tools enthält der Katalog bereits den Monitoring-Stack, den die meisten IT-Teams nutzen: Datadog, Grafana, Sentry, Better Stack und Cloudflare, alle über OAuth. Kombinieren Sie das mit dem SSH-Backend, und Sie haben einen Agenten, der einen Alert liest, die Maschine prüft und Ihnen dann sagt, was seiner Meinung nach nicht stimmt.

Zwei Sicherheitsvorgaben helfen hier ebenfalls. Cron-Jobs lehnen gefährliche Befehle standardmäßig ab (cron_mode: deny), ein geplanter Job kann also nichts per systemctl restart neu starten, solange Sie das nicht umstellen (Security). Die Prüfungen auf gefährliche Befehle laufen außerdem auf den Backends local und ssh, und genau dort findet die IT-Arbeit statt.

So beschreiben es Homelab-Nutzer. Ein Hacker-News-Kommentator betreibt es genau so, mit Freigabeschritt und Rückweg:

"I use Hermes at home. [...] it's a sysadmin for my homelab. It has a read-only mcp server to check the k8s status and has it's own ssh access to fix stuff after I approve it per session. It's magical. Each morning I get a small update whether the backup ran, if pods are stuck or behaving weirdly etc... Since the entire homelab is GitOps I can always reverse a change made by the agent."

apexalpha, Hacker News

Beachten Sie, wer dort freigibt: dieselbe Person, der die Server gehören. Wenn Sie ein kleines IT-Team mit einem Engineer sind, der so etwas gern macht, ist Aufgabe 1 ein guter Einsatz für ein kostenloses Tool.

Aufgabe 2: Hermes als Anlaufstelle für Mitarbeiter (hier wird es knifflig)

Sobald Sie denselben Agenten für alle öffnen, werden vier Dinge in den Docs relevant. Keines davon ist ein Bug, wohlgemerkt. Hermes wurde als Agent für Operatoren entworfen, und das sind die Nahtstellen, an denen dieses Design durchscheint.

1. Zugriff wird Einzel-ID für Einzel-ID vergeben

Jede Chat-Allowlist ist eine Liste einzelner IDs: Slack-Member-IDs, Azure-AD-Objekt-IDs bei Teams, E-Mail-Adressen bei Google Chat (Environment variables). Ich habe keinen Domain-Wildcard wie *@company.com gefunden, und eine Einstellung für den ganzen Tenant oder Workspace gibt es auch nicht.

Die einzigen „Alle“-Schalter, wie SLACK_ALLOW_ALL_USERS und TEAMS_ALLOW_ALL_USERS, sind in der Referenz mit „(dev only)“ gekennzeichnet. Gruppenbasierter Zugriff existiert nur für Discord-Rollen. Der andere Weg ist DM-Pairing: Jeder Mitarbeiter bekommt einen Code, und ein Admin gibt ihn per Hand mit hermes pairing approve frei. Bei 200 Personen sind das 200 Freigaben, und dann kommt jeder neue Kollege dazu.

Single Sign-on gibt es, aber nur für das Web-Dashboard über Ihren eigenen OpenID-Connect-Anbieter (Web Dashboard). SCIM gibt es ebenfalls nicht: Wenn Sie jemanden in Okta offboarden, wird er nicht automatisch aus dem Bot entfernt.

2. Die Nutzerstufe begrenzt Befehle, nicht Tools

Hermes hat eine Trennung zwischen Admin und Nutzer, und man nimmt leicht an, sie begrenze, was normale Nutzer tun dürfen. Tatsächlich begrenzt sie Slash-Befehle. Normale Nutzer erhalten die Befehle, die Sie in user_allowed_commands aufführen, plus /help und /whoami (Slash commands).

Normaler Chat wird gar nicht eingeschränkt. Das bedeutet, jeder zugelassene Mitarbeiter kann den Agenten um alles bitten, was seine Tools erlauben, das Terminal eingeschlossen. Dieselbe Wand bin ich auf der Kundenseite in meinem Beitrag zu Hermes für den Kundensupport gestoßen.

3. Freigaben gehen an die Person, die gefragt hat

Wenn Sie IT-Leiter sind, würde ich diesen Punkt doppelt unterstreichen. Wenn Hermes einen markierten Befehl ausführen will, etwa systemctl restart, chown -R root oder sed -i auf eine Datei in /etc/, fragt er im selben Chat um Freigabe: „the agent sends the dangerous command details to the chat and waits for the user to reply“ (Security).

Die approvals-Konfiguration hat mode, timeout, cron_mode und ein paar weitere Optionen, aber keine Freigeber-Liste und keine Möglichkeit, die Karte an einen IT-Admin oder einen separaten Kanal zu schicken. In Teams hat die Karte vier Schaltflächen: Allow Once, Allow Session, Always Allow, Deny (Teams). Wer in einem Gruppenchat darauf klicken darf, sagen die Docs nicht.

„Always Allow“ bleibt außerdem bestehen. Freigegebene Befehle werden in config.yaml gespeichert und „silently approved in all future sessions“ (Security). Ein Klick eines Mitarbeiters in Eile, und dieser Befehl ist für alle vorab freigegeben.

4. Der Speicher ist geteilt, und es gibt kein Chat-Audit-Log

Der eingebaute Speicher besteht pro Profil aus einer MEMORY.md (2.200 Zeichen) und einer USER.md (1.375 Zeichen), die in jede Sitzung dieses Profils geladen werden (Memory). Bei einem gemeinsamen IT-Bot heißt das: Was der Agent im Chat eines Mitarbeiters speichert, taucht in der Sitzung des nächsten Mitarbeiters auf. Den Schutz, den die Docs anbieten, ist memory.write_approval: true, das jede Speicherung aus dem Messaging zur Prüfung durch einen Admin mit /memory pending zwischenspeichert.

Ein Entwickler, der ein Multi-User-Setup ausprobiert hat, ging weiter:

"we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent."

GTP, Hacker News

Die Hermes-Docs nennen die Isolation zwischen Sitzungen als eine ihrer acht Sicherheitsebenen. Betrachten Sie das also als Erfahrung eines Entwicklers, nicht als dokumentierten Fehler. Es ist trotzdem das Erste, was ich testen würde, bevor ein Kanal live geht, in dem Leute nach Passwort-Resets fragen.

Zum Audit: Die Monitoring-Seite des Gateways sagt, es handle sich nicht um „analytics, audit logs, or detailed execution traces“ (Gateway monitoring). Die Sicherheits-Checkliste rät, „~/.hermes/logs/“ zu prüfen. Wenn Ihr IT-Team sich vor einem SOC-2-Auditor verantworten muss, ist das eine Lücke, die Sie selbst füllen müssten.

Hermes mit Slack, Teams und Google Chat verbinden

Jede Chat-App ist anders aufgebaut, und diese Unterschiede entscheiden am Ende, wo Sie das Gateway hosten können.

Quellen: Slack, Teams, Google Chat.

Slack ist am einfachsten. Socket Mode „works behind firewalls, on your laptop, or on a private server.“ Für die IT sind zwei Einstellungen wichtig: channel_skill_bindings lädt einen Skill, sobald in einem Kanal wie #it-help eine Sitzung startet (Threads erben ihn), und allowed_channels sorgt dafür, dass der Bot jeden anderen Kanal ignoriert, selbst bei einer @Erwähnung. Eine Eigenheit, die man kennen sollte: DMs sind von allowed_channels ausgenommen.

Teams macht mehr Arbeit. „Teams delivers messages by calling a public HTTPS webhook“, das Gateway braucht also einen erreichbaren Endpunkt, und „Teams rejects self-signed certificates.“ Die Registrierung läuft über die @microsoft/teams.cli von Microsoft („no Azure portal needed“), die Ihnen Client-ID, Secret und Tenant-ID liefert. In den Docs steht eine Warnung, die ich wörtlich nehmen würde: Ohne TEAMS_ALLOWED_USERS kann „anyone who can find or install your bot“ mit ihm interagieren.

Es gibt außerdem einen Microsoft-Graph-Listener (msgraph_webhook), der heute aber vor allem die Pipeline für Teams-Meeting-Zusammenfassungen speist (Graph webhook). Er gibt Hermes keinen Zugriff auf das Nutzerverzeichnis oder die Geräteverwaltung, erwarten Sie also nicht, dass er Passwörter zurücksetzt oder Intune prüft. Mein Ratgeber zur Automatisierung von Microsoft-Teams-Support betrachtet den Teams-Weg breiter.

Welche IT-Tools Hermes erreichen kann

Beim MCP-Katalog werden IT-Teams oft überrascht. Er ist stark beim Monitoring, aber dünn bei Identität und Service-Management.

Jira Service Management hat eine versteckte Lücke. Der Atlassian-Eintrag im Katalog beschreibt „Jira issues and Confluence pages“ und verbindet sich über OAuth. Atlassians Rovo-MCP-Server hat zwar eine JSM-Toolgruppe, aber diese vier Tools betreffen On-Call-Alerts und Zeitpläne und erscheinen nur bei API-Token-Authentifizierung, die ein Org-Admin aktivieren muss. Über den OAuth-Weg des Katalogs sieht Hermes eine Anfrage also nur als gewöhnliches Jira-Work-Item. Es gibt kein Tool für Anfragetypen, Queues, SLAs oder Freigaben. Mein Beitrag zu Claude für JSM geht denselben Server im Detail durch.

ServiceNow hat keinen Katalogeintrag. Der eigene MCP-Server von ServiceNow ist in Now Assist und den AI-Native-SKUs enthalten, und sein Quickstart-Server liefert vier Tools zum Lesen und Zusammenfassen. Auf der Open-Source-Seite führt der Weg über einen Community-Server, den Sie selbst unter mcp_servers konfigurieren. Siehe meinen Ratgeber zur ServiceNow-MCP-Integration.

Identität und Geräte sind Eigenbau. Es gibt keine Einträge für Okta, Entra, Intune, Jamf oder den Google-Workspace-Admin. Community-Skills auf skills.sh sind klein: Der beliebteste ServiceNow-Skill hat 135 Installationen, Freshservice 118, Jamf 4. Die Ausnahme ist Googles eigener Skill persona-it-admin mit 28,951 Installationen (skills.sh). Bedenken Sie, dass jeder dieser Skills Drittanbieter-Code ist, den Nous nicht geprüft hat.

Wenn Ihr Stack aus Jira, Confluence und Datadog besteht, deckt Hermes viel ab. Wenn es ServiceNow, Okta und Intune sind, planen Sie echte Entwicklungszeit ein. Mein Überblick zu KI für IT-Service-Management behandelt Tools, die für diesen zweiten Stack gebaut sind.

So richten Sie Hermes sicher für internen IT-Support ein

Das Muster, für das ich mich entscheiden würde, trennt die beiden Aufgaben in zwei Profile. In Hermes ist ein Profil ein vollständig getrennter Agent mit eigener Konfiguration, eigenem Speicher, eigenen Skills und Bot-Tokens, und ein Gateway kann mehrere bedienen (Profiles).

Ein Entwickler auf Hacker News ist auf dieselbe Idee gekommen, allerdings für ein anderes Risiko:

"My solution to the problem, which I am implementing as a Hermes plugin + custom iOS / macOS app, is simple: an airlock architecture. One Hermes profile runs with local FS access and no internet access, inside an Apple container, and one Hermes profile runs with internet access and no FS access, inside an Apple container."

elliotbnvl, Hacker News

So würde ich es Schritt für Schritt aufbauen.

1. Das Gateway auf einer eigenen Maschine betreiben

Die Docs sind hier eindeutig: „For maximum security, run the gateway on a separate machine or VM. Set terminal.backend: ssh“ (Security). Und setzen Sie das Dashboard nie ohne Authentifizierung ins Netz. Die Docker-Docs beschreiben „the June 2026 MCP-config persistence campaign“, bei der Scanner offen erreichbare Dashboards fanden und „drove the agent into planting an SSH-key backdoor“ (Docker).

2. Das Terminal für das Mitarbeiter-Profil abschalten

Fügen Sie im Profil it-desk terminal und code_execution zu agent.disabled_toolsets hinzu. Laut Docs wird ein dort aufgeführtes Toolset immer entfernt, „even if a platform's saved config still lists it“ (Configuration). Ohne Terminal verschwindet das Problem „Freigabe geht an den Anfragenden“ größtenteils, denn es bleibt nichts Gefährliches mehr freizugeben.

Übrig bleiben Lese- und Weiterleitungsaufgaben: aus Ihrer internen Wissensdatenbank in Confluence oder Notion antworten, ein Jira-Issue nachschlagen, ein Ticket eröffnen. Das deckt den Großteil der „Wie richte ich das VPN ein?“-Fragen ab, und der Rest ist einfache Ticket-Triage.

3. Auf einen Kanal und einen Skill festlegen

Setzen Sie allowed_channels auf #it-help und binden Sie diesen Kanal mit channel_skill_bindings an einen IT-Skill. Nutzen Sie zusätzlich strict_mention, damit der Bot in einem langen Thread still bleibt, bis jemand ihn wieder anpingt. Die Docs nennen genau diesen Fall: „a long tech-support thread where the bot helped at the start and you'd rather it stay silent unless explicitly pinged again“ (Slack).

4. Speicherschreibvorgänge zwischenspeichern

Setzen Sie memory.write_approval: true im Profil it-desk, damit der Chat eines Mitarbeiters nicht unbemerkt umschreiben kann, was der Agent danach allen anderen erzählt.

5. Das ops-Profil absichern

Das Profil ops bekommt das SSH-Backend, approvals.mode: manual und eine Allowlist mit genau Ihren IT-Admins. Fügen Sie zusätzlich eine approvals.deny-Liste für Befehle hinzu, die Sie nie aus dem Chat ausgeführt haben wollen, und verzichten Sie auf „Always Allow“ für alles, was /etc/ oder einen Dienst berührt. Die Hardline-Blockliste verweigert rm -rf /, Fork-Bombs und rohe Schreibzugriffe auf Datenträger in jedem Fall, damit sind diese bereits abgedeckt.

6. Testen, bevor Mitarbeiter es sehen

Dabei hilft Hermes nicht. Es gibt keine eingebaute Möglichkeit, die IT-Tickets des letzten Monats durch den Agenten laufen zu lassen und zu sehen, was er geantwortet hätte. Sie brauchen einen Testkanal, eine Liste echter vergangener Fragen und jemanden, der jede Antwort liest, bevor #it-help live geht.

Was Hermes ein IT-Team kostet

Die Lizenz kostet nichts. Der Betrieb ist eine andere Geschichte.

Mit Nous Portal können Sie außerdem einen berechtigten ChatGPT-Tarif für Inferenz verbinden, wobei Tools und Hosting separat abgerechnet werden. Mein Beitrag zu Hermes-Alternativen schlüsselt die Ebenen genauer auf.

Die letzte Zeile taucht nie auf einer Rechnung auf. Jemand muss die Allowlist pflegen und Pairing-Codes für neue Mitarbeiter freigeben, außerdem zwischengespeicherten Speicher prüfen und das Gateway aktuell halten. Bei Aufgabe 1 ist das in Ordnung, weil der Admin zugleich der Nutzer ist. Bei Aufgabe 2 wird daraus ein kleines internes Produkt, das Sie nun betreuen. Ein Kunde, der sich gegen den Eigenbau entschieden hat, hat den Zielkonflikt gut formuliert:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

an engineering lead at a crypto-hardware company, on why they bought instead of building

Hermes vs. eesel für internen IT-Support

So schneiden beide bei den Punkten ab, nach denen ein IT-Leiter meist zuerst fragt.

Quellen: eesel Internal Operations docs, eesel approvals, eesel pricing.

Um ehrlich zu sein, was eesel nicht kann: Es führt keine Shell-Befehle auf Ihren Servern aus, und das ist Absicht. Es ist ein Teamkollege für den Service Desk, kein Sysadmin. Wenn Sie einen Agenten wollen, der sich per SSH auf eine Maschine verbindet und nginx neu startet, ist das Aufgabe 1 von Hermes und nicht das, wofür eesel gedacht ist. eesel hat heute außerdem keine Integration für ServiceNow oder Freshservice (mein Überblick zu KI für Freshservice behandelt diesen Stack), und Teams wird auf Anfrage statt per Self-Service aktiviert.

Sollten Sie Hermes für internen IT-Support betreiben?

Ja, für Aufgabe 1. Wenn Sie ein kleines IT- oder Ops-Team und einen Engineer haben, der so etwas gern macht, ist Hermes als reiner Admin-Sidekick ein gutes Werkzeug, und kostenlos. Betreiben Sie ihn mit dem SSH-Backend und manuellen Freigaben, Datadog oder Grafana über MCP und Skript-Cron für die langweiligen Checks.

Mit Vorsicht, für ein schreibgeschütztes it-desk. Wenn Ihr Wissen in Confluence und Ihre Tickets in Jira liegen, kann ein Profil ohne Terminal, festgelegt auf #it-help, die „Wie mache ich“-Fragen beantworten. Planen Sie nur den Aufwand für die Pflege der Allowlist ein und für das Testen, das niemand gern macht.

Nein, für eine Anlaufstelle für Mitarbeiter mit Terminal. Solange Hermes Freigaben nicht an einen Admin weiterleiten kann, würde ich 200 Mitarbeiter nicht mit einem Agenten chatten lassen, der systemctl ausführen kann. Das ist keine Kritik an Hermes. Er wurde für den Operator gebaut, und die Docs sagen das auch.

Wenn Sie noch abwägen, behandeln meine Listen mit KI-Tools für IT-Support und internen Support-Chatbots Tools, die für die Anlaufstelle gebaut sind, und meine Liste der Slack-Ticketsysteme deckt die Ticketing-Seite ab.

eesel für internen IT-Support

Wenn Sie eigentlich Aufgabe 2 wollen, einen IT-Helpdesk, den Mitarbeiter in Slack fragen können, ohne dass jemand einen Server betreibt, dann ist das genau das, was der Helpdesk-Teamkollege von eesel tut. Er antwortet aus Ihrem Confluence, Notion und Google Drive mit verlinkter Quelle, und wenn er etwas nicht findet, sagt er das.

Der wichtigste Punkt für diesen Beitrag sind die Freigaben. Jede Aktion steht auf Auto, Freigabe nötig oder Deaktiviert, und wenn ein Lauf in Slack gestartet wurde, landet die Freigabekarte in diesem Thread. Nur Workspace Owner und Editoren können freigeben, abgeglichen über ihre Slack-Profil-E-Mail (approvals docs). Der Mitarbeiter, der gefragt hat, kann seine eigene Anfrage nicht freigeben.

Für IT mit Tickets arbeitet eesel in Jira Service Management: Es übernimmt neue Anfragen, antwortet dem Melder oder hinterlässt eine interne Notiz und weist Issues zu, versieht sie mit Labels und verschiebt sie. Und bevor es je eine laufende Anfrage anfasst, können Sie es gegen vergangene Tickets laufen lassen und jede Antwort lesen, die es gegeben hätte.

Und wenn Ihr Team das Terminal so mag wie Hermes-Nutzer, führt die eesel CLI denselben Teamkollegen aus einer Shell aus. eesel approvals listet ausstehende Aktionen, eesel chat "how do I reset a password?" testet eine Antwort, und jeder Befehl gibt JSON aus, sodass Claude Code oder Codex Ihr Setup steuern können. Soll er eine interne Asset-Datenbank erreichen? Network Access lässt ihn eine REST-API aufrufen, während die Zugangsdaten für die KI unsichtbar bleiben.

Sie können eesel kostenlos testen, mit 100 Credits und ohne Karte. Verbinden Sie Slack und Confluence, stellen Sie ihm Ihre zehn häufigsten IT-Fragen und schauen Sie, was zurückkommt.