Abstract

This paper provides a systematic introduction to AI agents, covering core definitions and foundational architectural concepts. It examines tool integration, including operational principles, capabilities, and evaluation of AI coding agents, as well as the Model Context Protocol. The paper further analyzes memory systems as a key component for context persistence and long-horizon task execution. A central focus is placed on established reasoning patterns such as Chain of Thought, Reasoning and Acting, as well as further reasoning patterns and their combinations. Finally, orchestration strategies for single- and multi-agent systems are discussed, including parallel, hierarchical, and group-based patterns, along with control-handoff and coordination mechanisms.

Kurzfassung

Diese Arbeit bietet eine systematische Einführung in KI-Agenten und behandelt dabei zentrale Definitionen und grundlegende Architekturkonzepte. Es untersucht die Tool-Integration, einschließlich der Funktionsprinzipien, Fähigkeiten und Bewertung von KI-Codierungsagenten sowie das Model Context Protocol. Die Arbeit analysiert darüber hinaus Speichersysteme als Schlüsselkomponente für die Kontextpersistenz und die Ausführung von Aufgaben mit langem Zeithorizont. Ein zentraler Schwerpunkt liegt auf etablierten Argumentationsmustern wie „Chain of Thought”, „Reasoning and Acting” sowie weiteren Argumentationsmustern und deren Kombinationen. Abschließend werden Orchestrierungsstrategien für Single- und Multiagenten-Systeme diskutiert, darunter parallele, hierarchische und gruppenbasierte Muster sowie Kontrollübergabe- und Koordinationsmechanismen.

Einleitung

Die rasante Weiterentwicklung von Large Language Models (LLMs) hat in den letzten Jahren den Weg von reinen Chatbots hin zu handlungsfähigen, autonomen KI-Agenten eröffnet, die aktiv in Softwareentwicklungsprozesse eingreifen können. In der Praxis entstehen daraus neue Chancen für Produktivität, Codequalität und Automatisierung, aber ebenso neue Herausforderungen hinsichtlich Zuverlässigkeit, Kosten und Orchestrierung.

Die Arbeit untersucht, wie autonome KI-Agenten auf Basis von LLMs in der Softwareentwicklung gestaltet und eingesetzt werden können. Im Mittelpunkt stehen Architektur- und Orchestrierungsmuster von Single- bis Multi-Agent-Systemen, verschiedene Reasoning-Patterns wie Chain-of-Thought, ReAct oder Tree-of-Thoughts sowie Kurz- und Langzeit-Memory-Systeme.

Ziel der Arbeit ist es, einen strukturierten Überblick über Architektur‑, Orchestrierungs‑, Reasoning‑ und Memory-Konzepte autonomer KI-Agenten in der Softwareentwicklung zu geben und deren Abwägung zwischen Vor- und Nachteilen sowie Fehlermodi herauszuarbeiten.

Grundlagen von Agenten

Dieses Kapitel definiert die fundamentalen Konzepte von Software-Agenten, grenzt sie von statischen Workflows ab und ordnet sie in ein Framework für Autonomiegrade ein.

Definition und Kerneigenschaften eines Agenten

Im Kontext der KI-gestützten Softwareentwicklung ist ein Agent mehr als nur ein Werkzeug zur Code-Generierung, er wird als System verstanden, das seine Umgebung wahrnimmt und aktiv handelt, um Ziele zu erreichen [1], [2]. Während traditionelle Softwarekomponenten passiv auf Eingaben warten, zeichnen sich moderne, auf LLM basierende Agenten durch vier wesentliche Eigenschaften aus [1], [3]:

1. Autonomie
   Agenten agieren unabhängig und benötigen keine konstante, kleinschrittige Steuerung durch den Menschen. Sie treffen Entscheidungen innerhalb ihres Handlungsspielraums selbstständig [4].
2. Reaktivität
   Ein Agent muss fähig sein, Veränderungen in seiner Umgebung (z. B. Fehlermeldungen beim Kompilieren, geänderte Anforderungen) zeitnah wahrzunehmen und darauf zu reagieren [2].
3. Proaktivität
   Über die reine Reaktion hinaus agieren Agenten zielgerichtet. Sie warten nicht nur auf Befehle, sondern planen eigenständig Schritte, um ein übergeordnetes Ziel (z. B. “Refactoring eines Moduls”) zu erreichen [3].
4. Soziale Fähigkeit
   In komplexen Systemen agieren Agenten oft nicht isoliert. Sie besitzen die Fähigkeit, mit anderen Agenten oder Menschen in einer interpretierbaren Weise zu kommunizieren und zu verhandeln [1].

Abgrenzung von Workflows und Agenten

Ein entscheidender Aspekt für das Verständnis von Agentic AI ist die Unterscheidung zwischen traditionellen Automatisierungs-Workflows (Chains) und echten Agenten-Systemen [5], [6].

Während Workflows auf starren, vordefinierten Pfaden operieren, generieren Agenten ihre Vorgehensweise dynamisch zur Laufzeit [5].

In klassischen Workflows ist der Ausführungspfad vom Entwickler statisch festgelegt (hard-coded) und folgt meist einer deterministischen „Wenn-Dann“-Struktur. Im Gegensatz dazu agiert ein Agent adaptiv: Er generiert seinen Plan basierend auf der aktuellen Aufgabenstellung und dem Kontext selbstständig [1], [5]. Diese Fähigkeit ermöglicht es dem Agenten, Feedback, etwa Fehlermeldungen eines Compilers oder Rückmeldungen eines Code-Reviewers, aktiv zu verarbeiten und seinen Lösungsansatz entsprechend anzupassen [6].

Diese Flexibilität ist besonders relevant für die Fehlerbehandlung und den Einsatz in komplexen Umgebungen. Während unerwartete Fehler in einem starren Workflow oft zum Prozessabbruch führen, verfügen Agenten über Mechanismen zur Selbstüberprüfung. Sie können Fehler autonom erkennen und beheben, bevor eine menschliche Intervention notwendig wird [5], [7]. Damit sind Agenten speziell für Aufgaben in unvorhersehbaren Umgebungen konzipiert, in denen nicht alle Randbedingungen bereits zur Entwicklungszeit bekannt sind [2], [5].

Framework für Autonomiegrade (Levels of Autonomy)

Um die Fähigkeiten von KI-Systemen in der Softwareentwicklung zu klassifizieren, wird oft ein Stufenmodell herangezogen, das an die aus der Automobilindustrie bekannten Autonomie-Level angelehnt ist [8], [9].

Für Software-Agenten lässt sich dieses Spektrum wie folgt unterteilen [8]:

Level 0: Keine Autonomie Der Prozess wird vollständig manuell vom Menschen durchgeführt. Es findet keine Unterstützung durch KI statt [8].

Level 1: Einfache Assistenz Das System bietet Vorschläge (z. B. Code-Vervollständigung) oder Erklärungen an, die exekutive Kontrolle liegt jedoch vollständig beim Menschen [8].

Level 2: Teilautomatisierung Das System kann einzelne Aufgaben unter menschlicher Aufsicht übernehmen, beispielsweise das Bearbeiten mehrerer Dateien, wobei der Mensch den Prozess initiiert und überwacht [8].

Level 3: Bedingte Autonomie Der Agent agiert innerhalb eines definierten Rahmens autonom. Der Mensch greift nur ein, wenn das System an seine Grenzen stößt oder explizit um Hilfe bittet (Human-in-the-loop) [3], [8].

Level 4: Hohe Autonomie Der Agent übernimmt den Großteil der Tasks selbstständig, inklusive Planung und Ausführung. Der Mensch prüft lediglich Ausnahmen oder validiert das Endergebnis [8].

Level 5: Volle Autonomie Das System agiert komplett eigenständig von der Aufgabenstellung bis zur Lösung. Eine menschliche Aufsicht ist für die operative Durchführung nicht mehr erforderlich [8].

Toolintegration

Dieses Kapitel beleuchtet die technische Funktionsweise der Tool-Integration und analysiert die spezifischen Fähigkeiten sowie die Vor- und Nachteile von KI-Coding-Agenten.

Tool-Integration und Funktionsweise

Die Fähigkeit, externe Werkzeuge (Tools) zu nutzen, ist das zentrale Unterscheidungsmerkmal zwischen einem reinen Chatbot und einem handlungsfähigen Agenten [1], [4]. Während ein Standard-LLM auf sein trainiertes Wissen beschränkt ist, ermöglichen Tools den Zugriff auf Echtzeitdaten, das Dateisystem oder APIs [6].

Der technische Ablauf eines Tool-Aufrufs folgt einem zyklischen Prozess, der oft als strukturierte Ausführung beschrieben wird [10]. Dieser Prozess lässt sich in fünf Schritte, wie in [tools] dargestellt, unterteilen:

1. Reasoning (Der Gedanke): Der Agent analysiert die Benutzeranfrage z. B. „Brauche ich morgen eine Jacke?“ und stellt fest, dass sein internes Wissen nicht ausreicht [2]. Er formuliert den internen Plan: „Ich brauche die Wetter-Informationen, um fortzufahren“.
2. Strukturierter Request (JSON-Generierung): Anstatt freien Text zu generieren, erzeugt das Modell einen strukturierten Befehl, meist im JSON-Format, der maschinenlesbar ist [10]. Beispiel: { “tool”: “weather_api”, “city”: “Stuttgart”, “date”: “2025-12-12” }
3. System-Ausführung (Execution): Eine deterministische Umgebung (z. B. eine Python-Runtime) erkennt den strukturierten Block, stoppt die Textgenerierung und führt den API-Aufruf tatsächlich aus [4], [6].
4. Observation (Ergebnis-Rückgabe): Das externe Tool liefert das Ergebnis zurück an den Agenten [6] Beispiel: “Stuttgart: 3°C, 20 % Regen”
5. Integration (Synthese): Der Agent nimmt diese neue Information in seinen Kontext auf und generiert darauf basierend die Antwort oder plant den nächsten Schritt [2].

