Agenten, die deine Apps betreiben

„Wo KI-Agenten deine Anwendungen betreiben“ ist die Richtung von PaaSbox. Wörtlich genommen: Ein Agent, ein Sprachmodell mit Werkzeugen, erledigt die Betriebsarbeit an einer laufenden App, etwa ihren Zustand prüfen, ihre Logs lesen, ein Backup ziehen, nachweisen, dass sich das Backup wiederherstellen lässt, und ein Upgrade fahren. Das tut er nur über die Aktionen, die der Katalogeintrag der App festlegt, eine Person gibt die Aktionen frei, die der Eintrag als freigabepflichtig markiert, und jeder Aufruf wird festgehalten.

Der Stand, kurz:

• Gebaut Im Labor: typisierte Aktionen pro App als MCP-Tools, Ablehnungen und Freigaben, ein Audit-Log, und ein Agent auf einem kleinen Modell, der vier Apps über ihre Betriebs-Skills betreibt.
• In Arbeit Eine REST-API und MCP-Tools für PaaSbox Clusters, mit denen ein Agent deine Cluster liest, Snapshots auslöst und Upgrades plant.
• In Arbeit Ein Lese-Proxy, der Agenten kubectl zum Lesen gibt und Secret-Werte schwärzt.
• Geplant Ein Betriebs-Agent, der nach eigenem Zeitplan läuft, Prüfungen vor jedem Update, Live-Zahlen aus echtem Betrieb und der Betrieb von Apps durch Agenten als eigener Dienst.

„Im Labor“ heißt: virtuelle Maschinen auf einem Mac mit einem echten Kubernetes-Cluster. Nichts auf dieser Seite ist ein Produktionsergebnis, und heute wird kein KI-automatisierter Betrieb verkauft.

Nicht dieser Agent: pbx-agent

pbx-agent, der Agent auf einem Node von PaaSbox Clusters, ist ein Programm, kein KI-Modell. Er führt eine feste Liste von Operationen aus, die ihm das Portal übergibt, etwa einen Snapshot, eine Wiederherstellung oder ein Upgrade, und sonst nichts. Das Wort „Agent“ meint auf dieser Seite einen KI-Agenten.

PaaSbox Clusters für Agenten

In Arbeit Ein Agent kann PaaSbox Clusters über eine REST-API und MCP-Tools anlegen, prüfen und löschen, mit einem Schlüssel, der nur die Scopes trägt, die du ihm gibst: Einem Agenten Zugriff geben hat die Schritte, und Leitplanken für Agenten, was ihn begrenzt.

Kleine, isolierte Cluster

Warum die Änderung eines Agenten in einem Cluster getestet wird, der für den Test gebaut ist, und warum jede Stage und App einen eigenen kleinen Cluster bekommt, steht auf Warum isolierte Cluster für Agenten.

Wie ein Agent heute handelt

Jede App im Katalog hat einen Eintrag, und der Eintrag legt fest, was mit der App getan werden darf, als typisierte Aktionen: ein Name, ein Titel, typisierte Parameter, und ob die Aktion destruktiv ist. Gekürzt, aus dem Eintrag von Forgejo:

operations:
  actions:
    - name: reset-mfa
      title: Remove a user's two-factor authentication
      kind: job
      danger: true
      params: {username: {type: string}}
      command: [forgejo, admin, user, reset-mfa, --username, "{username}"]
agent:
  mcp: {server: actions}
  skills: [skills/operate-forgejo]
  routines:
    - {name: update-check, schedule: "0 6 * * 1", skill: operate-forgejo, tools: write, approval: true}

Gebaut Im Labor:

