Dominic MeiserIch komme aus der Mechatronik und der datenbasierten Forschung. Heute entwickle ich Systeme für die kontrollierte Arbeit mit KI-Agenten.

Meine heutige Arbeit mit KI-Agenten ist kein getrenntes Thema neben meinem bisherigen Werdegang. Sie setzt eine Arbeitsweise fort, die mich bereits in der Mechatronik, der Messtechnik und der angewandten Forschung begleitet hat.

Dort habe ich Messsysteme aufgebaut, Sensordaten ausgewertet und Verfahren entwickelt, mit denen sich große Merkmalsräume methodisch prüfen lassen. Dabei musste ich stets unterscheiden, ob ein Ergebnis nur auf den vorhandenen Daten gut aussieht oder auch unter sauber getrennten Bedingungen besteht. Bei KI-Agenten stellt sich dieselbe Frage. Ich möchte wissen, welchen Kontext ein Agent verwendet hat, welche Werkzeuge er aufrufen durfte und wie sich seine einzelnen Schritte später prüfen lassen.

Angefangen habe ich Anfang März 2026, und zwar nicht mit einem System, sondern mit einzelnen Code-Schnipseln, die ich aus Chats in Notebooks übernommen habe. Mit den Agenten wollte ich zunächst vor allem schneller entwickeln. Dabei zeigte sich jedoch recht früh, dass Geschwindigkeit allein nicht das eigentliche Problem löst: Zusammenhänge gingen zwischen Sitzungen verloren, Ergebnisse ließen sich später nur schwer rekonstruieren, und ein Agent konnte eine Aufgabe für abgeschlossen halten, obwohl eine unabhängige Prüfung noch Fehler fand.

Die Softwareseite dieser Arbeit habe ich nicht aus einer klassischen Entwicklerlaufbahn mitgebracht. Ich habe sie mir an genau diesen Problemen erschlossen und versucht, die methodische Strenge aus der Messtechnik beizubehalten. Aus dieser Haltung und aus den ersten Verlusten ist die Frage entstanden, die seitdem hinter allem steht.

Zweimal hat mir die eigene Test-Suite eine produktive Datenbank geleert. Es gab keinen Angriff und keinen spektakulären Moment — nur zweimal denselben stillen Verlust. Ein Audit über den Stack benannte diese Lücke anschließend als die größte offene.

Daraus habe ich eine Entscheidung abgeleitet: Befehle, die Daten zerstören können, werden geprüft, bevor sie laufen. Seitdem sitzt ein Hook (ein Prüfpunkt, der automatisch vor einer Aktion läuft) zwischen der Planung eines Agenten und der Ausführung. Er erkennt destruktive Muster, stoppt den Aufruf und protokolliert jeden Treffer.

Die erste Fassung war allerdings zu streng. Sie blockierte einen harmlosen Review-Auftrag, weil rm -rf darin nur als zitierter Text vorkam — Daten sahen für die Prüfung aus wie Befehle. Seitdem werden zitierte Textteile vor dem Abgleich ausgeblendet, und geprüft wird nur der eigentliche Befehl.

Geblieben ist eine feste Grenze mit ehrlichen Lücken. Der Hook ist ein Musterabgleich, kein vollständiger Schutz, und er ersetzt keine Reviews. Was er grundsätzlich nicht erkennen kann, habe ich dokumentiert.

Ich beginne selten mit der größtmöglichen Architektur. Zunächst versuche ich zu verstehen, welches konkrete Problem ein neuer Baustein lösen soll und ob sich der Aufwand dafür überhaupt lohnt. Danach baue ich die kleinste nutzbare Schicht und prüfe sie an einem echten Ablauf, bevor die nächste Stufe folgt.

Dabei verlasse ich mich nicht darauf, dass ein Agent seine eigene Arbeit für abgeschlossen hält. Änderungen werden am Code, an Tests oder an Messwerten überprüft. Bei kritischen Pfaden trenne ich die Umsetzung von einer unabhängigen Gegenprüfung, weil gerade dort Fehler durch mehrere interne Kontrollen hindurchkommen können. Wo etwas unklar bleibt, gehe ich reversibel vor, damit sich jeder Schritt wieder zurücknehmen lässt.

Was funktioniert, bleibt als wiederverwendbarer Ablauf erhalten. Was wiederholt schiefläuft, wird nach Möglichkeit zu einer festen Grenze, einem Hook (einem Prüfpunkt, der automatisch vor oder nach einer Aktion läuft) oder einem dokumentierten Muster. Dadurch wächst die Werkstatt nicht nur um weitere Projekte — sie verändert auch die Art, wie ich die nächsten baue.

Seit Juli arbeitet die Werkstatt zum ersten Mal für ein Ziel außerhalb ihrer selbst. job-radar, eine kleine lokale Anwendung, durchsucht die öffentliche Jobsuche der Bundesagentur für Arbeit, bewertet die Treffer gegen mein Profil und entwirft Anschreiben. Gebaut ist sie mit den Bausteinen und der Arbeitsweise dieser Werkstatt: eng geschnittene Arbeitspakete, eine getrennte Gegenprüfung und sauber isolierte Testdaten. In zwei realen Läufen hat sie 84 Stellen eingesammelt und drei Anschreiben-Entwürfe erstellt. Abgeschickt habe ich davon nichts automatisch — die Entwürfe bleiben Entwürfe, und die eigentliche Bewerbung bleibt Handarbeit.

Damit schließt sich der Bogen dieser Seite. Aus der prüfenden Haltung wurden Systeme, aus den Systemen eine Arbeitsweise — und die arbeitet jetzt an meinem nächsten Schritt.