Fähigkeiten und Bewertung von KI-Coding-Agenten

Spezialisierte Coding-Agenten wenden die generelle Fähigkeit zur Werkzeugnutzung direkt auf den Software-Entwicklungszyklus an [7]. Basierend auf der aktuellen Forschung lassen sich ihre Kompetenzen in drei Bereiche unterteilen, die jeweils spezifische technische Potenziale, aber auch Risiken bergen.

Im Bereich Code Analysis und Understanding nutzen Agenten semantische Suche und Vektordatenbanken, um den Kontext über Dateigrenzen hinweg zu erfassen, was als Repo-level Coding bezeichnet wird [12]. Dies befähigt sie dazu, als Mentoren zu fungieren und das Onboarding von Entwicklern in unbekanntem Quellcode signifikant zu beschleunigen [7], [13]. Allerdings ist die Präzision dieser Assistenz stark von der Qualität der Suche abhängig. Fehlender Kontext kann zu Halluzinationen führen, bei denen der Agent Funktionen erfindet, die im Projekt real nicht existieren [14].

Hinsichtlich der Code-Transformation können Agenten Code modernisieren und technische Rückstände abbauen. Eine empirische Studie zeigt jedoch eine qualitative Diskrepanz: Während Agenten formale Refactorings gut beherrschen, neigen sie bei tiefergehenden Änderungen der Programmlogik dazu, subtile Fehler einzubauen, die schwer zu entdecken sind [14]. Zwar verfügen Agenten über Mechanismen zur Selbstkorrektur, um solche Fehler iterativ zu beheben [12], doch besteht hierbei das Risiko von fehlerhaften Iterationsschleifen, in denen der Agent Fehler propagiert statt sie zu lösen [6], [7].

Im Feld Code-Generation und -Testing erstellen Agenten nicht nur produktiven Code, sondern generieren parallel die passenden Tests zur Validierung [6], [7]. Dies führt nachweislich zu einer subjektiven Entlastung der Entwickler bei Routineaufgaben und steigert die Arbeitszufriedenheit [13]. Der Preis für diese Autonomie ist jedoch eine erhöhte Komplexität in der Wartung der Agenten-Workflows sowie steigende Latenzzeiten und Kosten, die durch die Vielzahl der notwendigen API-Aufrufe verursacht werden [2], [10].

Model-Context-Protocol (MCP)

Mit der zunehmenden Anzahl an spezialisierten Tools und Datenquellen entsteht für Entwickler die Herausforderung, jede Schnittstelle individuell an einen Agenten anzubinden. Um dieses Integrationsproblem zu lösen, wurde das Model Context Protocol (MCP) entwickelt [15].

Das MCP fungiert als ein Open-Source Standard, der eine einheitliche Schnittstelle zwischen KI-Modellen und externen Systemen definiert. Anstatt für jede Datenbank oder API einen eigenen Konnektor zu schreiben, bietet MCP eine universelle Architektur, um KI-Anwendungen sicher mit lokalen oder entfernten Datenquellen zu verbinden [15].

Die Architektur bietet dabei zwei zentrale Kernfunktionen: Zum einen ermöglicht sie Agenten den direkten Zugriff auf externen Kontext, Dokumente und komplexe Arbeitsabläufe, ohne dass das zugrundeliegende Modell neu trainiert werden muss [15]. Zum anderen gewährleistet die standardisierte Schnittstelle, dass Daten und Befehle in einem normierten Format ausgetauscht werden. Dies sichert die Interoperabilität zwischen verschiedenen KI-Clients, wie IDEs oder Chat-Interfaces und Servern, etwa Datenbanken, Slack oder GitHub [15].

Memory-Systeme

Während LLMs von Natur aus zustandslos sind, benötigen autonome Agenten ein Gedächtnis, um aus vergangenen Aktionen zu lernen und konsistente Entscheidungen über längere Zeiträume zu treffen [4], [16]. Die Forschung unterscheidet hierbei primär zwischen Kurzzeit- und Langzeitgedächtnis, analog zur kognitiven Architektur des Menschen [12], [17].

Der folgende Vergleich verdeutlicht die technischen Unterschiede und Einsatzgebiete:

Reasoning Patterns

Unter Reasoning Patterns werden strukturierte Denk- und Verarbeitungsmuster verstanden, die ein Agent nutzt, um auf Basis logischer Abhängigkeiten zielgerichtet zu Schlussfolgerungen zu gelangen [2], [20]. Diese Muster können in unterschiedlichen Formen auftreten und variieren, je nach Modellarchitektur und Aufgabenstellung [20].

Chain-of-Thought

Ein prominentes Beispiel ist das Chain-of-Thought-Reasoning (CoT), das erstmals 2022 von Wei et al. beschrieben wurde [21]. CoT modelliert mehrschrittiges logisches Denken, indem ein Problem nicht unmittelbar beantwortet wird, sondern über eine explizite Sequenz intermediärer Schlussfolgerungsschritte. Diese explizite Darstellung von Zwischenschritten erlaubt es dem Modell, komplexe logische Abhängigkeiten innerhalb einer autoregressiven Generierung zu repräsentieren und führt empirisch zu einer verbesserten Lösungsqualität bei anspruchsvollen Aufgaben [21].

Die Generierung der Reasoning-Kette erfolgt dabei sequenziell innerhalb einer einzelnen Modellinferenz, wie in [cot] dargestellt: Das Modell erzeugt tokenweise eine Abfolge von Schlussfolgerungsschritten, wobei jeder Schritt kontextuell auf den zuvor generierten Tokens basiert. Ein explizites, erneutes Anwenden des Modells auf Zwischenergebnisse findet nicht statt; vielmehr entsteht der gesamte Reasoning-Prozess als zusammenhängende Ausgabesequenz [21].

Durch die explizite Zerlegung eines Problems in Zwischenschritte erreicht das Modell unter Verwendung von CoT höhere Erfolgsraten bei Aufgaben, die mehrstufiges logisches Denken erfordern, insbesondere auch bei Out-of-Distribution-Problemen [21], [22]. Zudem erhöht die explizite Darstellung der Reasoning-Schritte die Transparenz der Modellentscheidungen und verbessert die Nachvollziehbarkeit sowie die Debuggability für Nutzer und Entwickler [22], [23].

Gleichzeitig führt die Generierung ausführlicher Reasoning-Ketten jedoch zu einem erhöhten Tokenverbrauch und damit zu längeren Laufzeiten und höheren Rechenkosten [22]. Darüber hinaus können Fehler in frühen Zwischenschritten unentdeckt fortgepflanzt werden, da klassisches CoT keine integrierte Selbstkorrektur innerhalb der Reasoning-Kette vorsieht [22], [23], [24].

Rasoning and Acting

Reasoning and Acting (ReAct) wurde 2023 von Yao et al. beschrieben und stellt eine Erweiterung des CoT -Reasonings dar [25]. ReAct kombiniert dabei explizites Schlussfolgern in Schritten mit gezielten Aktionen, indem ein Agent während der Problembearbeitung iterativ zwischen den Zuständen “Reasoning” und “Acting” wechselt [25].

Ausgehend von einem initialen Prompt entscheidet der Agent zunächst, welcher nächste Schritt zielführend ist, beispielsweise das Lösen eines Teilproblems oder das Beschaffen zusätzlicher Informationen. Anschließend führt er eine Aktion aus, etwa eine Code-Ausführung oder einen Zugriff auf eine externe Quelle. Die Ergebnisse dieser Aktionen werden als “Observations” in den Kontext aufgenommen und dienen als zusätzliche Informationsbasis für nachfolgende Reasoning-Schritte, wie [react] zeigt. Auf dieser erweiterten Grundlage entscheidet der Agent über weitere Aktionen oder setzt die Schlussfolgerung fort. Dieser zyklische Prozess aus Denken, Handeln und Beobachten wird iterativ wiederholt, bis eine Lösung erreicht ist. Abhängig von der Aufgabe können dabei auch mehrere Reasoning-Schritte ohne zwischenliegende Aktionen erfolgen [25].

Durch die enge Verzahnung von Reasoning und Interaktion mit der Umgebung bietet ReAct eine hohe Flexibilität und Adaptivität, da der Lösungsweg dynamisch an neu gewonnene Informationen angepasst werden kann. Zudem erhöht die explizite Struktur der einzelnen Schritte die Transparenz des Entscheidungsprozesses [25], [26]. Die Einbindung externer Observations, etwa durch Suchergebnisse, kann die Faktentreue verbessern und die Neigung zu Halluzinationen im Vergleich zu reinem, internem Reasoning reduzieren [26].

Demgegenüber stehen mehrere Nachteile. Die Ausführung zusätzlicher Aktionen und die iterative Erweiterung des Kontexts führen zu einem erhöhten Rechen- und Zeitaufwand sowie zu höheren Kosten [26]. Darüber hinaus besteht ein erhöhtes Fehlerrisiko durch externe Informationsquellen: Fehlerhafte oder veraltete Observations können zu falschen Schlussfolgerungen führen [25]. Ebenso können unvollständige Beobachtungen Halluzinationen begünstigen, oder der Agent kann Tool-Ausgaben fehlerhaft interpretieren, etwa Warnungen als Fehler missverstehen, was den weiteren Lösungsprozess negativ beeinflusst [25].

Reflection

