Agents, Harness, Betrieb

Repository, Rollen, Plan

Der Agent bekommt das Repository statt eines Prompts: die Conventions-Datei, die Expert Subagents mit ihrer Domäne, die erlaubten Tools und einen Plan, der so konkret ist, dass eine falsche Annahme schon auf dem Papier auffällt. Was er meldet, prüft der Check: Build, Tests, Delta, Digest auf der Box, eine Behauptung ist nie der Beleg. Was unbeaufsichtigt läuft und was auf einen Menschen wartet, steht pro Environment vor dem ersten Lauf fest.

Harness, Skills, Hooks

Jede Session schreibt zurück, was sie gelernt hat: Eine Korrektur wird zur Regel, ein Ablauf wird zum Skill mit seinen Failure Modes daneben, ein Incident wird zur Zeile im Lessons Log neben dem Code. Guard Hooks setzen die Grenzen durch. Was zur Codebase gehört, bleibt im Repository, was allgemein gilt, wandert in die Library für andere Projekte. Sie bekommen alle Anwendungen im Source Code, Backups ab dem ersten Tag und ein Log aller Gespräche.

Worktime, Secrets, Dashboard

Das Ergebnis läuft im eigenen Betrieb: Worktime führt den Time Ledger und die Verrechnung über einen eigenen MCP Server, Secrets hält Konfigurationswerte und Schlüssel an einer Stelle, aus der Deployments lesen, und das Kunden-Dashboard läuft als Portal auf der Hetzner Box. Die Azure- und Hetzner-Skills dieser Praxis fahren dafür das CI/CD, von der GitHub-Actions-Pipeline bis zum Blue/Green Deploy.

Verlauf lückenlos

jedes Gespräch mit dem Agenten wird zusammen mit dem entstandenen Code aufbewahrt

Sie geben frei

ein Vorschlag wartet auf Ihre Freigabe, bevor er in ein Live-System geschrieben wird

Jede Zahl belegt

jede Zahl auf der Rechnung führt zurück zu einer echten, erfassten Arbeitssitzung

Seite bestätigt live

die öffentliche Seite bestätigt ein Update, bevor es als live gilt

Vom Plan zum verlässlichen Betrieb

Bestandsaufnahme & Plan 3 Schritte

Erst verstehen, dann loslassen

Bevor die AI eigenständig arbeiten darf, wird zuerst alles aufgeschrieben, was es über den Betrieb zu wissen gibt: was heute läuft, wo, welche Datenbanken es gibt und wie die Zugänge funktionieren. Ein offener Punkt wird als offen markiert statt geraten, und ein Passwort wird nur beschrieben, wo es liegt, nie ausgeschrieben. Am Ende steht ein Dokument, an dem die nächste Sitzung weiterarbeitet.

Arbeit in Rollen aufgeteilt

Die Arbeit wird aufgeteilt wie in einem kleinen Team: eine Rolle schreibt, eine prüft, eine überträgt, eine recherchiert, eine veröffentlicht, jede mit eigenem Auftrag. Eine Prüfung entscheidet, ob nachgebessert wird, aber höchstens zweimal, damit keine Schleife endlos läuft. Die volle Aufmerksamkeit der AI geht dorthin, wo wirklich Urteilsvermögen gefragt ist.

Erst planen, dann handeln

Jede Aufgabe bekommt dieselbe klare Form, bevor sie beginnt, damit eine falsche Annahme schon auf dem Papier auffällt und nicht erst beim Bauen. So sind zum Beispiel die 83 Lektionen der Business-Class geschrieben. Dieselbe Sorgfalt gilt für eine Anfrage: Erst wird der Code angeschaut, dann trägt die Anfrage die echte Datei statt einer Vermutung.

Eingebautes Wissen 3 Schritte

Die Absicherung ist Teil der Arbeit

Die Absicherung, die die Schulung lehrt, ist selbst im Einsatz: eigene Spezialisten für jeden Bereich, ein Team, das jede Änderung automatisch aus drei Blickwinkeln prüft, und feste Hausregeln, an die sich die AI halten muss. Alles davon ist live in den Lektionen im Einsatz. Jede Anweisung steht an genau einer Stelle, und die Arbeit läuft damit zuverlässig ab.

Aus jedem Fehler eine Regel

Jeder Fehler, der einmal passiert, wird zu einer Regel, die die AI nicht mehr brechen kann. Ein Beispiel: Wenn Domain-Einträge aktualisiert werden, würde ein vergessener Eintrag sonst stillschweigend gelöscht, deshalb wird vorher automatisch eine Sicherungskopie gemacht. Eine wiederkehrende Aufgabe kann als einfacher Button in Microsoft 365 an die Fachabteilung gehen, ohne technisches Werkzeug.

