Das ist Teil 3 der Serie Dein eigener KI-Agent im Selbstbau. In Teil 1 ist der Agent als Docker-Container mit Telegram entstanden, in Teil 2 hast du im Browser abgeschottete Wissens-Agenten gebaut. Bisher warst du als Administrator allein unterwegs. Jetzt kommt eine weitere Person dazu, sauber von dir getrennt.
Worum es geht
Hier entscheidet sich, ob so ein Setup für mehrere Leute taugt. Würdet ihr denselben Agenten nutzen, landeten eure Notizen, Vorlieben und Dokumente in einem gemeinsamen Gedächtnis. Der Agent würde der neuen Person womöglich aus deinen Unterlagen antworten, oder dir aus ihren. Das ist im besten Fall peinlich und im schlechteren ein Datenschutzproblem.
Die Lösung steckt in einem einfachen Gedanken: Ein Profil pro Person ist ein eigener, abgeschotteter Agent. Jedes Profil hat sein eigenes Gedächtnis, seine eigenen Unterhaltungen und seine eigenen Dokumente. Open WebUI im Browser und Telegram am Handy sind dann nur zwei Türen zu genau diesem einen Profil. Du als Administrator richtest alles ein und behältst den Überblick, jede Person sieht und nutzt nur ihren eigenen Agenten.
Am Ende dieses Teils meldet sich die neue Person mit ihrem eigenen Konto im Browser an und sieht dort nur ihren Agenten, schreibt am Handy ihrem eigenen Telegram-Bot, und beide Türen führen zum selben privaten Gedächtnis. Rechne mit etwa einer Stunde.
Was am Ende läuft
Der Aufbau aus Teil 2 bleibt: ein Docker-Container mit Hermes, davor Open WebUI. Neu ist, dass im selben Hermes-Container jetzt mehrere Profile laufen, eines pro Person. Jedes Profil ist ein vollständig eigener Agent mit eigenem Gedächtnis und eigenem kleinen API-Server auf einem eigenen Port. Open WebUI spricht jeden dieser Agenten als eigene Verbindung an, und jede Person bekommt im Browser genau ihren zugewiesen. Für Telegram bekommt jedes Profil seinen eigenen Bot.
Es bleibt also ein einziger Container, den du startest und sicherst. Die Profile kommen ohne Neuaufbau dazu, und nach einem Neustart fahren sie von selbst wieder hoch.
Schritt 1: Ein eigenes Profil für die Person
Ein Profil legst du mit einem einzigen Befehl an. Wir machen das beispielhaft für eine weitere Person, nennen wir sie Martina (deinen eigenen Namen setzt du natürlich ein). Jede weitere Person bekommt später nach demselben Muster ihr eigenes Profil. Die Befehle sprechen über docker compose exec den schon laufenden Container an. docker compose selbst erwartet dabei, dass du im Projektordner ~/ki-heimserver stehst, in dem die Compose-Datei liegt, deshalb bleibst du für diesen ganzen Teil in diesem Ordner. Die Befehle weiter unten, die mit dem vollen Pfad ~/.hermes/… arbeiten, laufen dagegen von überall:
cd ~/ki-heimserver
docker compose exec hermes hermes profile create martina
Das Profil bekommt damit ein eigenes Verzeichnis unter ~/.hermes/profiles/martina/ mit eigener Konfiguration, eigenem Gedächtnis (MEMORY.md, USER.md), eigenen Sitzungen und eigener .env. Dieses Profil ist Martinas Agent.
Das frische Profil hat noch kein Modell und keinen Schlüssel, und bewusst auch ein leeres eigenes Gedächtnis und eine eigene Persönlichkeit. Von dir wird nichts übernommen, genau richtig für eine eigene Person. Du richtest Martinas Agenten mit demselben Einrichtungs-Assistenten ein wie in Teil 1, nur für ihr Profil:
docker compose exec hermes martina setup
Dort wählst du wie in Teil 1 OpenRouter, fügst einen Schlüssel ein und wählst ein Modell. Den Schritt für Messaging überspringst du hier, Martina bekommt ihren eigenen Telegram-Bot erst in Schritt 5.
Eigenes Budget pro Person (für die Firma)
Beim Einrichten fügst du einen OpenRouter-Schlüssel ein, und welchen du nimmst, entscheidet über das Budget. Nimmst du denselben Schlüssel wie dein Hauptagent, teilen sich alle Profile ein Budget, einfach für einen Haushalt. In einer Firma willst du oft pro Person ein eigenes Limit: Leg dann bei OpenRouter pro Person einen eigenen Schlüssel mit Ausgabe-Limit an und gib genau den im Assistenten ein. So hat jede Person ihr eigenes monatliches Budget, und du siehst bei OpenRouter pro Schlüssel, was verbraucht wird. Auch ein anderes Modell pro Person wählst du einfach im Assistenten.
Damit Open WebUI später mit dem Profil reden kann, braucht es seinen eigenen kleinen API-Server auf einem eigenen Port. Diese Einstellungen sind Umgebungsvariablen und gehören in die .env des Profils. Martina bekommt Port 8650 (die Ports 8644 bis 8646 sind intern belegt, deshalb starten wir bei 8650):
cat >> ~/.hermes/profiles/martina/.env <<EOF
API_SERVER_ENABLED=true
API_SERVER_HOST=0.0.0.0
API_SERVER_PORT=8650
API_SERVER_KEY=$(openssl rand -hex 32)
EOF
API_SERVER_HOST=0.0.0.0 ist wieder der entscheidende Punkt, damit der Open-WebUI-Container den Agenten im Compose-Netz erreicht. Den erzeugten Schlüssel brauchst du gleich in Open WebUI, deshalb liest du ihn dir danach aus der Datei:
grep API_SERVER_KEY ~/.hermes/profiles/martina/.env
Jetzt startest du Martinas Agenten. Im offiziellen Image überwacht s6 jedes Profil als eigenen Dienst, der Slot wird dynamisch registriert, ein Neuaufbau ist nicht nötig:
docker compose exec hermes hermes -p martina gateway start
✅ Checkpoint: Martinas Agent antwortet jetzt containerintern. Prüf das über den Health-Endpunkt auf dem neuen Port:
docker compose exec hermes curl -s http://localhost:8650/health; echo
Du bekommst ein {"status": "ok", "platform": "hermes-agent"} zurück.
Schritt 2: Den neuen Agenten in Open WebUI verfügbar machen
Jetzt machst du Martinas Agenten in Open WebUI bekannt. Das macht der Administrator einmalig. Öffne http://localhost:3000 und klick oben rechts auf dein Profilbild, dann auf Admin-Bereich. Oben in der Reiterleiste wählst du Einstellungen (achte darauf, dass es der Reiter im Admin-Bereich ist, nicht das persönliche Zahnrad im Profil-Menü), links dann Verbindungen. Unter OpenAI-API legst du über das Stift-Symbol eine Verbindung an:
| Verbindung | URL | API-Key |
|---|---|---|
| martina | http://hermes:8650/v1 |
Martinas Schlüssel aus Schritt 1 |
Wie schon in Teil 2 ist die Adresse der Servicename hermes aus der Compose, nicht localhost, und das /v1 am Ende ist Pflicht. Den Port musst du nicht nach außen freigeben, die beiden Container reden über das interne Compose-Netz.
Nach dem Speichern erscheinen im Modell-Dropdown zwei Einträge: dein eigener hermes-agent aus Teil 2 und martina. Beide sind eigene, vollständig getrennte Agenten.
Schritt 3: Ein Konto anlegen und den Agenten zuweisen
Damit Martina nur ihren eigenen Agenten sieht, braucht sie ein eigenes Konto, und du weist diesem Konto genau ein Modell zu.
Konto anlegen. In den Admin-Einstellungen unter Benutzer legst du ein Konto für Martina an (oder du erlaubst die Selbstregistrierung und gibst neue Konten frei, sie stehen sonst auf „ausstehend"). Der erste Account, deiner, ist und bleibt Administrator.
Modell zuweisen. Jetzt kommt die eigentliche Trennung. In den Admin-Einstellungen unter Modelle klickst du beim Modell martina auf das Schloss-Symbol für den Zugriff. Das Modell ist ohnehin schon privat, du hakst Martinas Konto an und fügst es hinzu, damit sie Lesezugriff bekommt. Ab jetzt sieht Martina nach dem Login nur martina im Dropdown. Du als Administrator siehst weiterhin alle, das ist gewollt.
Schritt 4: Private Dokumente für die Person
Jetzt bekommt Martinas Agent seine eigenen Unterlagen. Martina meldet sich mit ihrem Konto an und legt ihre Wissensbasis genau so an wie in Teil 2: über die Seitenleiste → Arbeitsbereich → Wissen → +. Wichtig ist die Sichtbarkeit Privat, die ohnehin voreingestellt ist. Damit sehen andere Nutzer ihre Dokumente nicht.
In Open WebUI sind Wissensbasen und Modelle von Haus aus privat für die Person, die sie anlegt. So füllt jede Person ihren eigenen Agenten mit ihren eigenen Unterlagen, und niemand sieht die der anderen.
Schritt 5: Ein eigener Telegram-Bot für die Person
Die zweite Tür ist Telegram. Martina bekommt ihren eigenen Bot, der zu ihrem Profil führt. Sie holt sich bei @BotFather einen eigenen Bot-Token und kennt ihre Telegram-User-ID (beides wie in Teil 1 beschrieben). Diese Werte trägst du in die .env ihres Profils ein:
cat >> ~/.hermes/profiles/martina/.env <<EOF
TELEGRAM_BOT_TOKEN=martinas-bot-token
TELEGRAM_ALLOWED_USERS=martinas-telegram-id
EOF
Dann startest du Martinas Gateway neu, damit der Bot online geht:
docker compose exec hermes hermes -p martina gateway restart
Für jede weitere Person machst du dasselbe mit ihrem eigenen Bot-Token in ihrer Profil-.env. Jede Person schreibt von nun an ihrem eigenen Bot und landet in ihrem eigenen Profil, mit demselben Gedächtnis wie im Browser. Alle Bots laufen gleichzeitig im einen Container.
Hermes hat dafür ein eingebautes Sicherheitsnetz. Würden zwei Profile versehentlich denselben Bot-Token verwenden, blockiert es das zweite mit einer klaren Fehlermeldung. Jede Person braucht also ihren eigenen Bot.
Der Punkt, der über Familie oder Firma entscheidet
Mit diesem Aufbau sind Gedächtnis, Dokumente und Sicht pro Person sauber getrennt. Für die Familie oder ein vertrautes Team ist das genau richtig: Jeder hat seinen eigenen Agenten, niemand sieht die Unterlagen der anderen, und du als Administrator behältst den Überblick.
Eine Grenze solltest du trotzdem kennen, bevor echte Kundendaten ins Spiel kommen. Profile trennen das Gedächtnis und die Dokumente, sie sind aber kein Datei-Sandbox. Wenn ein Agent Befehle ausführt, läuft das im gemeinsamen Container, und er könnte grundsätzlich auch Dateien außerhalb seines Profil-Ordners erreichen. Für Personen, die einander vertrauen, ist das kein Problem. Sobald du fremde Mandanten oder echte Kundendaten strikt trennen musst, gehst du eine Stufe weiter, mit einem abgeschotteten Terminal-Backend pro Profil oder getrennten Instanzen. An diesem Punkt entscheidet sich, ob ein Setup für die Familie reicht oder ob es für die Firma eine Nummer größer sein muss.
Drei weitere Dinge gehören zu einem sauberen Mehrnutzer-Betrieb, die wir im Produktions-Teil vertiefen: ein vorgeschalteter Reverse Proxy mit HTTPS für den Zugriff von außen, eine richtige Datenbank für die Sitzungsverwaltung, und die Faustregel, dass die Erlaubnis für eigene Werkzeuge gleichbedeutend mit Zugriff auf den Server ist und deshalb nur an Personen geht, denen du vertraust.
Häufige Fallstricke
| Problem | Ursache | Lösung |
|---|---|---|
| Neues Profil-Modell taucht nicht auf | API-Server des Profils nicht aktiv oder falscher Port | API_SERVER_* in der Profil-.env prüfen, docker compose exec hermes hermes -p <name> gateway restart |
| Open WebUI erreicht das Profil nicht | falsche Adresse | URL muss der Servicename mit /v1 sein, also http://hermes:8650/v1, und API_SERVER_HOST=0.0.0.0 muss in der Profil-.env stehen |
| Person sieht fremde oder alle Modelle | Modell-Zugriff nicht eingeschränkt | das Profil-Modell unter Zugriff auf privat stellen und nur dem richtigen Konto Lesezugriff geben |
| Agent findet die zugewiesenen Dokumente nicht | Wissensbasis nicht zugewiesen oder kein Lesezugriff | im Modell die private Wissensbasis der Person zuweisen, Zugriffsrechte prüfen |
| Telegram-Bot eines Profils geht nicht online | gleicher Token in zwei Profilen | jedem Profil einen eigenen Bot-Token geben, dann gateway restart |
| Profil-Agent weg nach Neustart | Gateway war beim Neustart nicht aktiv | nach docker restart kommen nur Profile zurück, die zuletzt liefen, sonst hermes -p <name> gateway start |
Die Serie im Überblick
- Teil 1: Den Agenten als Docker-Container starten und per Telegram aufs Handy holen. Er lernt und merkt sich Dinge von Anfang an.
- Teil 2: Open WebUI als Oberfläche anbinden und abgeschottete RAG-Agenten für Support und Projekte bauen.
- Teil 3 (hier): Mehrere Nutzer sauber getrennt, jede Person mit eigenem Agenten, eigenem Gedächtnis und eigenen Dokumenten.
Was noch kommt (ungefähre Reihenfolge, kann sich noch ändern):
- Der Agent wird proaktiv: eigene Fähigkeiten, E-Mail und automatische Aufgaben wie ein Morgenbriefing.
- Websuche, die du selbst hostest.
- Sprache: einfach reinsprechen statt tippen, der Agent versteht dich (und antwortet vielleicht auch gesprochen).
- Bilder vom Agenten generieren lassen.
- Eigene lokale Modelle, ganz ohne Cloud.
- Ein echtes Wissensgedächtnis: deine Dokumente dauerhaft und durchsuchbar, in jedem Kanal.
- Produktionsbetrieb: sicherer Fernzugriff per HTTPS, Datenbank und Backups.
Wenn du so ein Setup für deine Firma aufsetzen oder die Mehrbenutzer-Trennung sauber aufziehen willst, kannst du mich bei Fragen jederzeit kontaktieren.
Kein Teil der Serie verpassen?
Newsletter abonnieren