Ein weiteres Reasoning-Pattern ist Reflection. Dabei überprüft ein Agent nach einzelnen Zwischenschritten — etwa nach CoT – oder ReAct-Prozessen — seine bisherigen Ausgaben auf logische Konsistenz, Plausibilität und faktische Korrektheit. Der Agent generiert hierzu explizites Selbstfeedback, identifiziert potenzielle Fehler oder Ungereimtheiten und passt seine Ausgabe entsprechend an [27].

Der Ablauf von Reflection ist in [reflection] abgebildet und lässt sich wie folgt beschreiben: Zunächst erzeugt der Agent einen Reasoning-Schritt und produziert einen Output. Anschließend reflektiert er diesen Output, bewertet ihn kritisch und nimmt bei Bedarf Korrekturen oder Aktualisierungen vor. Die revidierte Version wird anschließend als Grundlage für den nächsten Schritt verwendet. Dieser Prozess wird iterativ fortgeführt, bis eine finale Ausgabe erreicht ist [27], [28].

Reflection bietet mehrere Vorteile. Durch die wiederholte Selbstüberprüfung können fehlerhafte Schlussfolgerungen identifiziert und korrigiert werden, wodurch sich die Qualität der finalen Ausgabe erhöhen kann. In geeigneten Implementierungen werden frühere Reflexionen im weiteren Verlauf erneut berücksichtigt, sodass erkannte Schwächen gezielt adressiert werden können. Zudem fördert Reflection ein iteratives Verfeinern der Lösung, anstatt die erste plausible Antwort zu akzeptieren, und unterstützt selbstständiges Debugging durch den Agenten [28].

Gleichzeitig weist dieses Pattern relevante Limitationen auf. In komplexen Aufgaben kann es zu sogenannten Fehlhalluzinationen kommen, bei denen der Agent fälschlicherweise Probleme in einer eigentlich korrekten Lösung vermutet und diese dadurch verschlechtert. Darüber hinaus besteht die Gefahr einer “Analyse-Paralyse”, bei der sich der Agent in wiederholter Selbstkritik ohne substanziellen Fortschritt verliert. Zudem ist die Fähigkeit zur Selbstdiagnose begrenzt, da Modelle Fehler in ihren eigenen Reasoning-Ketten nur unzuverlässig erkennen. Schließlich führt die iterative Selbstüberprüfung zu einem erhöhten Tokenverbrauch und damit zu höheren Laufzeiten und Kosten [27].

Plan-then-Execute

Ein weiteres Reasoning-Pattern ist Plan-then-Execute. Dabei handelt es sich um ein zweistufiges Vorgehen, das explizit die Planungs- von der Ausführungsphase trennt. Zunächst erzeugt der Agent einen strukturierten Plan zur Lösung der Aufgabe. Anschließend wird dieser Plan in einer separaten Phase Schritt für Schritt ausgeführt [29].

Im Unterschied zu zuvor beschriebenen Reasoning-Patterns, bei denen Planung und Ausführung eng miteinander verschränkt oder implizit innerhalb eines fortlaufenden Reasoning-Prozesses erfolgen [22], [25], führt Plan-then-Execute eine klare funktionale Trennung dieser beiden Aspekte ein [29]. Dadurch wird der Lösungsprozess stärker strukturiert und besser kontrollierbar.

Auf diesem Grundprinzip bauen weiterführende Ansätze wie Self-Planning und Tree-of-Thoughts auf. Diese erweitern Plan-then-Execute hinsichtlich der Planerzeugung und der Behandlung von Alternativen.

Self-Planning

Self-Planning ist ein Reasoning-Pattern, bei dem ein Agent selbstständig einen detaillierten Lösungsplan für eine gegebene Aufgabe erzeugt, wie [self_planning] zeigt. Der Nutzer spezifiziert dabei ausschließlich das Ziel, während der Agent die Aufgabe analysiert, in Teilaufgaben zerlegt und daraus einen strukturierten, sequenziellen Ausführungsplan ableitet. Dieser Plan wird anschließend ohne weitere Anpassungen schrittweise ausgeführt [30], [31].

Self-Planning weist spezifische Fehlermodi auf. Ein häufiges Problem ist ein sogenannter Plan Drift, bei dem der Agent einzelne Schritte des ursprünglich erzeugten Plans ignoriert oder abändert. Darüber hinaus kann eine Überspezifikation des Plans die Flexibilität während der Ausführung einschränken, während eine Unterspezifikation dazu führt, dass der Plan zu wenig Orientierung für die Execution bietet [31].

Zu den Vorteilen von Self-Planning zählen die erhöhte Vorhersehbarkeit und Transparenz des Lösungsprozesses, da der Plan vor der Ausführung vollständig vorliegt und von einem Menschen überprüft oder freigegeben werden kann. Die klare Struktur erleichtert zudem das Debugging, da Abweichungen und Fehler eindeutig einzelnen Planungsschritten zugeordnet werden können [30].

Demgegenüber steht ein relevanter Nachteil. Da keine Selbstkorrektur oder adaptive Plananpassung vorgesehen ist, propagieren sich Fehler aus der Planungsphase direkt in die Ausführung [30].

Tree-of-Thoughts

Tree-of-Thoughts (ToT) ist ein weiteres Reasoning-Pattern, das dem Plan-then-Execute-Paradigma zugeordnet werden kann, sich jedoch von klassischen Ansätzen durch die Erweiterung linearer Reasoning-Ketten hin zu einer verzweigten, baumartigen Struktur unterscheidet. Der Ansatz wurde erstmals 2023 von Yao et al. beschrieben [32]. Dabei verfolgt der Agent nicht mehr einen einzelnen linearen Gedankengang, sondern mehrere alternative Denkpfade, die als hierarchischer Baum von Thoughts organisiert sind [32].

Ausgehend von einem Prompt generiert der Agent zunächst mehrere unterschiedliche Ansatzgedanken, welche die Wurzeläste des Baums bilden, vgl. [tot]. Für jeden dieser Gedankengänge wird eine Bewertung vorgenommen, die dessen Erfolgsaussichten für die endgültige Lösung angibt. Vielversprechende Pfade werden weiter ausgeführt, während weniger geeignete verworfen werden. Innerhalb des Baums ist Backtracking möglich, sodass der Agent aus Sackgassen zu früheren Knoten zurückkehren und alternative Pfade weiterverfolgen kann [32], [33], [34].

Durch die strukturierte Exploration mehrerer Lösungsansätze erweitert ToT das klassische Plan-then-Execute-Prinzip um eine explizite Suche im Lösungsraum. Der Agent plant hierbei nicht nur eine einzelne Vorgehensweise, sondern untersucht systematisch verschiedene Alternativen, bevor er sich für eine Lösung entscheidet [34].

Jedoch birgt auch ToT Potenzial für Fehler. Ein Problem ist eine vorzeitige Vertiefung einzelner Pfade, bei der der Agent früh detaillierte Optimierungen vornimmt, bevor grundlegende Lösungsansätze ausreichend exploriert wurden [32]. Zudem können unbalancierte oder übermäßig große Bäume entstehen, insbesondere bei einfachen Aufgaben, bei denen der Ansatz zu unnötiger Komplexität und erhöhter Halluzinationsanfälligkeit führt [34].

Zu den Vorteilen von ToT zählt die parallele Exploration alternativer Lösungswege, wodurch Fehlschlüsse in einzelnen Pfaden kompensiert werden können. Zusätzlich bietet der Ansatz eine erhöhte Kontrollmöglichkeit für den Nutzer, da Parameter wie maximale Baumtiefe, -breite oder Abbruchkriterien explizit vorgegeben werden können [32].

Beeinflusst wird die Qualität der Ergebnisse bei der Verwendung von ToT durch die verwendete Bewertungsheuristik: Werden ungeeignete Pfade fälschlich hoch bewertet, investiert der Agent Rechenressourcen in irrelevante Teile des Suchraums. Zudem kann der Baum ohne geeignete Begrenzungen exponentiell wachsen, was zu hohem Tokenverbrauch führt und die Lösungssuche vorzeitig abbrechen kann, bevor ein geeignetes Ergebnis gefunden wird [33], [34].

Kombinationen

Die bislang betrachteten Reasoning-Patterns weisen jeweils spezifische Limitationen und Fehlermodi auf. In der Praxis lassen sich diese jedoch teilweise abmildern, indem verschiedene Patterns gezielt kombiniert werden. Solche Kombinationen nutzen komplementäre Stärken einzelner Ansätze und erhöhen dadurch Robustheit, Flexibilität und Ergebnisqualität von Agentensystemen.

Typische Kombinationen sind unter anderem:

1. ReAct + Reflection
   Der Agent nutzt ReAct, um durch alternierende Reasoning- und Action-Schritte eine Umgebung zu explorieren. Reflection wird anschließend eingesetzt, um die erzeugten Zwischenergebnisse kritisch zu überprüfen und Fehler zu identifizieren und die Ausgabe iterativ zu verbessern [25], [28].
2. Self-Planning + ReAct
   In dieser Kombination erzeugt Self-Planning zunächst einen globalen, strukturierten Lösungsplan [31]. ReAct übernimmt anschließend die schrittweise Ausführung einzelner Planbestandteile und ermöglicht dabei lokales Reasoning sowie die Einbindung zusätzlicher Informationen aus externen Quellen [20], [25].
3. ToT + Reflection
   ToT dient hier zur hierarchischen Zerlegung einer komplexen Aufgabe in mehrere alternative oder parallele Teilaufgaben [32]. Jeder Knoten des Baums wird separat bearbeitet, während Reflection zur Qualitätssicherung auf Ebene einzelner Teilprobleme eingesetzt wird, um inkonsistente oder fehlerhafte Zwischenergebnisse zu korrigieren [34].

Orchestrierung

