DoMe Dynamics
AI Agent Systems
Mein Weg

Von der Messtechnik zum AI-Agent Engineering.

Mein Weg zum AI-Agent Engineering begann nicht mit Sprachmodellen, sondern mit technischen Systemen, Sensoren und Messdaten. In der Messtechnik habe ich gelernt, dass Ergebnisse nur dann belastbar sind, wenn sich ihre Entstehung, ihre Bedingungen und ihre Grenzen nachvollziehen lassen. Heute übertrage ich diese Haltung auf KI-Agenten.

1. Technische Systeme verstehen

Die Mechatronik hat mir beigebracht, technische Systeme als Zusammenspiel zu sehen: Mechanik, Elektronik, Sensorik, Software und Regelung greifen ineinander, und ein Fehler zeigt sich selten genau dort, wo er entsteht. Aus dieser Zeit stammt mein Blick auf Schnittstellen, Signale und Zustände.

Zu diesem Blick auf Systeme kam im Studium das erste eigene Programmieren dazu.

2. Programmieren, das mir zunächst fremd blieb

Programmiert wurde im Studium von Anfang an, überwiegend in C und direkt auf Mikrocontrollern. In einem der Projekte haben wir die Signale eines Drehraten-, eines Beschleunigungs- und eines Magnetfeldsensors zusammengeführt und daraus Roll-, Nick- und Gierwinkel berechnet. Fachlich war das nah an dem, was mich interessiert hat, doch der Code selbst blieb mir lange fremd: abstrakt, schwer zu durchschauen und ohne erkennbaren Bezug zu dem, was ich damit eigentlich hätte anfangen können. Ich habe das Programmieren in dieser Zeit eher hinter mich gebracht, als dass ich es gesucht hätte.

Interessant wurde es erst, als ich anfing, Signale nicht nur zu verarbeiten, sondern auszuwerten.

3. Ergebnisse prüfen

In der Messtechnik und der angewandten Forschung wurde daraus ein Anspruch: Ein Ergebnis zählt erst, wenn seine Entstehung, seine Unsicherheiten und seine Gültigkeit geprüft sind. In meiner Master-Thesis habe ich Merkmale aus mikromagnetischen Sensordaten ausgewählt und validiert, mit sauber getrennten Trainings- und Testdaten, GroupKFold gegen Datenleckage und reproduzierbarer Auswertung.

Die Master-Thesis als Nachweis der prüfenden Arbeitsweise

4. Als Programmieren anfing, Sinn zu ergeben

Am Fraunhofer-Institut für Zerstörungsfreie Prüfverfahren habe ich viel mit Messdaten und ihrer Auswertung gearbeitet. Dort habe ich mich in Python eingearbeitet, und zum ersten Mal ergab das Programmieren für mich einen unmittelbaren Sinn: Jede Zeile beantwortete eine Frage an die Daten, die ich ohnehin hatte. Aus einzelnen Auswertungen wurden wiederkehrende Abläufe. Skripte und Notebooks übernahmen Schritte, die ich vorher von Hand wiederholt habe, und machten Ergebnisse vergleichbar.

Im Master habe ich das noch einmal vertieft, in einem Wahlpflichtfach zur Python-Programmierung für Ingenieure unmittelbar vor der Master-Thesis. Dort ist ein größeres eigenes Projekt entstanden, eine Anwendung rund um das Dartspiel. Einzelne Code-Schnipsel habe ich mir damals schon aus einem Chatfenster geben lassen, ohne Zusammenhang und ohne Kontext zum Projekt. Mit der Arbeitsweise, die ich heute nutze, hatte das noch wenig zu tun.

5. Als die ersten KI-Werkzeuge dazukamen

Aus den einzelnen Schnipseln wurde während der Master-Thesis zum ersten Mal eine Arbeitsweise. Ein kurzfristiger Themenwechsel zwang mich, mich in wenigen Wochen in ein Feld einzuarbeiten, das ich vorher nicht kannte. Perplexity habe ich genutzt, um belastbare Quellen und peer-reviewte Veröffentlichungen zu finden. In NotebookLM habe ich diese Quellen gesammelt und mir daraus Zusammenfassungen, Präsentationen und Podcasts erzeugen lassen, um die theoretischen Grundlagen schneller zu durchdringen. Später kamen einzelne Auswertungsskripte dazu, die ich aus einem Chat übernommen und dann selbst angepasst habe.

