Erst die Werkzeuge. Dann die Werkstatt. Dann die Frage, warum sie funktioniert.

1. Woher ich komme

Ich komme nicht aus einem klassischen Softwarehintergrund. Im Mechatronikstudium fühlte sich Programmieren lange eher wie eine Hürde an als wie ein Werkzeug. Interessant wurde es erst, als es eine konkrete Frage beantworten konnte: Messdaten am Fraunhofer-Institut, Python als Messinstrument, in der Masterarbeit eine Auswertung, die einer ehrlichen Prüfung standhalten musste.

Die ganze berufliche Linie steht unter Mein Weg

2. Die Dart-App: mein erstes großes Eigenexperiment

Kurz vor der Masterarbeit, in einem Wahlpflichtfach zur Python-Programmierung für Ingenieure, entstand eine ganz andere Idee: eine Dart-App. Eine Kamera sollte erkennen, wo ein Pfeil die Scheibe trifft, und daraus automatisch den Spielstand berechnen. Was als scheinbar überschaubares Projekt begann, führte zu Bewegungsdetektion, Bildvorverarbeitung, Perspektivkorrektur, ArUco- und ChArUco-Markern, Homographien und vielen Versuchen, die Spitze eines Dartpfeils zuverlässig zu lokalisieren.

Die Spiellogik war nicht das eigentliche Problem. Die physische Welt war es. WLAN war zu langsam. Kamerawinkel mussten korrigiert werden. Beleuchtung, Bewegungsunschärfe und die geringe sichtbare Spitze machten die Detektion unzuverlässig. Das Projekt wurde nie so fertig, wie ich es mir vorgestellt hatte.

Gerade deshalb war es wichtig. Die Dart-App war das erste Projekt, bei dem ich nicht nur eine Aufgabe abarbeiten, sondern eine eigene technische Idee in ein System übersetzen wollte. Sie zeigte mir, wie weit man mit Software kommen kann und wo ein Algorithmus an Sensorik, Übertragung und Physik stößt.

3. Als der Zusammenhang fehlte

Während meiner Masterarbeit kamen die ersten KI-Werkzeuge hinzu. Sprachmodelle erzeugten Auswertungsskripte, manchmal Hunderte Zeilen auf einmal. Doch der Zusammenhang fehlte. Sobald ein Chat länger wurde oder ich an einer früheren Stelle weiterarbeiten wollte, begann das Umkopieren. Code wurde neu erzeugt, bereits getroffene Entscheidungen gingen verloren, Fehler tauchten erneut auf. Es funktionierte, aber nur durch viele einzelne Versuche.

Nach der Masterarbeit änderte sich das. Coding Agents konnten nicht mehr nur Text ausgeben. Sie arbeiteten in Repositories, lasen Dateien, führten Tests aus und veränderten ganze Projekte.

Wie diese Phase beruflich verlief, steht unter Mein Weg

4. Die Werkzeuge waren interessanter als die Versprechen

Fast täglich erschienen Videos, Repositories und Demonstrationen mit neuen Werkzeugen, Frameworks und Arbeitsweisen. Die Botschaft war häufig dieselbe: Mit KI werde man zehnmal produktiver, baue schneller ein Business auf und gehöre zu den wenigen, die den Rest des Marktes hinter sich lassen.

Das war nicht der Teil, der mich interessierte. Mich interessierten die Werkzeuge.

Viele Demonstrationen wirkten auf mich irgendwann wie eine Reihe schöner Hämmer und Sägen, mit denen alle dasselbe Regal bauten. Das Regal konnte beeindruckend aussehen. Aber die interessantere Frage war doch: Was passiert, wenn mir nicht nur ein einzelner Hammer gezeigt wird, sondern eine ganze Werkstatt zur Verfügung steht? Was kann ich bauen, wenn ich lerne, all diese Werkzeuge selbst zu benutzen und miteinander zu verbinden?

5. Aus Fragen wurden Repositories

Also begann ich zu bauen. Nicht entlang eines großen Businessplans. Meistens begann es mit einem Satz:

• Was wäre, wenn ein Agent seine Erkenntnisse aus einer Session in die nächste mitnehmen könnte?
• Was wäre, wenn ich Claude über Telegram eine Aufgabe an meinem Rechner geben könnte?
• Was wäre, wenn Claude und Codex nicht nur nebeneinander laufen, sondern Arbeit übergeben, diskutieren und sich gegenseitig prüfen?
• Was wäre, wenn mein Obsidian-Wiki nicht nur Notizen speichert, sondern von Agenten durchsucht, gepflegt, visualisiert und befragt werden könnte?
• Was wäre, wenn es einen absichtlich verrückten Professor gäbe, der ein zu früh konvergiertes Denken wieder aufbricht?

Aus solchen Fragen wurden Repositories. Einige blieben kleine Experimente. Andere wurden archiviert, weil die Idee in dieser Form nicht trug. Manche Agentenschleifen erwiesen sich als reine Token-Verbrennungsmaschinen: Zwei Modelle konnten sehr lange miteinander reden, ohne dass dadurch automatisch ein besseres Ergebnis entstand. Also mussten Aufgaben, Rollen, Rundenzahlen, Abbruchbedingungen und Qualitätskriterien definiert werden.