Unter Orchestrierung wird die Steuerlogik eines Agentensystems oder Frameworks verstanden, die das Zusammenspiel einzelner Agenten oder Module koordiniert. Die Orchestrierung legt fest, welche Komponenten in welcher Reihenfolge aktiviert werden, wie Informationen zwischen ihnen ausgetauscht werden und unter welchen Bedingungen ein Prozess terminiert. Sie bildet damit die zentrale Kontrollinstanz für den Ablauf komplexer Reasoning- und Ausführungsprozesse [35].

Grundsätzlich lassen sich zwei Orchestrierungsformen unterscheiden: Systeme mit einem einzelnen, zentralen Agenten (Single-Agent-Orchestrierung) und Systeme mit mehreren spezialisierten Agenten (Multi-Agent-Orchestrierung) [35].

Single-Agent-Orchestrierung

Bei der Single-Agent-Orchestrierung verarbeitet ein einzelner Agent den gesamten Aufgabenfluss. Der Agent erhält den initialen Input, führt internes Reasoning durch und ruft bei Bedarf externe Tools, etwa Suchfunktionen oder Code-Ausführungen, auf. Die Ergebnisse dieser Tool-Aufrufe werden in den internen Kontext integriert, woraufhin der Agent seine Schlussfolgerungen iterativ aktualisiert, bis ein finales Ergebnis erzeugt wird [35].

Die Besonderheit der Single-Agent-Orchestrierung liegt darin, dass der Agent sämtliche klassischen Rollen innerhalb eines Projekts übernimmt, die typische Abfolge von Prompt zu Output zeigt [single_agent]. Dazu zählen beispielsweise die Planung und Strukturierung der Aufgabe, die Analyse bestehender Codebasen, die Implementierung neuer Funktionalität, das Testen von Code, die Erstellung von Dokumentation sowie die abschließende Überprüfung und Versionierung. Diese Rollen werden sequenziell vom gleichen Agenten ausgeführt [35].

Dieses Vorgehen weist jedoch bei hoher Komplexität Schwächen auf. Ein zentrales Problem ist Rollenverwirrung, bei der der Agent zwischen unterschiedlichen Aufgaben- oder Verantwortlichkeitskontexten wechselt und dabei den ursprünglichen Zielzustand aus den Augen verliert. Darüber hinaus besteht die Gefahr der Kontexterschöpfung: Durch lange Reasoning- und Tool-Interaktionsketten kann das verfügbare Tokenbudget vor Abschluss der Aufgabe aufgebraucht werden, was den Lösungsprozess vorzeitig beendet oder qualitativ verschlechtert [35].

Multiagenten-Orchestrierung

Multi-Agent-Orchestrierung bezeichnet den architektonischen Rahmen, der regelt, wie mehrere spezialisierte KI-Agenten interagieren und zusammenarbeiten, um komplexe Aufgaben zu lösen [36], [37], [38]. Wooldridge definiert Multi-Agent-Systeme als “systems composed of multiple interacting computing elements, known as agents”, die autonom handeln und durch Kooperation, Koordination und Verhandlung interagieren können [39]. Die Orchestrierung umfasst drei fundamentale Mechanismen: Aufgabenzerlegung (Task Decomposition), bei der komplexe Probleme in spezialisierte Arbeitseinheiten unterteilt werden, Routing und Delegation zur Zuweisung geeigneter Agenten, sowie Kontext-Management zur Definition des Informationsflusses zwischen Agenten [36], [37], [40].

Abgrenzung zu Single-Agenten

Single-Agent-Systeme stoßen bei zunehmender Komplexität an ihre Grenzen [23], [37]. Eine zentrale Limitation ist die Kontexterschöpfung: Ein einzelner Agent muss den gesamten Kontext in einem Kontextfenster verwalten, was bei mehrstufigen Aufgaben zu Context Narrowing führt, bei dem relevante Informationen vergessen werden oder Halluzinationen entstehen [41], [42], [43]. Zudem neigt ein Agent, der alle Rollen übernehmen muss, zum “Jack of all trades“-Problem mit generischen Ergebnissen und schwer wartbaren, monolithischen Prompts [38], [44].

Multi-Agent-Systeme adressieren diese Probleme durch Verteilung und Spezialisierung [36], [38]. Jeder Agent verwaltet nur aufgabenrelevanten Kontext, was die Verarbeitung größerer Informationsmengen ermöglicht. Die modulare Spezialisierung reduziert die Prompt-Komplexität stark [36], [43], [45]. Zudem erlauben Multi-Agent-Systeme Parallelisierung, Teilaufgaben können gleichzeitig bearbeitet werden, was die Ausführungszeit um bis zu 33% reduzieren kann [36], [46].

Multi-Agent-Systeme sind besonders bei zerlegbaren Aufgaben überlegen, etwa in der Softwareentwicklung mit spezialisierten Rollen, bei hochparallelen Forschungsaufgaben oder in Szenarien, die Fehlerkorrektur durch Diskurs erfordern [36], [45], [47], [48].

Topologien und Kontrollübergabe-Mechanismen

Multi-Agent-Architekturen werden durch zwei Dimensionen bestimmt: Topologien definieren die strukturelle Anordnung und Kommunikationswege, während Kontrollübergabe-Mechanismen regeln, wie die Ausführungsverantwortung wechselt.

Topologien

Sequential/Chain Pattern

Das Sequential- oder Chain-Pattern ([sequential]) definiert eine Architektur, bei der Agenten in einer vordefinierten, linearen Reihenfolge agieren. Das Kernmerkmal ist die Input-Output-Verkettung: Die Ausgabe eines Agenten dient unmittelbar als Eingabe für den nachfolgenden Agenten in der Sequenz. Der Ablauf ist deterministisch, die Reihenfolge ist fest und wird im gegensatz zu anderen Topologien nicht zur Laufzeit durch ein Orchestrierungsmodell entschieden. Dieses Muster lässt sich mit dem “Pipes and Filters“-Entwurfsmuster oder einer industriellen Montagelinie vergleichen, bei der Aufgaben wie am Fließband weitergereicht werden [36], [37], [44].

Der Ablaufprozess folgt einem strikten, linearen Ablauf, die sich in drei Hauptphasen unterteilt. In der Initialisierungsphase wird die Gesamtaufgabe in diskrete, sequenzielle Schritte zerlegt, wobei der Pfad bereits vor der Ausführung feststeht. Die sequenzielle Ausführung erfolgt durch unidirektionalen Datenfluss: Jeder Agent empfängt die Ausgabe des vorherigen Agenten, führt eine spezialisierte Transformation durch und gibt das Ergebnis weiter. Die Informationsweitergabe erfolgt durch verschiedene Mechanismen: direkte Input-Output-Verkettung, Carryover-Mechanismen, bei denen eine Zusammenfassung des vorangegangenen Dialogs weitergegeben wird, oder durch geteilte Speicher (Shared State/Blackboard), auf die nachfolgende Agenten zugreifen. Der Prozess endet, wenn der letzte Agent seine Aufgabe abgeschlossen hat [36], [37], [44], [49].​

Das Pattern eignet sich besonders für Aufgaben mit klaren, linearen Abhängigkeiten, bei denen der Output eines Schrittes zwingend als Input für den nächsten erforderlich ist [36], [37]. Das ChatDev Framework simuliert dazu sequenzielle Phasen wie Design, Codierung, Testen, Dokumentation, ähnlich zum Wasserfall-Modell in der Softwareentwicklung [50].

Das Pattern bietet progressive Verfeinerung durch schrittweise Qualitätssteigerung, wobei iterative Bearbeitung Fehler und Halluzinationen reduziert [36], [50], [51]. Die deterministische Steuerung eliminiert Unsicherheit über die Ausführungsreihenfolge und stellt sicher, dass kritische Schritte nicht übersprungen werden [36], [37]. Da keine zusätzlichen LLM-Aufrufe für Routing-Entscheidungen erforderlich sind, sinken Latenz und Kosten im Vergleich zu dynamischeren Mustern [37]. Die lineare Struktur ermöglicht klare Data Lineage und Traceability, wodurch Fehlerquellen besser lokalisiert werden können [44]. Bei langen Kontexten ermöglicht es die Überwindung von Kontextfenster-Limits durch sequenzielle Chunk-Verarbeitung, wobei nur relevante Erkenntnisse weitergereicht werden [52].

Das kritischste Risiko ist die Fehlerfortpflanzung: Ein Fehler in einer frühen Phase pflanzt sich durch die gesamte Kette fort, da nachfolgende Agenten auf falschen Prämissen weiterarbeiten [36], [37], [53]. Die statische Architektur verhindert dynamische Anpassungen zur Laufzeit und kann Schritte nicht überspringen, selbst wenn diese unnötig sind [36], [37]. Die lineare Ausführung addiert die Latenzen aller Schritte, wobei der langsamste Agent zum Bottleneck wird und keine Parallelverarbeitung möglich ist [40], [43]. Bei langen Ketten tritt außerdem Context Rot auf, wenn das Kontextfenster zu voll ist und frühere Informationen verloren gehen [42], [53]. Zudem führt der Ausfall eines einzelnen Agenten zum Zusammenbruch des gesamten Workflows, da es keine Redundanz oder alternativen Pfade gibt [36], [40].​

Parallel Pattern

Das Parallel Pattern ([concurrent]) (auch Concurrent Orchestration oder Fan-out/Fan-in-Muster) ist eine Architektur, bei der mehrere spezialisierte Agenten Aufgaben gleichzeitig und unabhängig voneinander bearbeiten. Das Muster zielt primär darauf ab, Latenzzeiten zu reduzieren und diverse Perspektiven zu integrieren [36], [37], [44].