• Der Actions-Server stellt einem Agenten die Aktionen einer App als MCP-Tools bereit, und sonst nichts: keine Shell, keine schreibenden kubectl-Befehle. Parameter werden gegen ihre Typen geprüft, bevor etwas läuft.
• Destruktive Aktionen warten auf eine Person. Der Server lehnt sie ab, außer er wurde von einem Client gestartet, der zuerst eine Person fragt. Im Labor vertritt ein simulierter Freigeber diese Person, und seine Antworten werden aufgezeichnet.
• Jeder Aufruf landet in einem Audit-Log, auch die abgelehnten: die Aktion, ihre Parameter, die Begründung, die der Agent für eine schreibende oder destruktive Aktion angeben muss, und das Ergebnis.
• Der Betriebs-Skill sagt dem Agenten, wie er diese App betreibt: welche Aktion welche Frage beantwortet, und was er davor und danach prüft.
• Das Harness lässt den Agenten die laufende App über ihren Skill und dessen Evals betreiben, zeichnet die Freigaben auf, um die er gebeten hat, und bewertet den Lauf.

Die Routinen, die ein Eintrag festlegt, etwa ein wöchentlicher Restore-Drill, eine wöchentliche Update-Prüfung und ein täglicher Zustandsbericht, sollen Geplant nach Zeitplan laufen; heute läuft ein Agent, wenn eine Person ihn startet.

Die vier Dinge, die Vertrauen verdienen

Einen Agenten an die Produktion zu lassen, ist eine Frage des Vertrauens. Vier Dinge verdienen es, und jeder Teil von PaaSbox gehört zu einem davon.

1. Leitplanken: Ein Agent kann nur, was er darf, und du siehst, was er tut

• Gebaut Jeder Befehl gibt einen JSON-Plan aus, bevor sich etwas ändert, und meldet seinen Fortschritt typisiert als JSON.
• Gebaut Typisierte Aktionen pro App als MCP-Tools: Destruktive werden abgelehnt, solange sie nicht erlaubt sind, Freigaben, wo der Eintrag eine verlangt, jeder Aufruf im Audit-Log. Im Labor.
• Gebaut Netzwerkregeln, erzeugt aus den Verbindungen jeder App, im Labor.
• In Arbeit Ein Lese-Proxy: Agenten behalten kubectl zum Lesen; Secrets werden verweigert, Secret-Werte in jeder Antwort und jeder Logzeile geschwärzt, und jeder Lesezugriff wird festgehalten. Gebaut auf einem Branch und getestet auf einem Wegwerf-Cluster.
• Geplant Ein Betriebs-Agent, der nur darf, was eine Person in Rufbereitschaft darf.

2. Getestete Änderungen: Nichts erreicht die Produktion ungetestet

• Gebaut GitOps: Jede Änderung ist ein Commit, gerendert aus einer Datei pro Suite von Apps.
• Gebaut Ein Upgrade mit Rollback für jeden der vier Golden Entries, mit geprüften Daten, im Labor.
• Geplant Staging, eine Promotion-Strecke, Prüfungen vor jedem Deployment und Update, ein schrittweiser Rollout. Die Änderung eines Agenten durchläuft dieselben Prüfungen wie deine.

3. Betrieb eingebaut: Jede App kommt betriebsbereit

• Gebaut Apps, verbunden mit ihrer Datenbank und ihrem Cache, mit Zugangsdaten, die keine andere App lesen kann, im Labor.
• Gebaut Backups mit getestetem Restore: in eine Wegwerf-Kopie wiederhergestellt und ein Datenmarker zurückgelesen, für jeden Golden Entry, im Labor.
• Gebaut Ein Betriebs-Skill pro Golden Entry, mit dem ein Agent die laufende App betreibt.
• Geplant Monitoring und Alarme pro App, gespeist aus den Metriken der Plattform.

4. Offen gemessen: Aus der Behauptung wird eine Zahl

• Gebaut Die Laborrunde vom 2026-10-09, unten.
• Geplant Live-Zahlen aus dem eigenen Betrieb von PaaSbox: der Anteil der Aufgaben, die Agenten erledigt haben, Wiederherstellungszeit, Fehlerquote von Änderungen, Restore-Drills, gemessene Verfügbarkeit.
• Geplant Nachweise für Controls nach CIS und BSI IT-Grundschutz; was sie belegen, entscheidet deine Prüferin oder dein Prüfer.

Die Laborrunde vom 2026-10-09

Am 2026-10-09 liefen die vier Golden Entries, Forgejo, Vaultwarden, Listmonk und Umami, durch jede Laborzeile im Mac-Labor: Installation, Zugangsdaten, Netzwerkregeln, Konfiguration, Aktionen, Alarm, Restore-Drill, Upgrade, der Skill-Lauf des Agenten und eine zweite Installation.