6. Fehler wurden zu Bauteilen

Nach Datenverlust entstanden Testdatenbanken, Pfadprüfungen und Guards. Nach endlosen Schleifen entstanden Rundenlimits und Circuit Breaker. Nach schwer nachvollziehbaren Agentenläufen entstanden Traces, Statusmodelle und Dashboards. Aus Sessionabbrüchen entstanden Handoffs und Memory-Strukturen. Aus riskanten Werkzeugaufrufen entstanden Freigaben und Blockaden.

So wuchs aus vielen einzelnen Experimenten langsam eine Werkstatt. Agentic OS hielt Entscheidungen, Fehler, Muster und Learnings zwischen Sessions fest. Das Wiki verband Quellen, Projekte und Begriffe. Living-Vault machte denselben Wissensbestand als Graph, Chat und öffentliche Projektion sichtbar. DCO wurde zur Steuerungs- und Beobachtungsschicht für Aufgaben, Telegram, Agenten und Freigaben. Dual Bridge verband Geräte und Modelle über kontrollierte Übergaben. Crazy Professor machte selbst die absichtliche Abweichung zu einem Werkzeug. Und der Agent Memory Atlas kartierte schließlich die Werkstatt selbst: welche Fähigkeiten, Erinnerungen und Projekte es überhaupt gibt. Eine durchsuchbare Landkarte, die meine Agenten heute befragen, bevor sie arbeiten.

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

7. Der minimale Harness

Der entscheidende Aha-Moment kam erst später. Auf einem frisch installierten Ubuntu-Laptop begann ich noch einmal fast bei null. Kein alter Projektkontext, kein gewachsener Stack. Ich wollte verstehen, wie klein ein Agent eigentlich sein kann.

Der erste Harness bestand im Kern nur aus einer Schleife und wenigen Werkzeugen: Dateien lesen, Dateien schreiben und Befehle ausführen. Das Modell erhielt die Beschreibungen dieser Werkzeuge. In jeder Runde konnte es entscheiden, ob es antwortet oder einen strukturierten Werkzeugaufruf erzeugt. Das Ergebnis des Werkzeugs wurde zurück in den Kontext gegeben, und die nächste Runde begann.

Plötzlich ordneten sich die vorherigen Monate neu. Ein Sprachmodell erzeugt zunächst Sprache. Ein Harness gibt bestimmten sprachlichen Ausgaben eine operative Bedeutung. Es stellt Kontext und Werkzeuge bereit, prüft Aufrufe, führt sie aus, liefert Ergebnisse zurück und setzt Grenzen. Aus einer Folge von Text wird dadurch ein Arbeitsprozess.

8. Der Loop schließt sich

Und an diesem Punkt erkannte ich eine strukturelle Parallele zu meiner eigenen Entwicklung: Coding Agents waren zunächst mein Harness. Ich brachte Fragen, Neugier, Sprache, technisches Systemverständnis und die Fähigkeit mit, Ergebnisse zu beurteilen. Was mir fehlte, war die praktische Reichweite in großen Codebasen, Tools und Softwarearchitekturen. Coding Agents machten mir Dateien, Shell, Tests, Repositories und schnelle Rückkopplung zugänglich. Sie nahmen mir das Denken nicht ab. Aber sie senkten die Hürde, Gedanken in ausführbare Experimente zu übersetzen.

Danach begann ich zu verstehen: Erst ein Harness aus Kontext, Werkzeugen, klaren Grenzen und Rückkopplung gibt einem Sprachmodell einen erweiterten, aber begrenzten Handlungsspielraum.

Seitdem versuche ich zu verstehen, wie dieser Rahmen gestaltet sein muss: leistungsfähig genug, um wirklich zu helfen, und begrenzt genug, um nachvollziehbar zu bleiben. Genau daran arbeite ich mit der Werkstatt und dem DCO weiter.

Und während ich lernte, mit meinem eigenen Harness umzugehen, begann ich Harnesses für Agenten zu bauen: Kontextsysteme, Memory, Toolgrenzen, Rollen, Queues, Reviews, Freigaben und Beobachtung. Die Mechanismen sind nicht dieselben. Ein Mensch lernt und verändert sich anders als ein Sprachmodell in einer Toolschleife. Aber die Bedeutung einer guten Werkzeugumgebung wurde mir auf beiden Seiten sichtbar.

Heute interessiert mich deshalb nicht mehr nur, was ein Agent erzeugt. Mich interessiert, welchen Kontext er erhalten hat. Welche Werkzeuge ihm zur Verfügung standen. Welche Zustände das System kannte. Welche Entscheidungspfade möglich waren. Wo ein Mensch eingreifen musste. Und ob das Ergebnis im Nachhinein verständlich, prüfbar und verantwortbar bleibt.

Dynamic DOME ist deshalb keine Sammlung makellos abgeschlossener Produkte. Es ist die sichtbare Spur von Fragen, die ausführbar wurden. Am Anfang wollte ich wissen, was möglich ist. Heute möchte ich verstehen, warum es möglich ist und wie man es so baut, dass es nicht nur beeindruckend, sondern nachvollziehbar bleibt.