Manuel Hartmann ITK Dienstleistungen

Projekt

Olymp

Eine Firma aus Agenten, die um Erlaubnis fragt

Agenten-Plattform mit Zuständigkeiten, Rechtestufen und Freigaben — je Mandant getrennt, Modelle lokal und in der Cloud.

Ausgangslage

KI gab es überall — nirgends als System

Vor Olymp steckte KI an vielen Stellen: in zeitgesteuerten Jobs mit Modellaufrufen, in Chat-Assistenten neben der Warenwirtschaft, in Skripten mit eigenem Schlüssel. Jede Stelle hatte eigene Regeln — oder keine. Wer wissen wollte, was ein Agent gestern getan hat, musste in fünf Protokolle schauen. Wer eine Freigabe wollte, bekam sie an drei Orten auf drei Arten.

Olymp fasst das zu einer Plattform zusammen, die wie eine Firma aufgebaut ist: ein Vorstand je Mandant, Abteilungen mit Zuständigkeit — Buchhaltung, Einkauf, Marketing, Kundenservice, Entwicklung, Systembetrieb — ein Adressbuch, Delegation mit Rückmeldung. Jeder Agent hat einen Namen und eine Persönlichkeit; kundensichtbar ist davon nichts.

Über allem steht eine Regel, die nicht in einem Prompt steht, sondern in der Datenbank: Was unumkehrbar ist, entscheidet ein Mensch. Ein Agent kann eine Buchung vorschlagen, eine Kundenantwort entwerfen, eine Löschung beantragen. Ausführen kann er es nicht — auf keinem Pfad, auch nicht, wenn ein anderer Agent ihn darum bittet.

Die zweite Regel ist die Mandantentrennung. Beide Mandanten nutzen dieselbe Plattform, aber nichts davon ist gemeinsam: eigener Runner unter eigenem Betriebssystem-Benutzer, eigener Tresor für Zugangsdaten, eigene Wissensbasis, eigener Vorstand. Ein Fehler in einem Mandanten kann den anderen nicht erreichen.

Auf einen Blick
Aufbau

Panel, Runner, Gate — und Modelle, die austauschbar sind

Drei Teile, die getrennt laufen: das Panel verwaltet, der Runner handelt, das Gate entscheidet, was der Runner darf. Modelle und Werkzeuge hängen daran wie Steckkarten.