Entscheidend war dabei nicht, dass ein Modell Text erzeugt hat. Entscheidend war, dass ich die Quellen weiterhin selbst geprüft und die Auswertung selbst verantwortet habe. Aus vier Monaten wurde auf diese Weise ein anderer Arbeitsmodus, und aus der Thesis eine Arbeit, deren Ergebnisse ich offen bis an ihre Grenzen dokumentieren konnte.

Die Fallstudie zur Master-Thesis mit Methodik und Grenzen

6. Erste Arbeit mit Coding-Agenten

Nach der Verteidigung Ende Januar 2026 lag die Arbeit erst einmal ein paar Wochen ruhig. Anfang März habe ich dann angefangen, mit Coding-Agenten zu arbeiten: zunächst einzelne Code-Schnipsel aus Chats, die ich in Notebooks übernommen habe. Ich wollte vor allem schneller entwickeln. Mit der Zeit wurde wichtiger, welchen Kontext ein Agent kennt und was sich davon wiederverwenden lässt.

7. Warum einzelne Chats nicht genügten

Recht früh zeigte sich, dass Geschwindigkeit allein das eigentliche Problem nicht löst. Zusammenhänge gingen zwischen Sitzungen verloren, Arbeitsschritte ließen sich später kaum rekonstruieren, und Wissen lag verstreut in Chatverläufen. Werkzeuge kannten keine Grenzen, Entscheidungen keinen Prüfpfad, bis hin zu einer Test-Suite, die mir die eigene Arbeitsdatenbank leerte.

Der Vorfall und die Grenze, die daraus wurde, im Werkstatt-Log

8. Vom Assistenten zum System

Aus diesen Verlusten sind die Systeme entstanden, die diese Website zeigt. Ein Orchestrator verbindet Eingaben, spezialisierte Skills, Wissensquellen und Freigaben zu einem durchgehenden Arbeitsfluss. Ein Gedächtnis hält Wissen über Sitzungen hinweg auffindbar. Eine Kontrollschicht macht Läufe nachvollziehbar: mit Traces, Audit-Logs und Prüfpunkten, die vor destruktiven Aktionen greifen. Ihre Werkzeuge sprechen die Agenten über MCP an, eine Schnittstelle, über die Agenten Werkzeuge aufrufen.

9. Was aus der Messtechnik geblieben ist

Was aus der Messtechnik geblieben ist, lässt sich am ehesten als Übersetzungstabelle lesen: Für die zentralen Begriffe der Messkette gibt es in der Arbeit mit Agenten eine direkte Entsprechung.

MesstechnikAI-Agent Engineering
MessketteAgenten- und Tool-Kette
SensorzustandSystem- und Agentenzustand
KalibrierungEvaluation und Referenztests
MessunsicherheitModell- und Retrieval-Grenzen
PrüfprotokollTrace und Audit Log
zulässiger BetriebsbereichTool- und Berechtigungsgrenzen
reproduzierbare Messungwiederholbarer Workflow
FehlerdiagnoseObservability und Fehlerpfade

10. Heutige Richtung

Heute entwickle ich in meinem eigenen Lab Systeme, die Aufgaben an KI-Agenten verteilen, Zusammenhänge über Sitzungen hinweg behalten, Wissen wiederfinden, Werkzeuge nutzen und die Arbeit der Agenten kontrollierbar halten. Ich suche ein technisches Umfeld, in dem ich Agentensysteme, AI Adoption oder datenbasierte Engineering-Aufgaben praktisch weiterentwickeln kann: offen für Rollen in AI Engineering, AI Adoption, Data Science und Engineering mit AI-Fokus, in Saarbrücken oder remote.

Mein technischer Hintergrund ist kein früheres Kapitel neben meiner heutigen Arbeit. Er ist die Grundlage dafür, wie ich KI-Agenten denke, entwickle und beurteile.