Der Ablaufprozess unterteilt sich in drei Hauptphasen. Die Initialisierung (Fan-out) erfolgt durch einen Orchestrator, der die Anfrage analysiert und entweder eine komplexe Aufgabe in unabhängige Teilaufgaben zerlegt oder die Aufgabe für verschiedene Perspektiven repliziert. Die Befehlsverteilung kann deterministisch nach fest codierter Logik oder dynamisch durch semantisches Routing erfolgen. In der Ausführungsphase arbeiten die Agenten asynchron parallel, wobei jeder Agent seinen Befehl isoliert verarbeitet. Da alle Agenten gleichzeitig arbeiten, entsteht eine hohe momentane Ressourcenauslastung, die jedoch die Gesamtlaufzeit drastisch reduziert. Die Aggregationsphase (Fan-in) sammelt die Ergebnisse über einen Collector oder Synthesizer-Agenten, der typischerweise wartet, bis alle Agenten geantwortet haben oder ein Timeout erreicht ist. Die Synthese erfolgt durch Konsolidierung unterschiedlicher Teilinformationen, Voting-Mechanismen bei identischen Problemstellungen oder Konfliktlösungsstrategien bei widersprüchlichen Ergebnissen [36], [37], [40].​

In der Softwareentwicklung wird das Pattern unter anderem für automatisierten Code-Review eingesetzt, bei dem ein Security Auditor, Style Enforcer und Performance Analyst denselben Code simultan prüfen. Moderne Tools wie Cursor 2 oder Claude Code nutzen Hintergrundagenten zur parallelen Feature-Entwicklung, etwa gleichzeitige UI-Verfeinerung und Backend-Optimierung [36].

Das Pattern reduziert Latenz stark, da die Gesamtdauer nur durch den langsamsten Agenten bestimmt wird und nicht durch die Summe aller Arbeitsschritte. Experimente zeigten Zeitreduzierungen um 70-75% bei komplexen Diagnoseaufgaben. Durch Ensemble Reasoning entstehen vielseitige Perspektiven, wobei spezialisierte Agenten umfassendere Problemraumabdeckung erreichen als Generalisten [36], [40], [54], [55]. Voting-Mechanismen filtern Halluzinationen einzelner Modelle heraus, da multiple Agenten selten denselben Fehler halluzinieren [45]. Die Kontext-Isolierung ermöglicht jedem Agenten ein frisches Kontextfenster, was Context Pollution verhindert [56]. Zudem bietet die lose Kopplung Robustheit durch Graceful Degradation, wobei der Ausfall eines Agenten nicht zwingend zum Systemausfall führt [36], [40], [43], [57].​

Das Pattern verursacht hohe Ressourcenintensität durch massiven Token-Verbrauch, da mehrere Agenten gleichzeitig mit vollständigen Kontexten arbeiten [37], [48]. Studien quantifizieren redundante Token-Verarbeitung von 53-86% [58]. Burst Loads bei paralleler Ausführung führen zu Lastspitzen, die schnell zu API-Rate-Limits führen können [58]. Die Aggregationskomplexität erfordert aufwendige Konfliktlösungsstrategien bei widersprüchlichen Agentenantworten [36], [37], [40]. Race Conditions treten auf, wenn mehrere Agenten gleichzeitig auf geteilten Speicher zugreifen, was zu Datenkorruption führen kann [36], [44], [53], [55]. Das Straggler-Problem limitiert die Geschwindigkeit auf den langsamsten Agenten, wobei Timeouts oder endlose Schleifen den gesamten Aggregationsprozess blockieren können [40], [55]. Zudem ist das Pattern ungeeignet für abhängige Aufgaben, bei denen Schritt B zwingend auf dem Ergebnis von Schritt A aufbauen muss [36].​

Hierarchical Pattern

Das Hierarchical oder Supervisor Pattern ([hierarchical]) definiert eine geschichtete Struktur von Agenten zur Bewältigung komplexer Aufgaben. Die Architektur organisiert Agenten in einer Baumstruktur mit 2 oder mehr Ebenen: Ein Top-Level-Agent (Root/Manager) verwaltet das übergeordnete Ziel und zerlegt komplexe Aufgaben in kleinere Teilaufgaben, Mid-Level-Agenten fungieren als spezialisierte Teamleiter oder Koordinatoren für bestimmte Domänen und Worker-Agenten auf der untersten Ebene führen die konkreten Aufgaben aus [37], [38], [59], [60]. Der Informationsfluss erfolgt bidirektional: Top-Down fließen Entscheidungen und Aufgabenanweisungen kaskadenartig durch die Hierarchie, während Bottom-Up Informationen und Ergebnisse aggregiert werden, wobei jede Ebene die Komplexität für die darüberliegende Ebene abstrahiert [59]. Ein wesentlicher Aspekt ist die temporale Hierarchie, bei der höhere Ebenen strategische Entscheidungen mit langem Zeithorizont treffen, während niedrigere Ebenen kurzfristige, reaktive Entscheidungen ausführen [59].

Der Ablaufprozess basiert auf dem Divide-and-Conquer-Prinzip durch rekursive Aufgabenzerlegung. Der Top-Level-Agent analysiert die Anforderung und zerlegt sie in kleinere, handhabbare Teilaufgaben, die an Mid-Level-Agenten weitergegeben werden. Diese zerlegen sie bei Bedarf weiter, bis die Aufgaben einfach genug für spezialisierte Worker-Agenten sind [37], [57]. Die Delegation erfolgt hierarchisch und rollenbasiert durch Kaskadierung, wobei Mid-Level-Agenten als Orchestratoren für ihren Teilbaum fungieren [57], [61]. Der Supervisor überwacht den Fortschritt, validiert Ausgaben und stellt sicher, dass Aufgaben in der richtigen Reihenfolge ausgeführt werden [38], [54], [57]. Zur Kontextverwaltung arbeiten Sub-Agenten oft mit eigenem, vom Haupt-Thread getrenntem Kontextfenster, was die Gefahr der Context Pollution verringert [56], [62].

In der Softwareentwicklung simulieren Frameworks wie MetaGPT oder ChatDev virtuelle Software-Firmen, bei denen ein CEO/Projektmanager an spezialisierte Rollen wie Architekten, Ingenieure und QA-Ingenieure delegiert [50], [63], [64]. Bei umfangreichen Code-Migrationen erstellt ein Hauptagent eine To-Do-Liste und spawnt Sub-Agenten, die Datei-Batches parallel bearbeiten [56], [62].

Das Pattern bewältigt Komplexität durch Abstraktion, wobei höhere Ebenen Entscheidungen auf Basis verdichteter Daten treffen und Information Hiding die kognitive Belastung reduziert [43], [59]. Die Skalierbarkeit wird durch Aufteilung der Kontrollspanne erreicht: Zwischenebenen verhindern, dass ein einzelner Manager zum Flaschenhals wird, wodurch das System auf Hunderte von Agenten skalieren kann [38], [59]. Die temporale Hierarchie ermöglicht Trennung von Entscheidungen nach Zeithorizonten, wobei höhere Ebenen strategisch planen, während untere Ebenen reaktiv agieren [59]. Modularität und Spezialisierung erlauben saubere Trennung von Verantwortlichkeiten, wobei ganze Zweige als spezialisierte Teams fungieren [43], [57]. Die strukturierte Koordination mit klaren Autoritätsbeziehungen vermeidet Entscheidungsparalysen und reduziert Kommunikationsrauschen durch Beschränkung auf vertikale Pfade [59].

Manager-Agenten werden bei zu vielen untergeordneten Agenten zum Bottleneck und stellen einen Single Point of Failure dar, wobei ihr Ausfall den gesamten Workflow oder entsprechende Zweige funktionsunfähig macht [43]. Die Multi-Hop-Latenz erhöht Antwortzeiten durch notwendige Weiterleitung über mehrere Ebenen [36], [37], [43]. Der Koordinationsaufwand verursacht hohen Token-Verbrauch durch Zwischenschritte und Statusberichte, wobei Multi-Agenten-Systeme bis zu 15-mal mehr Token als Einzelagenten verbrauchen können [48]. Bei einfachen Aufgaben übersteigen die Koordinationskosten den Nutzen [36], [65]. Informationsverlust tritt auf, wenn untergeordnete Agenten ihre Ergebnisse zusammenfassen und kritische Details verloren gehen [53], [65]. Planungsfehler des Root-Agenten kaskadieren durch das gesamte System, da alle nachgelagerten Agenten an falschen Teilaufgaben arbeiten [36], [40], [53]. Studien zeigen, dass Produktionssysteme Fehlerraten zwischen 41% und 86,7% aufweisen können, wobei ein Großteil auf Spezifikations- und Koordinationsprobleme zurückzuführen ist [63], [66]. ​

Groupchat Pattern

Das Groupchat Pattern ([groupchat]) ist ein Orchestrierungsmuster, bei dem mehrere spezialisierte Agenten gemeinsam in einem geteilten Konversationsstrang interagieren, um komplexe Probleme zu lösen, Entscheidungen zu treffen oder Arbeitsergebnisse zu validieren. Das zentrale Merkmal ist ein geteilter Kommunikationskanal (Thread), in dem alle teilnehmenden Agenten sowie optional menschliche Teilnehmer den vollständigen Gesprächsverlauf einsehen können. Die Koordination erfolgt durch einen Group Chat Manager, der basierend auf dem aktuellen Kontext und der Historie entscheidet, welcher Agent als Nächstes sprechen darf. Dieser Manager kann regelbasiert oder als eigener Agent implementiert werden. Das Muster unterstützt verschiedene Interaktionsmodi: kollaboratives Brainstorming, wobei Agenten mit unterschiedlichen Perspektiven auf Beiträgen anderer aufbauen, strukturierte Debatten zur Konsensfindung sowie Maker-Checker-Loops als iterative Zyklen zwischen Ersteller und Prüfer [36], [67].

