Wenn ich meinen heutigen Arbeitsalltag mit dem vergleiche, was ich viele Jahre unter Softwareentwicklung verstanden habe, hat sich nicht nur das Werkzeug verändert. Früher bestand ein erheblicher Teil meiner Arbeit darin, Anforderungen zu verstehen, Architektur zu entwerfen, Code zu schreiben, Fehler zu suchen und Anwendungen weiterzuentwickeln. Heute beschäftige ich mich immer häufiger mit einer anderen Frage: Wie muss ich Arbeit beschreiben, strukturieren und orchestrieren, damit ein KI-System sie möglichst selbstständig übernehmen kann, ohne dass ich dabei die Kontrolle über fachliche Entscheidungen, Qualität und produktive Änderungen verliere?
Damit bewege ich mich zunehmend in Richtung agentischer Systeme. Der Übergang war allerdings keineswegs geplant. Ich habe nicht irgendwann beschlossen, jetzt Entwickler für Multi-Agent-Systeme zu werden, sondern bin schrittweise dort angekommen, weil sich aus meiner täglichen Arbeit mit ChatGPT, Codex und Agenda immer neue Anforderungen ergeben haben. Aus einem Coding-Assistenten wurde zunächst ein Werkzeug zur Umsetzung klar definierter Aufgaben, daraus ein strukturierter Arbeitsprozess und schließlich die Frage, wie mehrere spezialisierte KI-Systeme und Agenten sinnvoll zusammenarbeiten können.
Genau an diesem Punkt befinde ich mich heute. Ich habe bereits mehrere agentische Bausteine, aber noch kein vollständig ausgebautes Multi-Agent-System im klassischen Sinn. Gerade dieser Zwischenstand ist für mich spannend, weil sich daran gut zeigen lässt, wie aus normaler KI-gestützter Softwareentwicklung schrittweise eine ganz andere Form technischer Arbeit entsteht.
Am Anfang stand einfach nur Codex
Der erste Schritt war rückblickend ziemlich unspektakulär. Ich habe Codex genutzt, um Aufgaben im Quellcode schneller umzusetzen. Statt jede Änderung selbst zu programmieren, konnte ich beschreiben, was ich erreichen wollte, und Codex einen Teil der technischen Arbeit übernehmen lassen.
Zunächst war das für mich vor allem eine Frage der Produktivität. Wenn eine Funktion schneller entsteht oder ein Fehler schneller gefunden wird, ist das unmittelbar nützlich. Mit der Zeit wurde aber deutlich, dass die eigentliche Qualität der Ergebnisse weniger davon abhängt, wie geschickt ein einzelner Prompt formuliert ist, sondern davon, wie gut die Aufgabe vorher durchdacht wurde.
Deshalb beginne ich größere Themen heute häufig mit einer ausführlichen Konzeptphase in ChatGPT, in der Anforderungen, Sonderfälle, Abhängigkeiten und offene Entscheidungen geklärt werden, bevor Codex überhaupt in das Repository eingreift. Aus dieser Trennung entstand langsam eine Rollenverteilung: ChatGPT hilft mir beim Denken und Strukturieren, Codex übernimmt anschließend die technische Umsetzung.
Damit war der erste wichtige Schritt in Richtung agentischer Systeme eigentlich schon getan, auch wenn ich ihn damals noch nicht so genannt hätte. Ich begann nicht mehr nur darüber nachzudenken, welche KI eine Aufgabe lösen kann, sondern welche Rolle ein KI-System innerhalb eines größeren Prozesses übernehmen soll.
Ein Agent ist für mich mehr als ein Chat mit Systemprompt
Je länger ich mit dieser Arbeitsweise arbeite, desto weniger reicht mir die Vorstellung, ein Agent sei einfach ein Chatfenster mit einer besonderen Anweisung. Für meine Zwecke gehört zu einem Agenten deutlich mehr.
Ein Agent braucht eine klar umrissene Aufgabe, Zugriff auf passende Werkzeuge, ausreichend Kontext über seinen Arbeitsbereich und eindeutige Regeln dafür, wann seine Arbeit erfolgreich abgeschlossen ist oder wann sie als fehlgeschlagen gilt. Gleichzeitig muss festgelegt sein, welche Entscheidungen der Agent selbst treffen darf und bei welchen Punkten er die Arbeit unterbrechen und eine Entscheidung zurückgeben muss.
Gerade diese Grenze ist für mich entscheidend. Ich möchte nicht, dass ein Agent möglichst autonom wirkt, indem er fehlende fachliche Entscheidungen einfach selbst erfindet. Wenn eine technische Detailfrage innerhalb einer bestehenden Architektur eindeutig lösbar ist, darf Codex diese Entscheidung durchaus treffen. Wenn dagegen nicht festgelegt ist, wie sich ein Produkt fachlich verhalten soll, möchte ich lieber eine blockierte Aufgabe als eine plausible, aber möglicherweise falsche Annahme.
Meine gesamte Prozesskette von der Idee bis zum Deployment basiert inzwischen auf diesem Prinzip. Autonomie bedeutet für mich nicht, dass möglichst viele Entscheidungen von der KI getroffen werden, sondern dass möglichst viel Arbeit selbstständig ausgeführt werden kann, nachdem die entscheidenden Rahmenbedingungen geklärt sind.
Mit Agenda wurde aus KI-Unterstützung langsam Orchestrierung
Der nächste große Schritt war Agenda. Solange ich direkt mit Codex arbeite, bleibt der Ablauf relativ einfach: Ich formuliere eine Aufgabe, Codex bearbeitet sie und ich sehe mir das Ergebnis an. Sobald aber mehrere Themen parallel vorbereitet werden und einzelne Aufgaben unabhängig voneinander laufen sollen, reicht dieser direkte Dialog irgendwann nicht mehr aus.
Agenda schafft deshalb eine zusätzliche Ebene zwischen Planung und Ausführung. Dort liegen Aufgaben mit Zuständen, Abhängigkeiten und Freigaben. Eine Aufgabe kann vorbereitet sein, auf meine Freigabe warten, bearbeitet werden, blockieren oder abgeschlossen sein. Wenn eine laufende Arbeit unterbrochen wird, muss außerdem nachvollziehbar bleiben, was passiert ist und ob sie fortgesetzt oder neu gestartet werden kann.
Der Gartenstuhl-Test beschreibt ziemlich gut, wohin ich damit möchte. Ich möchte eine sauber vorbereitete Aufgabe freigeben können, ohne anschließend jeden technischen Schritt selbst begleiten zu müssen. Genau dafür brauche ich aber eine Orchestrierung, die mehr kann, als nur Aufgaben in einer Liste anzuzeigen.
Agenda wird dadurch zunehmend zu dem Ort, an dem agentische Arbeit organisiert wird.
Mehrere Agenten sind noch kein Multi-Agent-System
Spätestens an dieser Stelle stellt sich die Frage, wann aus mehreren KI-Arbeitern eigentlich ein Multi-Agent-System wird.
Für mich reicht es nicht, einfach mehrere Codex-Chats gleichzeitig zu öffnen. Das ist Parallelisierung, aber noch keine echte agentische Zusammenarbeit. Ein Multi-Agent-System wird erst dann interessant, wenn mehrere Agenten unterschiedliche Rollen übernehmen, auf einen gemeinsamen Arbeitszustand zugreifen und ihre Ergebnisse Auswirkungen auf die Arbeit anderer Agenten haben.
Mehrere KI-Systeme laufen bei mir heute bereits parallel. Während ein ChatGPT-Gespräch ein neues Konzept entwickelt, kann Codex ein anderes Konzept analysieren und daraus Agenda-Aufgaben erzeugen, während gleichzeitig bereits eine freigegebene Aufgabe umgesetzt wird.
Das ist für mich bereits ein großer Produktivitätsgewinn, aber noch kein vollständiges MAS. Heute stoße ich viele Übergänge weiterhin selbst an, entscheide über Freigaben und bestimme, wann eine Aufgabe in die nächste Phase gelangt.
Ein echtes Multi-Agent-System würde diese Übergänge innerhalb klar definierter Regeln stärker selbst organisieren.
Der Test-Agent war ein erster Schritt zu spezialisierten Rollen
Besonders deutlich wurde diese Entwicklung beim Testing. Ich wollte nicht, dass Codex nur Code erzeugt und anschließend dieselben offensichtlichen Tests schreibt, die seine eigene Umsetzung bestätigen.
Meine automatisierten Tests sollen gezielt nach Fehlern und Abweichungen suchen, und dafür setze ich bereits einen spezialisierten Test-Agenten ein. Dieser Agent ist keine Person und auch kein eigenständiger Tester in meinem Unternehmen, sondern eine technische Rolle innerhalb meines automatisierten Entwicklungsprozesses.
Der Unterschied liegt im Auftrag. Während Codex bei der Umsetzung versucht, eine Spezifikation korrekt zu realisieren, soll der Test-Agent das Ergebnis möglichst kritisch prüfen und gezielt Situationen finden, in denen die Umsetzung nicht hält, was sie verspricht.
Damit existieren bereits unterschiedliche agentische Rollen innerhalb desselben Prozesses. Gleichzeitig zeigt genau dieser Bereich, warum ich meinen heutigen Stand noch nicht als fertiges Multi-Agent-System bezeichnen würde. Wenn Implementierung und Testing auf derselben grundlegenden KI-Technologie beruhen, kann dieselbe falsche Annahme auf beiden Seiten auftauchen.
Die Rollen sind also getrennt, die Denkweise ist möglicherweise noch nicht unabhängig genug.
Agenda könnte zum gemeinsamen Arbeitsraum der Agenten werden
Für mein zukünftiges MAS sehe ich Agenda deshalb als möglichen gemeinsamen Arbeitsraum.
Ich halte wenig von der Vorstellung, mehrere KI-Agenten müssten permanent direkt miteinander diskutieren. Für meine Arbeit ist ein klarer, nachvollziehbarer Zustand wesentlich wichtiger als eine künstliche Konversation zwischen mehreren Modellen.
Ein sinnvolles Szenario wäre beispielsweise, dass aus einem Konzept zunächst technische Aufgaben entstehen. Eine freigegebene Aufgabe wird von einem Umsetzungsagenten übernommen. Nach erfolgreicher Umsetzung entsteht automatisch die nächste Prüfphase, in der ein anderer Agent Tests durchführt. Werden Fehler gefunden, geht die Aufgabe wieder zurück in die Umsetzung. Sind die Prüfungen erfolgreich, wechselt sie in einen Zustand, in dem das Deployment vorbereitet werden kann.
An bestimmten Stellen greife weiterhin ich ein, insbesondere bei fachlichen Konflikten oder der Freigabe produktiver Änderungen.
Die Agenten müssen dafür nicht direkt miteinander reden. Sie arbeiten über gemeinsame Zustände, Aufgaben und Ergebnisse.
Genau diese Form der Orchestrierung erscheint mir wesentlich kontrollierbarer.
Mein heutiger Stand liegt zwischen agentischem Workflow und MAS
Wenn ich meinen aktuellen Stand möglichst nüchtern einordne, arbeite ich bereits deutlich agentischer als noch vor einiger Zeit, aber ich betreibe noch kein vollständig selbstorganisierendes Multi-Agent-System.
Die wichtigsten Bausteine sind trotzdem schon vorhanden. Unterschiedliche KI-Systeme übernehmen verschiedene Rollen, spezialisierte Agenten existieren für einzelne Aufgaben, Agenda verwaltet Zustände und Abhängigkeiten, und für unterbrochene Arbeiten gibt es Konzepte rund um Heartbeats, Leases und begrenzte Neustartversuche.
Gleichzeitig bleiben viele Übergänge bewusst an meine Freigabe gebunden. Das ist zum Teil noch eine technische Begrenzung, zum Teil aber auch eine bewusste Entscheidung.
Ich möchte nicht, dass ein Agent eigenständig neue Produktziele definiert, Prioritäten verändert oder produktive Änderungen freigibt. Mein Ziel ist deshalb kein System, das mich vollständig aus dem Prozess entfernt, sondern ein System, das möglichst viel Arbeit zwischen meinen Entscheidungen selbstständig erledigt.
Der passende Begriff dafür ist im Moment wahrscheinlich eher Human-in-the-Loop-Agentensystem als ein vollständig autonomes MAS.
Die eigentliche Schwierigkeit verschiebt sich von der Umsetzung zur Koordination
Sobald mehrere Agenten parallel arbeiten können, entsteht eine neue Klasse von Problemen. Nicht mehr die einzelne Implementierung ist zwangsläufig der Engpass, sondern die Frage, welche Arbeiten überhaupt gleichzeitig laufen dürfen.
Für parallele Änderungen am selben Projekt habe ich deshalb bereits ein Konzept mit logischen Arbeitsbereichen entwickelt. Eine Aufgabe kann mehrere fachliche und technische Bereiche berühren, und wenn eine zweite Aufgabe dieselben Komponenten benötigt, dürfen beide nicht einfach gleichzeitig loslaufen.
Genau hier wird Multi-Agent-Entwicklung anspruchsvoll. Ein Orchestrator muss nicht nur Arbeit verteilen, sondern auch verstehen, welche Aufgaben voneinander abhängig sind, welche Ressourcen sie benötigen und welche Konflikte entstehen könnten.
Das ist ein ganz anderer Blick auf Softwareentwicklung als die klassische Frage, wie eine bestimmte Funktion programmiert wird.
Ich beschäftige mich zunehmend damit, wie Arbeit selbst modelliert werden muss.
Fehlerverhalten wird bei Agenten besonders wichtig
Bei klassischer Software lässt sich ein Fehler häufig klar einem Vorgang zuordnen. Bei agentischer Arbeit kann eine Aufgabe dagegen über viele Minuten oder Stunden laufen, mehrere Dateien verändern, externe Systeme ansprechen und mitten in diesem Prozess abbrechen.
Dann stellen sich Fragen, die ich früher deutlich seltener hatte.
Ist die Aufgabe wirklich beendet oder nur die Verbindung abgebrochen? Welche Änderungen wurden bereits vorgenommen? Kann ein neuer Agent die Arbeit fortsetzen? Muss die Aufgabe neu gestartet werden? Was passiert, wenn derselbe Schritt versehentlich doppelt ausgeführt wird?
Genau deshalb gehören Heartbeats, Leases und Wiederaufnahme inzwischen zu Agenda.
Wenn ein laufender Agent verschwindet, soll die Aufgabe nicht einfach für immer im Zustand „in Arbeit“ hängen bleiben. Gleichzeitig darf Agenda nicht blind neu starten, solange noch unklar ist, ob die ursprüngliche Arbeit tatsächlich beendet wurde.
Solche Mechanismen sind für mich typische Probleme agentischer Systeme, weil nicht mehr nur die Funktion selbst zuverlässig sein muss, sondern auch der Arbeiter, der diese Funktion über mehrere Schritte hinweg ausführt.
Langfristig sehe ich mehrere spezialisierte Agententypen
Mein Zielbild besteht deshalb nicht aus möglichst vielen identischen Codex-Instanzen.
Ich halte spezialisierte Rollen für deutlich interessanter.
Ein Agent könnte Konzepte technisch analysieren und daraus ausführbare Aufgaben ableiten. Ein anderer übernimmt die eigentliche Umsetzung. Ein unabhängigeres System kümmert sich um Tests. Weitere Agenten könnten später Deployment, Infrastruktur oder redaktionelle Prozesse übernehmen.
KI ist bei mir ohnehin längst nicht mehr auf klassische Softwareentwicklung beschränkt. Ich nutze dieselben Grundprinzipien inzwischen auch bei Websites, Unternehmensprozessen, Infrastruktur und anderen technischen Aufgaben.
Damit könnte Agenda langfristig weniger eine reine Entwicklungsaufgabenverwaltung und stärker eine allgemeine Orchestrierungsschicht für agentische Arbeit werden.
An diesem Punkt würde aus meinem heutigen Workflow wahrscheinlich tatsächlich ein echtes Multi-Agent-System.
Lokale KI könnte dabei später eine wichtige Rolle spielen
Mein Ziel, Codex langfristig teilweise durch lokale KI zu ersetzen, hängt ebenfalls mit diesem Thema zusammen.
Ein Multi-Agent-System kann schnell sehr viel Rechenleistung verbrauchen, insbesondere wenn mehrere spezialisierte Agenten parallel arbeiten. Mit eigener Hardware könnte ich langfristig unterschiedliche Modelle nach ihren jeweiligen Stärken einsetzen.
Ein leistungsfähiges Modell könnte komplexe Umsetzungen übernehmen, ein anderes unabhängigere Tests erzeugen und kleinere Modelle könnten einfache Verwaltungs-, Klassifikations- oder Kontrollaufgaben erledigen.
Das ist heute noch Zukunftsmusik, weil mir dafür insbesondere die passende Hardware fehlt. Konzeptionell passt es aber sehr gut zu der Richtung, in die sich mein System ohnehin entwickelt.
Meine Rolle als Entwickler verändert sich dadurch deutlich
Der vielleicht wichtigste Unterschied liegt für mich darin, worüber ich heute nachdenke.
Früher bestand Architektur vor allem aus Komponenten, Daten, Schnittstellen, Prozessen und Benutzeroberflächen. Heute kommen Rollen, Aufgaben, Zustände, Rechte, Ressourcen und Übergaben zwischen Agenten hinzu.
Ich muss mir überlegen, welcher Agent welche Informationen bekommt, welche Werkzeuge er verwenden darf, welche Entscheidungen zu seiner Rolle gehören und wie seine Arbeit in den Gesamtprozess zurückfließt.
Damit entwickle ich nicht mehr nur Software, die eine fachliche Aufgabe erledigt.
Ich entwickle zunehmend Software, die Arbeit organisiert und wiederum andere technische Systeme dazu bringt, diese Arbeit auszuführen.
Genau darin liegt für mich der Übergang zur Entwicklung agentischer Systeme.
Ich bin weiterhin Softwareentwickler, aber meine Arbeit verschiebt sich immer stärker von der einzelnen Implementierung hin zur Architektur von Prozessen, in denen KI-Systeme selbstständig handeln können.
Und beim Thema Multi-Agent-Systeme bin ich heute genau an dem Punkt, an dem die einzelnen Bausteine nicht mehr nur theoretisch interessant sind, sondern beginnen, zu einem zusammenhängenden System zu werden.