Aufbau der Agenten-Plattform Links das Panel mit Verwaltung, Läufen und Freigabe-Inbox. In der Mitte je Mandant ein eigener Runner, der Aufträge ausführt. Zwischen Runner und Werkzeugen sitzt das Gate mit drei Rechtestufen: Stufe 0 läuft automatisch, Stufe 1 nach Regelwerk, Stufe 2 nur nach Freigabe durch einen Menschen. Rechts die austauschbaren Modelle, lokal und in der Cloud, und die Werkzeuge, die über MCP angebunden sind. Panel Agenten, Modelle Läufe mit Ereignisspur Freigabe-Inbox AiHub, Coder, Wissen Monitoring, Meldungen PHP · MariaDB Runner Mandant A eigener Benutzer eigener Tresor Runner Mandant B eigener Benutzer eigener Tresor HARTE TRENNUNG Gate 0 · automatisch 1 · nach Regelwerk 2 · Mensch entscheidet Modelle lokal (GX10) Cloud per Abo Werkzeuge MCP-Server je Agent freigeschaltet STUFE 2 → ANTRAG IN DER FREIGABE-INBOX DES PANELS
Nicht die Aufgabe entscheidet über die Stufe, sondern die Umkehrbarkeit der Folge.
  1. 01

    Panel

    Verwaltung, Läufe mit lückenloser Ereignisspur, Freigabe-Inbox, Meldekanal. PHP ohne Framework, derselbe Kern wie die Warenwirtschaft.

  2. 02

    Runner je Mandant

    Python-Prozesse unter eigenem Betriebssystem-Benutzer. Ein Runner kann die Zugangsdaten des anderen Mandanten nicht lesen — auch nicht auf demselben Rechner.

  3. 03

    Drei Rechtestufen

    Lesend und umkehrbar läuft automatisch, schreibend nach Regelwerk, unumkehrbar nur nach Freigabe. Die Stufe hängt an der Folge, nicht an der Aufgabe.

  4. 04

    Modell-Router

    Ein Router vor lokalen Modellen und Cloud-Diensten; Modellwahl je Agent, je Gespräch, je Nachricht. Jede Antwort trägt ihr Modell als Kennzeichen.

  5. 05

    Drei Ausführungsarten

    Modelle per Schnittstelle mit eigenem Werkzeug-Protokoll, Claude per Kommandozeile, Codex per Kommandozeile. Die Wahl trifft die Plattform nach Modellart.

  6. 06

    Werkzeuge über MCP

    Fassaden auf die Warenwirtschaft, Dateien, Web, EU-Produktdatenbank, Wissensbasis, SSH, Virtualisierung. Freischaltung je Agent und Stufe — als Datensatz, nicht als Prompt.

  7. 07

    Zugangsdaten aus dem Tresor

    Ein Lauf erhält Verweise, nie Werte. Fehlt ein Schlüssel, bricht der Lauf ab — er läuft nicht mit leerem Passwort weiter.

  8. 08

    AiHub

    Langlebige Gespräche, geräteübergreifend; Themen, Volltextsuche, Freigaben als Karten im Verlauf, Modellwechsel mitten im Thread.

  9. 09

    Coder

    Web-Editor auf registrierten Projekten, jede Speicherung ein Git-Commit, Versionen und Diff im Panel, Aufträge an den Entwicklungs-Agenten.

  10. 10

    Messenger-Bridge

    Discord-Threads werden Gespräche im AiHub — auch Direktnachrichten an den Systembetreuer.

  11. 11

    Monitoring

    Hosts im Minutentakt, Stromaufnahme des Modellrechners über die Steckdose, Korrelation zwischen Agentenläufen und Auslastung.

  12. 12

    Wissensbasis

    Git-Markdown je Mandant mit Vektorindex, Obsidian als Editor für Menschen. Den Prüfstatus eines Dokuments kann kein Agent setzen.

  13. 13

    Push und PWA

    Freigaben und Meldungen aufs Telefon; entschieden wird mit drei Ausgängen — annehmen, ändern, ablehnen.

Integrationen

Woran die Plattform hängt

Modelle

  • Qwen3 (lokal)
  • gpt-oss (lokal)
  • Claude
  • Codex
  • Hermes-Gateway

Infrastruktur

  • Proxmox
  • Ubuntu
  • MariaDB
  • LiteLLM
  • Vaultwarden
  • Gitea
  • Discord
  • Shelly

Werkzeuge

  • ERP-Adapter
  • EPREL
  • Dateien (SFTP, SMB)
  • Web
  • SSH
  • Proxmox-API
  • WinRM
  • Wissensbasis
Was daran schwer war

Drei Vorfälle, die Regeln wurden

  1. 01

    Der stille Totalausfall

    Die Agenten liefen wochenlang leer: Aufträge wurden erzeugt, aber keine einzige von 940 Meldungen erreichte einen Menschen. Kein Fehler im Protokoll — der Zusteller war schlicht nie gestartet worden.

    Lehre: Durchsatz zählen, nicht Fehler. Ein System, das nichts meldet, ist nicht gesund, sondern stumm. Am Artefakt prüfen, nicht an der Erfolgsmeldung →

  2. 02

    Die gerissene Freigabekette

    Eine Freigabe kam an, wurde protokolliert — und nicht ausgeführt. Die Kennung des Mandanten überlebte den Wechsel in einen Ausführungs-Thread nicht; der Aufruf lief mit leerem Kontext und wurde zu Recht abgewiesen.

    Lehre: Eine Schranke, die zu oft fällt, ist genauso ein Fehler wie eine, die nie fällt. Beides wird jetzt gemessen. Ein Ausfall ist kein Urteil →

  3. 03

    Größer ist nicht besser

    Zehn Modelle von acht bis 235 Milliarden Parametern, verglichen an echten Aufgaben aus dem Betrieb statt an Standard-Benchmarks. Bei der Compliance-Prüfung gewann die Mittelklasse, bei Produkttexten das große Modell — das größte brachte nichts, was die kleineren nicht auch konnten.

    Lehre: Messen statt vermuten — und vor „KI dafür einsetzen" die Frage, ob es überhaupt KI braucht. Wie KI hier eingebettet ist →

Woran ich gerade arbeite

Vier Baustellen, nach Priorität

Verweise

Dazu gehört