• Vaultwarden, Listmonk und Umami bestanden jede ihrer Zeilen; die Alarm-Zeile wurde übersprungen, wo der Katalog das erlaubt.
• Forgejo bestand 12 von 13 Zeilen. Seine Alarm-Zeile kann erst bestehen, wenn die Plattform die Metriken der App sammelt. Im Labor hat noch kein Alarm ausgelöst.
• Absichtlich kaputte Einträge scheitern an der richtigen Zeile: Zugangsdaten, die nicht an die App weitergegeben werden, scheitern an der Bindungs-Zeile, ein Backup ohne das Volume der App scheitert am Restore-Drill, ein Skill, der eine fehlende Aktion nennt, scheitert an der Skill-Zeile.
• Der Agent ist günstig im Betrieb: Claude Haiku betrieb jede laufende App über ihren Betriebs-Skill; die Skill-Zeilen kosteten 0,058 $ an Modellkosten über 12 aufgezeichnete Läufe.
• Noch offen: ein abschließender vollständiger Lauf jedes Eintrags auf einem frischen Node, dieselbe Runde in einem Hetzner-Laborprojekt und ein Alarm, der tatsächlich auslöst.

Offen betrieben hat die Tabelle, Zeile für Zeile.

Was geplant ist

• In Arbeit Der Lese-Proxy bekommt eine eigene Laborzeile, deren Negativkontrolle ein bekanntes Secret in eine Logzeile, einen Umgebungswert und eine ConfigMap legt und prüft, dass es den Agenten nie erreicht. Im Labor kann ein Agent dann direkten Zugriff oder Zugriff über den Proxy bekommen, und die beiden Diagnosen werden verglichen.
• Geplant Ein Betriebs-Agent. Er liest über den Lese-Proxy und die Metriken und Logs der Plattform, handelt nur über die typisierten Aktionen der Einträge und wartet auf eine Person, wo eine Aktion destruktiv oder freigabepflichtig ist. Zuerst betreibt er die Cluster von PaaSbox selbst.
• Geplant Update-Prüfungen: Prüfungen, die ein Update bestehen muss, bevor es eine laufende App erreicht, für die Änderung eines Agenten dieselben wie für deine.
• Geplant Der Betrieb von Apps durch Agenten als eigener Dienst: Agenten betreiben deine Apps unter der Freigabe einer Person, berechnet pro Cluster plus pro betriebener App. Das wäre ein eigenes Angebot: PaaSbox Clusters ist Software, mit der du deine Cluster betreibst, kein Managed Service. Noch ohne Preise und ohne Datum.
• Geplant Eine Demo in deinem eigenen Hetzner-Testprojekt: ein kleiner Cluster, zwei Apps und dein eigener Agent, der behebt, was ein Szenario kaputt macht, über typisierte Aktionen und mit deiner Freigabe, und ein Kurs, der darauf aufbaut. Beides ist nicht buchbar.

Die Teile, die die Behauptung überprüfbar machen, sollen offen sein: der Action-Runner, der Actions-Server, der Lese-Proxy, das Harness und die vier Golden Entries. Sie sind für die dritte Veröffentlichungswelle geplant. Die offenen Komponenten listet sie mit ihren Lizenzen.

Wie PaaSbox selbst mit Agenten gebaut wird

Ich baue PaaSbox selbst mit Agenten. Sie schreiben Code nach einer schriftlichen Spezifikation, fahren die Laborzeilen und Drills, prüfen Abhängigkeiten und Images und entwerfen die Analyse, wenn etwas kaputtgeht. Was sie abliefern, ist ein Pull Request, ein Laborprotokoll oder ein Ticket. Ich entscheide, ich merge, und ich bin der Einzige, der ein laufendes System anfasst. Offen betrieben hat die Charta.

Offen betriebenDie Laborrunde Zeile für Zeile, die Agenten-Charta und was veröffentlicht wird.

Die offenen KomponentenDer Katalog, der Action-Runner, der Lese-Proxy und das Harness, mit Lizenzen und Wellen.