Der zyklische Ablaufprozess beginnt mit der Initialisierung, bei der eine Benutzeranfrage an den Group Chat Manager gesendet wird und spezialisierte Agenten in einem gemeinsamen Chat-Raum instanziiert werden. In der Sprecherauswahl analysiert der Manager den akkumulierenden Chat-Verlauf und entscheidet basierend auf einer Routing-Strategie, welcher Agent als Nächstes sprechen darf [36], [68]. Die Auswahlstrategien variieren zwischen AutoPattern für dynamische, kontextbasierte Entscheidungen, Round Robin für zyklische Reihenfolge und regelbasierten Handoffs für explizite Übergaben [68], [69]. In der Ausführungsphase liest der ausgewählte Agent den Chatverlauf, führt seine spezifische Aufgabe aus und sendet das Ergebnis zurück in den gemeinsamen Thread [36], [67]. Der Prozess tritt in eine Iterationsschleife ein, wobei der Manager den neuen Zustand bewertet und zur Sprecherauswahl zurückkehrt. Die Terminierung erfolgt durch Zielerreichung, explizite TERMINATE-Nachrichten oder maximale Rundenbegrenzungen zur Vermeidung von Endlosschleifen [36], [55], [68].

Die dynamische, LLM-basierte Auswahl (AutoPattern) bietet hohe Flexibilität und Kontext-Sensitivität, verursacht jedoch hohe Kosten und Latenz sowie das Risiko von Endlosschleifen [36], [68]. Round Robin garantiert Fairness und einfache Implementierung bei niedrigem Overhead, führt jedoch zu Ineffizienz durch unnötige Beiträge und mangelnder Anpassungsfähigkeit [68], [69], [70]. Random Selection fördert Diversität in Brainstorming-Szenarien, erzeugt aber Chaos und Unvorhersehbarkeit [68], [69], [70]. Manuelle Regeln und Handoffs bieten Kontrolle und Sicherheit für kritische Prozesse, leiden aber unter Starrheit und hohem Wartungsaufwand [47].

In der Softwareentwicklung simuliert ChatDev virtuelle Entwicklungsteams mit Rollen wie Coder, Reviewer und Tester, die iterativ zusammenarbeiten, bis Code fehlerfrei läuft [50].

Das Pattern steigert Lösungsqualität durch Diversity of Thought, wobei strukturierte Debatten Halluzinationen reduzieren und Cross-Reflection Fehlerkorrektur ermöglicht [45], [71]. Dynamische Sprecherauswahl erlaubt flexible Anpassung an unerwartete Probleme zur Laufzeit. Der geteilte Kontext verhindert Informationsverlust und bietet vollständige Auditierbarkeit aller Interaktionen [59], [68]. Maker-Checker-Loops ermöglichen iterative Qualitätssteigerung durch stetige Verbesserung [36]. Die modulare Erweiterbarkeit erlaubt Hinzufügen neuer Fähigkeiten durch spezialisierte Agenten, ohne bestehende zu ändern, wobei Menschen nahtlos als weitere Teilnehmer integriert werden können [36], [38], [68]. Studien zeigen, dass spezialisierte Rollenaufteilungen bei steigender Aufgabenschwierigkeit deutlich bessere Ergebnisse liefern als andere Methoden [45], [72].

Der massive Ressourcenverbrauch führt zu bis zu 15-fach höherem Token-Verbrauch als Einzelagenten [48] mit Duplikationsraten von 53-86% [58], wobei der Koordinations-Overhead zu Leistungsverschlechterungen von 39-70% führen kann [65]. Die Diskussions-Latenz macht das Pattern für Echtzeitanwendungen ungeeignet [36], [54]. Infinite Loops können durch gegenseitiges Danken oder wiederholte Fragen ohne Abbruchbedingungen entstehen [36], [53], [63]. Die Skalierbarkeit ist begrenzt, es wird empfohlen, Gruppen auf drei oder weniger Agenten zu beschränken [71]. Context Window Overflow und Lost-in-the-Middle-Phänomene treten bei langen Threads auf [42], [52]. Theory of Mind Collapse führt dazu, dass Agenten Informationen zurückhalten oder falsche Annahmen über das Wissen anderer treffen [63]. Bei einfachen Aufgaben führt Overthinking zu schlechteren Ergebnissen als Einzelagenten [65], [72]. Wird ein zentraler Manager eingesetzt stellt dieser einen Single Point of Failure dar [36], [43]. ​

Hybrid-Architekturen

Hybrid-Architekturen können genutzt werden, wenn einzelne Topologien an ihre Grenzen stoßen. Sie kompinieren unterschiedliche Topologien, um spezifische Probleme zu lösen, in dem die stärken der Topologien kompiniert werden [36], [43], [60].

Die Kombination aus Manager und Sequential Workers implementiert Chained Task Sequencing. Ein Orchestrator delegiert eine Sequenz von Befehlen und ist zwischen den Schritten für Kontrolle und Validierung zuständig ist [40]. Das Framework AgentGroupChat-V2 zerlegt Benutzeranfragen in hierarchische Aufgabenbäume, wobei Aufgaben ohne Abhängigkeiten an verschiedene Group Manager verteilt und diese dann parallel ausgeführt werden [72].

Sequential mit Groupchat-Phasen wird in ChatDev implementiert, das sequentielle Phasen (Design → Coding → Testing) nutzt, wobei innerhalb jeder Phase Instruktor-Assistent-Paarungen oder Gruppendiskussionen zur Konsensfindung stattfinden [50]. Das Framework MetaGPT nutzt Standard Operating Procedures zur sequentiellen Strukturierung und weist diese einem Team aus spezialisierten Rollen zu, die Ergebnisse validieren und weitergeben [45], [47].

Es empfiehlt sich, verschiedene Phasen eines Workflows mit unterschiedlichen Topologien umzusetzen: sequentielle Orchestrierung für Datenaufbereitung mit Abhängigkeiten, parallele Muster für unabhängige Analysen und hierarchische Strukturen für komplexe Dekomposition [36], [37]. Zur Entwicklung solcher Architekturen bietet sich ein iteratives Vorgehen an: Zuerst startet man mit einfachen konfigurationsbasierten Mustern wie Supervisor und erst bei Bedarf geht man zu komplexen Orchestrierungen über [54]. Ein einzelner Agent ist oft effektiver und kostengünstiger als komplexe Systeme, wenn die Aufgabe keine parallele Verarbeitung oder spezialisierte Rollen erfordert [36], [58]. Das Framework ARG-Designer implementiert dynamische Generierung solcher Architekturen, statt statischer Templates und vermeidet so redundante Agenten durch autoregressive Generierung der Kollaborations-Topologie für jede Anfrage [73]. Damit nicht jeder Ausfall eines einzelnen Agenten zum Systemabsturz führt, sollten Failure Isolation techniken, wie Circuit Breakers oder Graceful Degradation, implementiert werden [36], [40].​

Kontrollübergabe-Mechanismen

Während die Topologien von Multi-Agenten-Systemen den strukturellen Rahmen der Agenten-Interaktion definieren, bestimmen Kontrollübergabe-Mechanismen die operativen Regeln, nach denen Entscheidungsbefugnisse, Aufgaben und Ressourcen zwischen den Agenten koordiniert und transferiert werden [74]. Die Effektivität eines Multi-Agenten-Systems hängt maßgeblich davon ab, wie präzise diese Mechanismen auf die Charakteristika der zu lösenden Aufgabe abgestimmt sind [43], [57]. Kontrollübergabe-Mechanismen bilden das Bindeglied zwischen der abstrakten Systemarchitektur und der konkreten Ausführung von Aufgaben, indem sie festlegen, welcher Agent zu welchem Zeitpunkt die Kontrolle ausübt und wie die Übergabe an nachfolgende Agenten erfolgt. Die Wahl des geeigneten Mechanismus beeinflusst fundamentale Systemeigenschaften wie Latenz, Skalierbarkeit, Ressourcenallokation und die Robustheit gegenüber Ausfällen [45], [54].

Im Folgenden werden vier zentrale Kontrollübergabe-Mechanismen systematisch analysiert: ​

Subagent-Mechanismus

Der Subagent-Mechanismus stellt ein Architekturmuster dar, bei dem ein übergeordneter Agent Teilaufgaben an spezialisierte Subagenten delegiert, die unabhängig parallel operieren und ihre Ergebnisse an den übergeordneten Agenten zurückmelden [56], [62], [75].

Der Subagent-Mechanismus eignet sich besonders für die hierarchische Topologie, wobei Entscheidungen von oben nach unten kaskadieren, während Informationen und Ergebnisse von unten nach oben fließen [43]. Ein zentrales Merkmal ist die Kapselung und Kontext-Isolation: Subagenten operieren in einem eigenen, isolierten Kontextfenster oder einer separaten Sitzung und erben nicht zwingend den gesamten Konversationsverlauf des Hauptagenten, sondern erhalten ausschließlich die für ihre spezifische Aufgabe relevanten Informationen [43], [56], [62], [76]. Der Hauptagent übernimmt die Rolle eines Synthesizers und wartet typischerweise auf die Fertigstellung der Aufgaben durch die Subagenten, um die Teilergebnisse zu einer Gesamtlösung zu aggregieren [40], [43], [75]. Die funktionale Spezialisierung der Subagenten ermöglicht es, dass diese als Experten für eng umgrenzte Domänen agieren und über spezifische Werkzeuge verfügen, die dem Hauptagenten nicht direkt zur Verfügung stehen müssen [38], [40], [56].