Regeln, die sich selbst durchsetzen

Die Hausregeln werden automatisch durchgesetzt statt nur aufgeschrieben und gehofft. Eine Prüfung am Ende stellt sicher, dass nichts durchrutscht. Eine Langzeit-Variante kann die Ladezeit der Website regelmäßig von selbst messen, mit engen Grenzen, was sie dabei anfassen darf, damit unbeaufsichtigt nichts Riskantes passiert.

Im eigenen Betrieb im Einsatz 2 Schritte

Zwei eigene Werkzeuge im Alltag

Zwei eigene Werkzeuge dieser Praxis laufen hier wirklich im Alltag, nicht nur als Beispiel. Eines erfasst Arbeitszeit und macht daraus die Abrechnung. Das andere hält jedes Passwort und jede Einstellung an einem sicheren Ort, aus dem jedes andere System automatisch liest, statt dass jemand von Hand kopiert.

Jedes Update beweist sich selbst

Bevor ein Update als live gilt, muss es sich beweisen: Was jetzt läuft, wird mit dem verglichen, was live gehen sollte, und am Ende wird geprüft, ob die Website auch wirklich antwortet. Das ist wichtig, denn einmal sah alles gesund aus, während die Seite trotzdem 25 Stunden nicht erreichbar war, bis jemand genauer hinsah.

Betrieb sichtbar und verrechnet 2 Schritte

Der ganze Betrieb auf einen Blick

Ein eigenes Dashboard zeigt den ganzen Betrieb auf einen Blick: welche Anwendung läuft, ob sie erreichbar ist, wie sie eingestellt ist, und was im Arbeitsprotokoll steht. Es läuft selbst produktiv, im gleichen Erscheinungsbild wie die öffentliche Website, nicht nur als Muster.

Ehrlich testen, ehrlich abrechnen

Was tatsächlich getestet wurde, wird ehrlich gezeigt, und was ungetestet blieb, steht offen als Lücke da, statt so zu tun, als wäre alles geprüft. Die Rechnung baut auf den erfassten Arbeitszeiten auf, jede Zahl darauf lässt sich auf eine echte Sitzung zurückführen.

Häufige Fragen

Entsteht dabei nur Anwendungscode?

Dasselbe Harness erzeugt Kurs- und Class-Material zu jedem Thema, über eine Factory, die Folien mit Overflow-Prüfung setzt, Narration pro Folie generiert, kommentierte Fotos zusammensetzt und Avatar-Video rendert. Multimedia entsteht über einen Media Service mit zwei Schnittstellen: über HTTP für das, was ein Mensch klickt, und über MCP für das, was ein Modell aufruft. Es entsteht auch Output für den Betrieb, darunter die Verrechnung, neu aufgebaut aus dem erfassten Time Ledger.

Wie wird das Verhalten eines Agents in einem echten Repository begrenzt?

Über Hooks und Gates. Ein Guard Hook begrenzt die Instruction-Datei auf 90 Zeilen, damit sie kurz genug bleibt, um bei jedem Turn gelesen zu werden, ein zweiter druckt bei jedem Prompt die Skill-Liste, und dahinter sitzt ein Verification Gate. Wo ein Tool nicht umkehrbar ist, kommt ein Approval Gate davor: Die Übung zum governed MCP übergibt einen laufenden Server mit sechs Tools, davon einem Destructor, und verlangt Boundary Rules plus einen Stresstest gegen adversariale Prompts.

Darf ein Modell direkt in ein laufendes Geschäftssystem schreiben?

Ein Draft Tool liefert ein interaktives Formular zurück, das im Chat Client gerendert wird, vorbefüllt mit dem, was das Modell vorgeschlagen hat. Das Modell selbst hat kein Schreib-Tool, und das Speichern läuft über einen eigenen Weg, den die Person vor dem Formular auslöst. Read-only-Integrations bleiben read-only, und ein Skill nennt die git-ignorierte Datei, die einen Wert hält, statt des Werts.

Wie beweist ein Deploy, dass tatsächlich etwas live gegangen ist?

Er vergleicht den eben gepushten Digest mit dem Image auf der Box, vergleicht die Image-Id des laufenden Containers mit diesem Image und schließt mit der Prüfung, ob der öffentliche Hostname antwortet; einen unveränderten Digest meldet er als bewusste No-op. Dieselben Prüfungen gibt es auch außerhalb eines Deploys über die Health- und Identity-Endpoints, die Frage lässt sich also jederzeit stellen.