Die 3 Stufen einer Multi-Agenten-Coding-Architektur

Stufe 1: Spaghetti-Modus

Im Spaghetti-Modus nutzt jeder die Agenten auf unterschiedliche Weise.

Die erste Phase der Agenten-Einführung ist chaotisch. Teams nutzen Tools wie Claude Code, Cursor oder Windsurf unabhängig voneinander, Ingenieure entwickeln ihre eigenen Prompts und Arbeitsabläufe, und es gibt kaum gemeinsame Standards dafür, wie Agenten Code schreiben, Änderungen testen oder Aufgaben im Zusammenhang mit der Bereitstellung bewältigen sollen. Diese Phase ist normal und sogar nützlich. Sie hilft Teams zu erkennen, wo Agenten effektiv sind, wo sie versagen und welche Risiken entstehen, wenn sie ohne klare Vorgaben arbeiten. Die Grenzen zeigen sich jedoch schnell.

Ohne gemeinsame Muster variiert die Qualität von Team zu Team, nützliches Wissen über Prompts bleibt bei Einzelpersonen hängen, und Führungskräfte haben kaum Einblick darin, was Agenten tatsächlich produzieren oder ob diese Ergebnisse internen Standards entsprechen. Schatten-KI entsteht, wenn Teams Agenten entwickeln, die außerhalb des Sicherheits- und Governance-Modells der Organisation angesiedelt sind. Diese Agenten liefern Code und Dienste, die für den Rest der Organisation unsichtbar bleiben, und verursachen damit versteckte Komplexität, die sich schließlich in aufgeblähtem Code, verminderter Leistung und Produktionsausfällen äußert.

Für die meisten Organisationen besteht das Ziel in dieser Phase nicht darin, eine vollständige Orchestrierung zu früh zu erzwingen. Vielmehr geht es darum, wiederholbare Muster zu identifizieren, die es wert sind, standardisiert zu werden.

Stufe 2: Standardisierung

Das Ziel hier ist es, einmal zu definieren und überall zu verteilen.

Der Übergang zu Phase 2 beginnt, wenn Organisationen den Einsatz von Agenten skalieren und erfolgreiche Muster in wiederverwendbare, versionierte Anweisungen festhalten. Agent-Skills gewinnen als Mittel zur Erfassung und Standardisierung dieses Wissens zunehmend an Bedeutung. Sie erfassen, wie die Organisation Code schreibt, Tests strukturiert, mit APIs umgeht, Änderungen überprüft und Software bereitstellt, und stellen diese Anweisungen dann allen Agenten und Teams zur Verfügung.

Governance entsteht hier ganz natürlich aus praktischer Notwendigkeit heraus, da Unternehmen Audit-Protokolle führen, um nachverfolgen zu können, welcher Agent wann welche Fähigkeit genutzt hat. Die Qualität verbessert sich systematisch, da die Konsistenz zunimmt und Konsistenz Halluzinationen und Fehler reduziert. In dieser Phase entstehen erste Orchestrierungsmuster, da Teams mehrere Agenten miteinander verbinden, damit diese zusammenarbeiten. Agenten beginnen, parallel zu arbeiten, und die Arbeit eines Agenten kann den Workflow eines anderen Agenten zuverlässiger versorgen.

Hier ist das Reifegradmodell in der Zusammenfassung:

Die meisten professionellen Teams können innerhalb von sechs bis zwölf Monaten in Stufe 2 übergehen, wenn sie aktiv Muster erfassen, diese versionieren und die Akzeptanz überwachen.

Etkin beschrieb diese Reifekurve als Übergang vom Spaghetti-Modus in eine bewusstere Phase, in der Teams beginnen, die Fähigkeiten der Agenten zu nutzen und die Schnittstellen und Tools festzulegen, auf die diese Agenten zugreifen können.

Stufe 3: Autonome Flotten

In Stufe 3 werden Agenten als vollwertige Mitwirkende behandelt.

Mehrere Agenten arbeiten mit minimaler menschlicher Aufsicht zusammen und agieren mit einer Autonomie und Koordination, die die meisten Unternehmen heute als schockierend empfinden würden. Ein Agent schreibt eine Funktion, validiert diese durchgängig in einer realen Umgebung – nicht in einer Sandbox –, führt Tests durch, prüft die Sicherheit, überprüft die Leistung und eröffnet einen Pull Request. Ein anderer Agent überprüft den gesamten Prozess, während ein weiterer ihn ausführt und so lange iteriert, bis die Erfolgskriterien erfüllt sind. Der Mensch definiert zu Beginn die Anforderungen und Erfolgskriterien und überprüft, ob das Ergebnis den Erwartungen entspricht. Wenn Probleme zwischen den Agenten auftreten, greift der Mensch ein, um die Situation zu bewerten und Lösungen zu finden.

Berreleza beschreibt Stufe 3 als „KI-Softwarefabriken“, in denen ein einzelner Slack-Kommentar oder eine PR-Beschreibung als Input für Agenten dient, die damit das Problem autonom lösen. Er verweist auf AirTable als ein Unternehmen, das bereits in diese Richtung geht.