Die Vorteile des Subagent-Mechanismus liegen primär in seiner Skalierbarkeit, da er die Bewältigung komplexer Probleme ermöglicht, welche die Kapazität eines einzelnen Agenten hinsichtlich Kontextfenster oder Reasoning-Fähigkeit übersteigen würden [37], [48], [62]. Die Kontext-Effizienz wird durch die Auslagerung von Aufgaben in separate Subagenten gewährleistet, wodurch das Kontextfenster des Hauptagenten nicht mit Details der Zwischenschritte überfrachtet wird [48], [56]. Zudem ermöglicht die Parallelisierung unabhängiger Teilaufgaben durch verschiedene Subagenten eine Erhöhung des Durchsatzes [44], [75].

Als Nachteile sind die erhöhte Latenz durch mehrschichtige Kommunikation und Koordination zu nennen, insbesondere wenn der Hauptagent sequenziell auf Ergebnisse warten muss [36], [40], [43], [48], [53], [57]. Der Einsatz mehrerer Agenten vervielfacht den Token-Verbrauch im Vergleich zu monolithischen Ansätzen, was die Kosten erhöht. Darüber hinaus kann der zentrale Orchestrator oder Hauptagent als Single Point of Failure zum Flaschenhals werden, dessen Ausfall den gesamten Prozess gefährdet [37], [43], [48], [58].

Handoff-Mechanismus

Der Handoff-Mechanismus bezeichnet die explizite, dynamische Übergabe der Kontrolle von einem aktiven Agenten zu einem anderen. Diese Übergabe wird häufig durch Werkzeugaufrufe realisiert, die eine Zustandsvariable ändern, wodurch der Gesprächsfluss an einen spezialisierten Agenten weitergeleitet wird [36], [77].

Beim Handoff-Mechanismus verändert sich das Verhalten dynamisch basierend auf dem aktuellen Zustand des Systems [77]. Die Agenten agieren als Knoten in einem Graphen, wobei Kanten die möglichen Übergänge repräsentieren, ähnlich wie bei einem Automaten [43], [77], [78]. Die explizite Routing-Entscheidung wird nicht von einem Router getroffen, sondern vom Agenten selbst, der aktiv entscheidet, dass er nicht mehr zuständig ist oder seine Kapazitätsgrenze erreicht hat und den Transfer initiiert [36]. Ein fundamentales Merkmal ist die sequenzielle Exklusivität: Zu einem Zeitpunkt ist in der Regel immer nur ein Agent aktiv und interagiert direkt mit dem Nutzer, bis ein Handoff erfolgt [36], [77]. Handoffs können an Validierungsbedingungen geknüpft sein, beispielsweise muss eine bestimmte Information vorliegen, bevor an einen spezialisierten Agenten übergeben wird [77].

Die Vorteile des Handoff-Mechanismus liegen in der Gewährleistung von Spezialisierung, da Aufgaben stets vom qualifiziertesten Experten bearbeitet werden, ohne dass ein monolithischer Agent alle Fähigkeiten besitzen muss [36]. Klare Verantwortlichkeiten verhindern Rollenkonfusion, da Agenten explizite Grenzen haben und Aufgaben abgeben müssen, die außerhalb ihrer Kompetenz liegen [36], [53]. Zudem ermöglicht der Mechanismus eine präzise Prozesssteuerung durch die Durchsetzung strenger sequenzieller Abläufe in Geschäftsprozessen [36], [77].

Als Nachteil ist das Risiko von Endlosschleifen zu nennen, bei denen Agenten Aufgaben immer wieder hin- und herreichen, wenn Zuständigkeiten nicht eindeutig sind oder Fehler auftreten [36]. Bei der Übergabe kann kritischer Kontext verloren gehen, wenn dieser nicht explizit und strukturiert an den nachfolgenden Agenten übermittelt wird [42], [53], [77]. Falsche Klassifizierungen der Nutzerabsicht können zu suboptimalem Routing und frustrierenden Nutzererfahrungen durch unnötige Handoffs führen [36].

​

Round Robin-Mechanismus

Round Robin ist ein deterministischer Algorithmus zur Ressourcenzuweisung oder Gesprächssteuerung, bei dem Agenten in einer festen, zyklischen Reihenfolge aktiviert werden oder Zugriff auf einen Kommunikationskanal erhalten [69].

​Die Reihenfolge der Interaktion ist starr und vorhersagbar und basiert nicht auf dem Inhalt der Aufgabe oder der aktuellen Dringlichkeit. Dieser Mechanismus garantiert, dass jeder Agent die Möglichkeit erhält, beizutragen oder Ressourcen zu nutzen, wodurch das Verhungern einzelner Agenten verhindert wird. Konfliktvermeidung wird dadurch erreicht, dass zu jedem Zeitpunkt klar definiert ist, welcher Agent senden oder agieren darf, wodurch Datenkollisionen in geteilten Medien vermieden werden. Ein weiteres Merkmal ist die Dezentralisierung, da kein komplexer zentraler Entscheidungsträger notwendig ist, der die Fähigkeiten der Agenten bewertet; die Logik folgt einem simplen Rotationsprinzip [69].

​Die Vorteile des Round Robin-Mechanismus liegen in seiner Einfachheit, da er leicht zu implementieren ist und einen geringen algorithmischen Overhead aufweist. Die ausgewogene Beteiligung stellt sicher, dass alle Perspektiven in einer Diskussion gehört werden, ohne dass dominante Agenten den Diskurs übernehmen. Er ist robust gegen komplexe Entscheidungsfehler, da keine intelligente Routing-Logik erforderlich ist [69].

​Als Nachteil ist die Ineffizienz zu nennen, da Agenten auch dann aufgerufen werden, wenn sie keinen relevanten Beitrag leisten können, was zu unnötigem Kommunikationsaufwand und Zeitverlust führt. Die mangelnde Priorisierung führt dazu, dass dringende Aufgaben oder Agenten mit kritischem Wissen warten müssen, bis sie an der Reihe sind, was die Latenz erhöht. Skalierbarkeitsprobleme entstehen dadurch, dass die Wartezeit für jeden einzelnen Agenten linear mit der Anzahl der Teilnehmer im System wächst [69].

Eignung der Mechanismen in verschiedenen Topologien

Der Subagent-Mechanismus passt sowohl zur hierarchischen Topologie, da er auf Top-Down-Zerlegung und Bottom-Up-Aggregation basiert und damit eine explizite Hierarchie erfordert. Die zentrale Koordination durch einen Hauptagenten entspricht der zentralisierten Architektur mit einem steuernden Orchestrator. Als auch zu parallelen Topologien, da hier unabhängige Teilaufgaben paralell bearbeitet werden.

Der Handoff-Mechanismus wird in sequenziellen oder Chain-basierten Topologien eingesetzt, da die explizite Kontrollübergabe zwischen Agenten eine lineare Prozesskette voraussetzt. Die zustandsbasierte Weiterleitung eignet sich für Szenarien, in denen spezialisierte Agenten nacheinander aktiviert werden müssen, um verschiedene Phasen eines Prozesses zu durchlaufen. In Groupchat-Topologien kann der Handoff-Mechanismus zur dynamischen Speaker-Selection eingesetzt werden, wobei die Kontrolle gezielt an den nächsten relevanten Agenten übergeben wird.

Der Round Robin-Mechanismus ist für Groupchat-Topologien geeignet, in denen eine faire und ausgewogene Beteiligung aller Agenten gewährleistet werden soll. Die zyklische Aktivierung verhindert, dass einzelne Agenten die Diskussion dominieren und bezieht alle Perspektiven systematisch ein. Für zeitkritische Anforderungen oder Topologien mit Priorisierung eignet sich der Mechanismus weniger, da die feste Reihenfolge keine dynamische Anpassung an den Systemzustand erlaubt, um unpassende Agenten zu überspringen.

Die Eignung eines Kontrollübergabe-Mechanismus darf nicht isoliert betrachtet werden, sondern muss immer im Kontext der Aufgabenstruktur und der gewählten Topologie evaluiert werden. Die sequenzielle Unabhängigkeit einer Aufgabe und der erforderliche Kommunikationsoverhead sind entscheidende Faktoren, die über die Wahl des optimalen Mechanismus entscheiden.

Fazit und Ausblick

Übergreifende Erkenntnisse

Die Analyse der Architektur-Patterns, Reasoning-Patterns und Memory-Systeme von KI-Agenten zeigt drei übergreifende Erkenntnisse, die über einzelne technische Komponenten hinausgehen.

Erstens wird deutlich, dass die Wahl des Orchestrierungsmodells die Kernentscheidung für die Gesamtarchitektur darstellt. Single-Agent-Systeme bieten Einfachheit, stoßen jedoch bei wachsender Komplexität auf Kontexterschöpfung und Rollenverwirrung. Multi-Agent- und hierarchische Systeme adressieren diese Limitationen durch Spezialisierung und Parallelisierung, führen jedoch neue Herausforderungen in der Koordination und Fehlervermeidung ein. Die Wahl determiniert nicht nur die unmittelbare Implementierungskomplexität, sondern auch operative Anforderungen für produktive Systeme.

Zweitens zeigt sich ein fundamentaler Trade-off zwischen Spezialisierung und Generalisierung bei der Agent-Konzeption: Spezialisierte Agenten erreichen höhere Präzision für definierte Aufgabenklassen, sind jedoch weniger flexibel und nur eingeschränkt auf andere Domänen übertragbar, während generalistische Agenten zwar breiter einsetzbar, aber anfälliger für Fehler und suboptimale Leistung sind [79], [80]. Eine systematische Designmethodologie für diese Balance fehlt bislang in der Literatur.

