Wie ich arbeite

LeitplankeLeitplanken

Ich arbeite gerne mit Agenten. Aber sie brauchen klare Grenzen.

Regeln, die greifen

Ein Hook stoppt gefährliche Befehle.

Dafür nutze ich eigene Sicherheits-Hooks und ein Policy-Gate. Ein Hinweis im Prompt reicht mir nicht. Auch diese Kontrollen können Fehler haben. Deshalb prüfe ich sie nach Änderungen.

Ich gebe frei

Veröffentlichungen, Löschungen und Nachrichten an andere Menschen brauchen meine Freigabe.

Änderungen dürfen Agenten vorbereiten und über das Review-Gate nach main bringen. Wenn eine Aktion nach außen wirkt, entscheide ich selbst.

So wenig Rechte wie nötig

Sandboxes bekommen keine Schlüssel und keinen Root-Zugriff. Auch keinen Docker-Socket.

Ein Worker darf sich keine zusätzlichen Rechte nehmen. Braucht eine Sandbox etwas, ergänze ich gezielt Pakete oder erlaube ihr, bestimmte Dateien zu lesen. Geheimnisse dürfen nicht ins Repository und nicht in die Ausgabe.

Reviews vor main

Zwei Modelle prüfen einen Commit, bevor er nach main kommt.

Die beiden Modelle kommen von unterschiedlichen Anbietern. Sind sie sich uneinig, schaut noch ein weiteres darauf. Bei einem BLOCK kommt die Änderung erst durch, wenn der Einwand geklärt ist.

Nachvollziehbar

Ich protokolliere, was läuft, und halte Entscheidungen mit Datum fest.

Zu einer Entscheidung schreibe ich auf, was dazu geführt hat. Taucht ein Fehler wieder auf, mache ich daraus eine Regel mit einem Kommando zum Prüfen. Für die nächste Sitzung steht der Arbeitsstand in einer Übergabe.

Kosten mit Deckel

Bezahlte Aufrufe haben feste Grenzen im Broker.

Beim Routing kommen Abonnements zuerst. Der Broker schaut, wie viel Kontingent noch übrig ist, und begrenzt bezahlte Aufrufe pro Tag und pro Abrechnungsfenster. Die Grenze greift im Broker selbst.

Grenze: Die Umgebungen für Reviews laufen noch ohne Sandbox auf Betriebssystem-Ebene. Darum muss ich mich noch kümmern.

Stand: November 2026

Agents Do, Humans Decide.

Ja, die Anfangsbuchstaben sind Absicht.

Rollen

Routing

Bevor ein Agent loslegt, wählt ein Broker Modell und Werkzeug aus. Er schaut auf Kosten, restliches Kontingent und frühere Fehler. Abonnements kommen zuerst. Ist ein Zugang ausgeschöpft, fällt er aus der Auswahl.

Entscheidungen

Routineentscheidungen treffen die Agenten selbst. Bei Entscheidungen mit größeren Folgen wägen mehrere Modelle in einem Council die Möglichkeiten ab und schreiben die Begründung auf.

Review

Soll ein Commit nach main, prüfen ihn zwei Modelle von unterschiedlichen Anbietern. Sind sie sich uneinig, schaut noch ein weiteres Modell darauf. Bei einem BLOCK kommt die Änderung erst durch, wenn der Einwand geklärt ist.

Übergaben

Claude, Codex, Pi und Antigravity schreiben sich über ein MCP-Postfach. Wechselt das Werkzeug oder fängt eine neue Sitzung an, steht der bisherige Kontext in einem Übergabedokument.

Womit ich gearbeitet habe

2008 habe ich mit Qualitätssicherung und Systemadministration angefangen. Seitdem sind DevOps, Cloud-Plattformen und die Arbeit mit KI-Agenten dazugekommen.

Qualitätssicherung

Ich habe Testpläne geschrieben, Lasttests laufen lassen und Software beim Kunden ausgeliefert.

Systemadministration

Ich habe Linux-Systeme und virtuelle Maschinen am Laufen gehalten und sie mit Nagios und Icinga überwacht.

Telefonie und Integration

Ich habe SIP und CTI an Kollaborationsplattformen angebunden.

DevOps

Ich habe Systeme von Docker Swarm auf Kubernetes umgestellt und die Abläufe mit Terraform, Ansible und CI/CD automatisiert.

Observability

Mit Prometheus, Grafana und ELK habe ich im Blick behalten, wie die Systeme laufen.

Secrets und Zugriff

Ich habe Geheimnisse mit HashiCorp Vault verwaltet und den Zugriff über Reverse Proxies geregelt.

Cloud-Architektur

Ich entwerfe Plattformen auf Azure und arbeite mit AKS, Infrastructure as Code und GitOps.

Dokumentation (DocOps)

Ich pflege Wikis und Runbooks und halte Entscheidungen mit Datum fest.

Kostenkontrolle (FinOps)

Ich lege Budgets fest, die begrenzen, was Modellaufrufe kosten dürfen.

Sicherheit im Alltag (DevSecOps)

Ich baue Guard-Hooks ein, begrenze den Zugriff und lasse Änderungen prüfen, bevor sie nach main kommen.

KI-Agenten

Ich verteile Aufgaben, prüfe die Ergebnisse und lasse mehrere Modelle Entscheidungen abwägen.

Stand: November 2026

PrüfungWo die Grenzen liegen

• Die Umgebung habe ich für mich gebaut. Ob sie in einem Team oder für Auftraggeber funktioniert, habe ich nicht geprüft.
• Auch ein Review kann einen Fehler übersehen. Tests und meine eigene Prüfung bleiben nötig.
• Wenn das Policy-Gate selbst einen Fehler hat, schreibt es ihn ins Protokoll. Die Aktion kann dann trotzdem durchgehen.
• Ob ich damit Kosten spare, kann ich nicht mit Messungen belegen.
• Nach einem Werkzeug-Update hat ein Guard einmal nichts mehr getan. Das blieb so, bis ich den Fehler gefunden und behoben hatte. Die Kontrollen selbst muss ich also auch prüfen und pflegen.