Stufe 3 erfordert eine Infrastruktur, über die die meisten Unternehmen noch nicht verfügen: bedarfsgesteuerte, kurzlebige Kubernetes-Umgebungen, Build-Services, die Code ohne lokales Docker kompilieren und containerisieren, integriertes Secret-Management, damit Agenten sicher auf Anmeldedaten zugreifen können, sowie durchgängige Observability hinsichtlich dessen, was Agenten getan haben und warum.

Ein Beispiel, aus das Berrelleza und Etkin hierfür hinweisen, ist Stripe, das angibt, 1.000 Pull Requests pro Woche mithilfe von „One Shot Agentic Workers“ zu versenden.

Sobald man die Zusammenarbeit der Agenten standardisiert hat, besteht der nächste Schritt darin, ihnen Zugriff auf Umgebungen zu gewähren, die die Produktion tatsächlich widerspiegeln, denn dort zeigt sich der wahre Nutzen.

Echte Umgebungen und Infrastruktur sind der Schlüssel

Auf ihrem Weg zum agentischen Engineering begehen Unternehmen den größten Fehler, wenn sie annehmen, dass Erfolg in der Sandbox Produktionsreife bedeutet. Ein Agent kann Code schreiben, der Unit-Tests besteht und dennoch versagen, sobald die Änderung auf echte Infrastruktur, Service-Abhängigkeiten, Netzwerkrichtlinien oder Ressourcenbeschränkungen trifft.

Deshalb sind ausgereifte Multi-Agent-Systeme auf echte Feedbackschleifen angewiesen. Anstatt bei der Codegenerierung aufzuhören, werden Agenten in temporären Umgebungen bereitgestellt, führen End-to-End-Prüfungen durch, beobachten Fehler und iterieren, bevor ein menschlicher Prüfer das Ergebnis entwirren muss.

In einem Podcast beschreibt Berrelleza dies anschaulich anhand einer Kubernetes-Demo, in der ein Agent eine fehlende Ingress-Konfiguration entdeckte, die für die Bereitstellung eines Health Checks erforderlich war, das Problem behob, den Code erneut bereitstellte und das Ergebnis validierte. Sein Argument: Manche Fehler treten erst auf, wenn die Software tatsächlich in einer Umgebung läuft, die die Realität widerspiegelt.

Brian Singer von Nobl9 fasst dies so zusammen: „Der eigentliche Durchbruch besteht darin, dass KI den Code tatsächlich schreibt, überprüft und bereitstellt und dass Leitplanken vorhanden sind, um im Grunde sicherzustellen, dass der Code so funktioniert, wie wir es wollen, und nichts kaputt macht, was nicht kaputtgehen soll.“

Wichtige Multi-Agent-Muster, die funktionieren

Drei Orchestrierungsmuster lassen sich bei Organisationen erkennen, die Multi-Agent-Systeme gut verwalten.

1. Sequentielle Muster. Diese verketten Agenten miteinander, wobei einer Code generiert, der nächste ihn überprüft, ein dritter ihn validiert und ein vierter ihn in die Produktion bereitstellt, wobei jeder Agent seine Ausgabe in einer klaren Übergabe an den nächsten weitergibt.
2. Parallele Muster. Diese lassen Agenten gleichzeitig denselben Code durchlaufen und validieren mehrere Aspekte gleichzeitig. Das bedeutet, dass ein Agent die Sicherheit prüft, ein anderer die Leistung und ein dritter die Kompatibilität. Alle drei arbeiten gleichzeitig, anstatt darauf zu warten, dass die anderen fertig werden.
3. Feedbackschleifen. Dies ist das wichtigste der drei Muster. Ein Agent versucht eine Aufgabe auszuführen, erhält echtes Laufzeit-Feedback, das anzeigt, ob er erfolgreich war, lernt aus dem, was tatsächlich passiert ist, und passt seinen Ansatz an. Dies funktioniert nur, wenn das Feedback aus der realen Infrastruktur stammt – also aus tatsächlichen Kubernetes-Instanzen, Richtlinien, Abhängigkeiten und Laufzeitbeschränkungen –, da alles, was auf Mocks oder Sandboxen basiert, den Agenten im Unklaren lässt und Komplexität hinzufügt, ohne das zugrunde liegende Problem zu lösen.

Obwohl diese Muster möglich sind, stellt sich die Frage, wann sich diese Komplexität lohnt und wann ein einzelner Agent immer noch die bessere Wahl ist.

Entscheidung zwischen Einzel- und Multi-Agent-Architekturen

Wenn ein Team noch lernt, wie man Coding-Agenten gut einsetzt, relativ geringe Mengen an KI-generiertem Code ausliefert oder an einem einfacheren Anwendungs-Stack arbeitet, reicht ein Einzel-Agent- oder Hybridmodell in der Regel aus. In dieser Phase benötigen Teams zudem klare Anforderungen und realistische Erwartungen darüber, was Agenten entscheiden sollten und was nicht, sowie die Bereitschaft, klar definierten Leitplanken zu vertrauen.

Für die meisten Teams ist der unmittelbar nächste Schritt einfacher: Erfassen Sie, was die besten Ingenieure bereits mit Agenten tun, wandeln Sie diese Muster in wiederverwendbare Leitlinien um und verbreiten Sie diese konsequent. Multi-Agenten-Systeme werden später wertvoll, wenn einzelne Agenten und die Überprüfung durch Menschen zum Engpass werden.

Dieser Artikel ist im Original in englischer Sprache auf Search App Architecture erschienen.