Drittens wird sichtbar, dass Transparenz und durchgängige Observability eine Infrastruktur-Anforderung für produktionsreife Agentensysteme darstellen [81], [82]. Da Agenten durch nichtdeterministische Reasoning-Prozesse agieren, sind traditionelle Monitoring-Ansätze (Logs, Metriken) unzureichend [81], [83], [84]. Die Nachvollziehbarkeit von Reasoning-Schritten, Tool-Aufrufen und Fehlerfortpflanzung wird zum kritischen Erfolgsfaktor für Debugging, Vertrauensaufbau und kontinuierliche Verbesserung [81], [82], [83]. ​

Offene Forschungsfragen

Trotz der umfassenden Betrachtung der Agent-Architekturen existieren mehrere Forschungslücken, die für praktische Einsätze in der Softwareentwicklung relevant sind.

Verification und Formal Methods für Agent Reasoning

Ein zentrales Problem liegt in der Verifizierbarkeit von agentgenerierten Reasoning-Schritten. Reasoning-Patterns wie Chain-of-Thought oder Tree-of-Thoughts verbessern zwar die Lösungsqualität, machen aber die Anzahl und Komplexität der Zwischenschritte größer, ohne dass diese formal überprüfbar wären [85], [86]. Weder das Modell selbst noch externe Monitoring-Werkzeuge können zuverlässig feststellen, ob eine Reasoning-Kette logisch konsistent und faktisch korrekt ist [87]. Erste Ansätze kombinieren LLMs mit formalen Verifikatoren, etwa Theorem-Provern oder SMT-Solvern, sowie interaktiven Beweissystemen wie Lean4, um natürlichsprachliche Erklärungen oder Code formal zu prüfen [86], [88], [89]. Diese Arbeiten fokussieren jedoch auf eng abgegrenzte Domänen. Für die Code-Generierung durch Agenten – einen Kernanwendungsfall dieser Arbeit – fehlen standardisierte Frameworks zur formalen Verifikation der Agentenausgaben [90]. Eine Forschungsaufgabe liegt in der Entwicklung von Verification-Frameworks, die sowohl die Reasoning-Kette als auch den generierten Code automatisiert auf Korrektheit überprüfen und in bestehende Softwareentwicklungsprozesse integrierbar sind.​

Error Propagation in Multi-Agent-Orchestrierungen

Ein wiederkehrendes Problem bei Multi-Agent-Systemen ist die Fehlerfortpflanzung über mehrere Orchestrierungsphasen hinweg [81], [83]. Besonders bei Sequential-Pattern-Orchestrierungen führt ein Fehler in einer frühen Phase, etwa ein suboptimaler Plan bei Self-Planning, dazu, dass nachfolgende Agenten auf fehlerhaften Prämissen aufbauen und Fehler verstärken, statt sie zu korrigieren [83], [91]. Analysen von Halluzinationen und Fehlverhalten in agentischen Systemen zeigen, dass solche Fehlerketten schwer zu detektieren sind und sich über mehrere Tools und Agenten hinweg fortsetzen können [58], [81]. Spezialisierte Ansätze wie Critic Agents, Validator-Agenten oder kollaborative Verifikationsstrategien verbessern die Robustheit, bleiben aber überwiegend ad-hoc und domänenspezifisch [85], [87]. Eine Forschungsaufgabe liegt in der Entwicklung von Error‑Localization‑ und Bounded‑Propagation‑Strategien, die kritische Fehlerquellen automatisch identifizieren, deren Auswirkung auf nachgelagerte Agenten begrenzen und Fehlermodi systematisch klassifizieren [85].

Observability, Debugging und Root-Cause Analysis

Agentensysteme weisen inhärent undurchsichtige, implizite Reasoning-Prozesse auf [83]. Klassische Observability-Konzepte aus verteilter Software (Logs, Metriken, Traces) erfassen zwar Systemzustände, liefern aber nur begrenzte Einsichten in agentische Denkprozesse, Tool-Nutzung und Halluzinationsmuster [83], [92]. Aktuelle Arbeiten schlagen kognitive Observability-Frameworks, spezialisierte LLM-Observability-Plattformen und Benchmarking-Ansätze vor, die Agentenverhalten detailliert analysieren und visualisieren. Gleichzeitig zeigen Berichte aus der Praxis, dass systematische Evaluation und Root-Cause-Analysen häufig manuell erfolgen und damit zeitaufwändig und fehleranfällig bleiben [83], [92]. Eine Forschungsaufgabe liegt in der Standardisierung von agentenspezifischen Observability-Protokollen, die einheitliche Tracing-, Evaluations- und Debugging-Mechanismen für unterschiedliche Agent-Frameworks und Tool-Landschaften definieren und sich mit bestehenden Monitoring-Stacks integrieren lassen.

Cost Optimization und Token-Effizienz bei Skalierung

Multi-Agent-Systeme konsumieren deutlich mehr Tokens als Single-Agent-Systeme, unter anderem durch zusätzliche Reasoning-Schritte, wiederholte Tool-Aufrufe und wachsende Kontexte [93], [94], [95]. Studien und Erfahrungsberichte zu agentischen Workflows in Cloud-Umgebungen und Unternehmen zeigen, dass ineffiziente Orchestrierung zu erheblichen verdeckten Kosten führen kann, etwa durch redundante Anfragen, unnötige Parallelisierung oder unzureichendes Caching [94], [95]. Pattern-basierte Optimierungen, zum Beispiel Plan-and-Execute-Ansätze mit getrennten Modellen für Planung und Ausführung oder hybride Edge-Cloud-Ressourcenzuweisung, demonstrieren bereits signifikante Einsparpotenziale [93], [96]. Eine offene Forschungsaufgabe besteht darin, kostenbewusste Designwerkzeuge für Agenten zu entwickeln, die Prompting, Memory-Strategien, Modellwahl und Orchestrierung systematisch hinsichtlich vorgegebener Kostenbudgets optimieren.

Legacy-System-Integration bei produktiven Deployments

Schließlich stellt die Integration agentischer Systeme in bestehende Unternehmenslandschaften eine weitere offene Herausforderung dar [80], [97]. Arbeiten zu agentischen Workflows und Enterprise-APIs betonen, dass viele Organisationen über Legacy-Systeme ohne geeignete Schnittstellen für Echtzeit-Zugriff, Transaktionssicherheit oder feingranulare Berechtigungsmodelle verfügen [80], [97]. Gleichzeitig deuten Marktanalysen darauf hin, dass die breite Einführung von Agentic AI in Unternehmen weniger an den Modellen selbst als an fehlender Modernisierung von API-Architekturen, Sicherheitskonzepten und Governance-Strukturen scheitert [80], [98]. Agenten, die Code ausführen oder produktive Systeme steuern, sind jedoch auf robuste APIs, moderne Middleware und konsistentes Identity- und Access-Management angewiesen [97], [99]. Es besteht Forschungsbedarf für Architektur- und Migrationsmuster, die eine sichere und schrittweise Anbindung agentischer Systeme an etablierte Infrastrukturen ermöglichen.

​

Ausblick

Mehrere Entwicklungen werden die Architektur von Agentensystemen in den kommenden Jahren voraussichtlich prägen.

Erstens werden Meta-Agenten und hierarchische Orchestrierungen an Bedeutung gewinnen [100], [101]. Generalistische Multi-Agent-Frameworks [96], [102], Agent-of-Agents-Architekturen [96] sowie hierarchische Kooperationsmuster zeigen sich bereits als skalierbare Lösungen für komplexe Aufgaben, die mit Single-Agent- oder flachen Multi-Agent-Architekturen nur schwer zu bewältigen sind [96], [100], [102]. Dies verschiebt den Schwerpunkt von der Konstruktion einzelner Prompts hin zum Entwurf ganzer Agentenhierarchien und Rollenmodelle [96], [100].

Zweitens werden Observability und Kostenüberwachung zu Plattformfunktionen. AI-Gateways und Observability-Plattformen für LLM- und Agent-Anwendungen etablieren sich als zentrale Infrastrukturkomponenten, die Routing, Policy-Enforcement und Monitoring bündeln. Observability wird damit nicht länger als optionales Diagnosewerkzeug, sondern als integraler Bestandteil von Governance- und Compliance-Anforderungen verstanden [81], [84], [94], [99].

Drittens verändern spezialisierte Reasoning-Modelle die Orchestrierungslogik. Leistungsfähige, aber kostspielige Reasoning-Modelle mit expliziter Darstellung von Denkpfaden werden zunehmend mit leichteren Modellen kombiniert, die einzelne Ausführungsschritte übernehmen. Solche hybriden Strategien, bei denen Frontier-Modelle die Planung und kleinere Modelle die Ausführung übernehmen, werden in Analysen zu Performance- und Kostenoptimierung als vielversprechend bewertet [93], [96], [103], [104].

Viertens zeichnet sich ab, dass Human-in-the-Loop mit klar definierter Governance ein zentraler Erfolgsfaktor bleibt [98], [105]. Position Papers zu Risiken vollautonomer Agenten sowie Arbeiten zu Guardrails, Governance-Frameworks und Organisationsstrategien betonen, dass gezielt gestaltete menschliche Eingriffspunkte entlang des Softwareentwicklungsprozesses essenziell für Sicherheit, Vertrauen und regulatorische Konformität sind. Anstatt vollständig autonome Systeme anzustreben, etablieren sich Konfigurationen, in denen Autonomiegrade bewusst variiert und an definierten Entscheidungspunkten durch Menschen übersteuert oder validiert werden. Organisationen, die solche Entscheidungsstrukturen, Rollen und Kontrollmechanismen frühzeitig etablieren, schaffen damit die Grundlage für den sicheren und effizienten Einsatz agentischer Systeme in der Softwareentwicklung [80], [85], [98], [99], [101], [106], [107], [108], [109].