Agentenreifemodell: Mensch im Kontrollkreislauf, Harness Engineering, Orchestrierung
Fünf Stufen der Agentenreife, die in der Produktion getestet werden: menschliche Überwachung im Kontrollkreislauf, Harness Engineering, Multi-Agent-Orchestrierung sowie noch ungelöste Probleme.
Quellen: Agentic Architectures — Article 15: The Maturity Model Revisited
Ein Reifemodell für Agenten ist einfach zu zeichnen, aber schwer in der Praxis umzusetzen. Auf dem Papier sieht es ordentlich aus: eine Leiter, die mit einfachen Tool-Aufrufern beginnt und in selbstverbessernden Produktionsystemen endet. Frameworks wirken immer ordentlich, bevor jemand versucht, sie unter Last zu betreiben. Sobald echter Code dahintersteckt, wirkt dasselbe Modell anders. Es war nicht falsch, aber etwas theoretisch zu kennen und es in der Produktion anzuwenden, sind unterschiedliche Arten des Wissens. Eine Karte kann einem nicht sagen, wie die Straße um drei Uhr morgens ist, wenn ein Schalter nicht schließt und man selbst im Bereitschaftsdienst ist.
Das ist ein Rückblick auf dieses Modell, nachdem die dahinterliegenden Schichten tatsächlich erstellt wurden: Wie die Ebenen mit der Ingenieurarbeit übereinstimmen, welche Annahmen dem Kontakt mit der Produktion nicht standhielten, wie eine gestapelte Referenzarchitektur aussieht und was noch ungelöst ist. Der Code ist hier minimal. Ziel ist es, einen Schritt zurückzutreten und die gesamte Architektur zu überblicken.
Fünf Ebenen, jede auf der vorherigen aufbauend
Das Reifemodell beschreibt fünf Ebenen der Fähigkeiten von Agenten. Jede Ebene ist mehr als nur eine verbesserte Version der darunterliegenden, denn sie hängt auch von allem darunter ab. Man kann keine Schritte überspringen. Ein Agent kann ohne Bewertungsinfrastruktur nicht zuverlässig autonom sein, und er kann sich ohne Speicher nicht selbst verbessern. Die Ebenen wirken sich gegenseitig verstärkend aus.
So entsprechen die ingenieurtechnischen Themen diesen Ebenen:
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
Die Form ist wichtiger als die Zuordnung. Ebene 5, die Selbstverbesserung, weist keinen speziellen Bestandteil auf, weil es sich nicht um etwas handelt, das man direkt aufbaut. Sie entsteht, wenn Gedächtnis und Bewertung zusammenwirken – selbst dann ist das Feld noch nicht vollständig vorhanden. Der Gipfel des Modells ist weiterhin teilweise nur ein Ziel, das angestrebt wird. Die Selbstverbesserung kann heute annähernd erreicht werden, aber nicht vollständig umgesetzt.
Das war bei der ersten Skizzierung des Modells nicht offensichtlich. Ebene 5 sah aus wie ein Ziel, das man durch das Zusammenfügen der richtigen Komponenten erreicht. In der Praxis verhält sie sich eher wie ein Horizont, der sich entfernt, je näher man ihm kommt.
Überzeugungen, die durch die Produktion korrigiert wurden – von Mensch im Prozess bis zur Orchestrierung
Das ist der Teil, den ein Rahmendokument niemals erfassen kann, denn er entsteht nur durch das Aufbauen. Mehrere frühe Annahmen erwiesen sich als falsch oder zumindest unvollständig.
Das Gedächtnis wurde stark unterschätzt. Im ersten Entwurf galt das Gedächtnis lediglich als eine weitere Funktion, die den Eindruck einer kontinuierlichen Interaktion zwischen Agenten erweckte. Die Entwicklung zeigte jedoch, dass das Gedächtnis eine Infrastruktur darstellt – mit all dem, was dieser Begriff beinhaltet: Schema-Design, Qualität der Abrufung, Verfallsregeln sowie Isolierung der Nutzer. Eine noch unangenehmere Erkenntnis folgte: Selbst die Infrastrukturen, die wir zu bauen wissen, sind nicht ganz die richtige Abstraktion. Teams passen Datenbanken an, die ursprünglich für andere Zwecke konzipiert wurden, weil es keine speziell dafür entwickelten Lösungen gibt. Das Gedächtnis war das am meisten unterschätzte Element im ursprünglichen Modell.
Das Ziel ist Vorhersehbarkeit, und Autonomie ist sekundär. Das ist der tiefste Wandel. Früher wurde der Fortschritt daran gemessen, wie viel ein Agent ohne menschliche Hilfe leisten konnte – daher wirkte jede zusätzliche Unabhängigkeit wie ein Fortschritt. Doch ein Agent, der allein, aber unvorhersehbar handelt, verursacht einfach früher Schaden. In jeder ernsthaften Anwendung erwies sich Zuverlässigkeit unter Aufsicht als wichtiger als reine Unabhängigkeit. Ein anschauliches Versagen betraf einen Agenten, der autonom Dutzende von duplizierten Tickets erstellte. Was Produktionsysteme benötigen, ist die richtige Menge an Autonomie: begrenzt, überprüfbar und vorhersehbar, wobei Menschen die Entscheidungen treffen, deren Kosten menschliche Aufmerksamkeit verdienen. Ein Leser argumentierte einmal, dass Orchestrierung auf Vorhersehbarkeit und nicht auf Autonomie ausgerichtet sein sollte – diesen Punkt musste man lange Zeit nicht akzeptieren.
Sicherheit ist eine Eigenschaft jeder Schicht. Der ursprüngliche Plan betrachtete die Sicherheit als ein Thema am Ende, etwas, das erst hinzugefügt wurde, nachdem das System funktionierte. Prompt-Injection korrigiert das. Ihre Ziele liegen anderswo: der Punkt, an dem Tools aufgerufen werden, der Weg, über den Erinnerungen geschrieben werden, die Art und Weise, wie Ziele geändert werden, sowie der Datenverkehr zwischen Agenten. Jeder Komponente kommt eine Sicherheitsdimension zu. Authentifizierung an der Grenze der Tools, Isolierung in der Speicherung sowie Kontrollen bei der Änderung von Zielen sind alles Aspekte der Sicherheit, die sich im gesamten System verteilen und nicht in einer einzigen Ebene konzentriert sind.
Der Loop steht über dem Prompt. Diese Lektion kam zuletzt und wäre zuerst nützlicher gewesen. Ein großer Teil der Anstrengungen in diesem Bereich galt der Prompt-Engineering-Technik sowie der Suche nach perfekten Formulierungen. Doch ein Agent ist kein Prompt – er ist ein Loop, der über mehrere Schritte hinweg ein Ziel verfolgt. Ein perfekter Prompt innerhalb eines fehlerhaften Loops ergibt zwar einen eloquenten Agenten, der jedoch niemals sein Ziel erreicht. Wenn man in Begriffen von Loops denkt, erweisen sich viele Probleme, die ursprünglich wie Einschränkungen des Modells aussahen, als Fehler im Loop-Design.
Ein Mensch im Prozess ist kein Fehler, den man durch Ingenieurskunst beseitigen kann. Es ist verlockend anzunehmen, dass die Beteiligung von Menschen nur eine vorübergehende Lösung ist, die mit der Weiterentwicklung der Technologie entfernt werden muss. Die besten Produktionsagentensysteme sind nicht die autonomesten. Sie setzen menschliches Urteilsvermögen genau dort ein, wo es benötigt wird – und nirgendwo sonst. Menschliche Überwachung ist kein Stadium, das man hinter sich lassen muss. Sie ist eine bewusste, dauerhafte Eigenschaft jedes Systems, dessen Fehler echte Kosten verursachen.
Der gesamte Stack in einem Bild
Wenn man alles oben Genannte zusammenfasst, sieht ein ausgereiftes Agentensystem so aus:
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Die vertikalen Schichten bilden den Anfragenpfad. Eine Aufgabe gelangt durch menschliche Überwachung hinein, wird durch Ziele und Schleifen geformt, zwischen Agenten koordiniert, durch das Framework verfeinert und schließlich gegen das Modell ausgeführt. Bedenken, die alle Ebenen betreffen, erreichen jede Schicht. Das Speicherystem liefert sowohl die Schleifen als auch das Framework. Die Sicherheit schützt die Grenzen der Tools sowie die Überprüfung der Ziele. Die Kosten bestimmen die Modellroute bei jedem Schritt. Die Bereitstellung umfasst alles zusammen.
Der schrittweise Überblick verdeckt, wie eng diese Komponenten miteinander verbunden sind. Eine Veränderung in einem Bereich wirkt sich auf die anderen aus. Man kann die Kosten nicht optimieren, ohne die Schleifen zu verstehen, da ein teurer Ausführungsprozess oft auf einer nicht endenden Schleife beruht. Auch die Sicherheit erfordert ein solches Bewusstsein für das Speichermanagement, da eine beschädigte Eintragung lange Zeit weiterhin Probleme verursacht. Betrachten Sie die Schichten als ein miteinander verflochtenes Ganzes und nicht als eine Reihe separater Module.
Was noch niemand gelöst hat
Das könnte der nützlichste Abschnitt sein, denn alles, was oben beschrieben wird, bezieht sich auf das, was bereits gebaut werden kann, während hier beschrieben wird, was bisher noch nicht möglich ist. Eine ehrliche Darstellung der Grenzen ist wertvoller als eine glatt polierte.
Eine wirklich agentenbasierte Speichertechnologie existiert nicht. Die heutigen Speichersysteme bestehen aus Datenbanken und Vektorlagern, die für andere Zwecke entwickelt wurden. Ein echtes, agentenbasiertes System, das Zeit verfolgt, über Assoziationen Informationen abruft, absichtlich vergisst und es dem Agenten überlässt, zu entscheiden, was gespeichert werden soll, ist nach einigen Schätzungen noch einige Jahre entfernt. Was es gibt, funktioniert – es ist aber nicht das, was benötigt wird.
Agenten können nicht zuverlässig erkennen, wann ihr Wissen anwendbar ist. Das ist die tiefere Form des Problems der veralteten Erinnerung. Ein Agent kann ein relevantes Verfahren abrufen und es zuversichtlich auf einen Fall anwenden, in dem es nicht passt, weil schwer zu definieren ist, ab wann ein Wissensbestandteil nicht mehr gültig ist – und noch schwieriger, dies bei der Abrufung zu überprüfen. Ein Verfahren, das in einem Rechtsgebiet funktioniert, wird in einem anderen falsch angewandt, ohne dass weder der Agent noch oft der Benutzer es bemerkt. Das ist eine grundlegende Einschränkung und nicht lediglich ein technisches Defizit.
Die Selbsteinschätzung ist unzuverlässig. Sowohl die Eskalationslogik als auch die Zuverlässigkeitsbewertung setzen voraus, dass ein Agent seine eigene Gewissheit genau beurteilen kann. Manchmal gelingt ihm das, manchmal irrt er jedoch, obwohl er sich sicher anhört – was der schädlichste Fall ist, da dadurch alle Schutzmechanismen wirkungslos werden, die davon abhängen, dass der Agent seine Grenzen erkennt. Bislang gibt es keine zuverlässige Lösung für kalibrierte Selbsteinschätzungen.
„Harnesses“ werden nicht zwischen Modellen übertragen. Jeder „Harness“ ist auf das Verhalten eines bestimmten Modells abgestimmt. Wechselt man das Modell, müssen Anweisungen, Schwellenwerte für die Loop-Erkennung sowie Überprüfungskriterien neu angepasst werden. Im Prinzip müsste es nicht so sein, doch bisher hat niemand eine Abstraktion für „Harnesses“ entwickelt, die einen Modellwechsel ohne Anpassung übersteht. Ein Modell-Upgrade bleibt somit ein Projekt und keine Konfigurationsänderung.
Es gibt kein echtes kontinuierliches Lernen. Prozedurales Gedächtnis simuliert Lernen: Erfolgreiche Ansätze werden gespeichert und wiederverwendet. Doch die Gewichte ändern sich nicht und das Agent entwickelt keine neuen Fähigkeiten aus Erfahrungen. Es erstellt eine Bibliothek vergangener Lösungen und zieht daraus ab. Ein Agent, das sich durch Erfahrung tatsächlich bei einer Problemklasse verbessert, ist etwas, was Produktionsysteme heute noch nicht leisten können.
Die Kosten sind am Rande unvorhersehbar. Es existieren Tools zur Kostenverwaltung, und sie funktionieren, doch der „Schwanz“ der Verteilung ist hartnäckig. Ein kleiner Anteil an Ausführungen – jene, die auf pathologische Schleifen oder ungewöhnliche Randfälle stoßen – verbraucht weiterhin unverhältnismäßig viele Ressourcen auf Weise, die schwer vorherzusagen ist. Man kann diesen Verbrauch begrenzen, kann ihn aber nicht immer vorhersagen.
Nichts davon ist ein Grund, zurückhaltend zu sein. Das sind die Ränder der aktuellen Karte – und das Wissen darüber, wo sie liegen, ist es, was Ingenieurwesen von bloßer Wunschdenkerei unterscheidet.
Wo anzufangen: Zuerst das Ingenieurwesen nutzen, bevor man Agenten orchestriert
Falls Sie ein Agentensystem entwickeln, sollten Sie die Themen nicht als Aufbauschritt betrachten. Sie sind nach Konzepten, nicht nach der Konstruktionsreihenfolge gruppiert. Bauen Sie in dieser Reihenfolge, und Sie schaffen erst Speicher, bevor es ein System gibt, das ihn nutzen kann, sowie erst Bewertungsmöglichkeiten, bevor es etwas gibt, das bewertet werden kann.
Beginnen Sie dort, wo Ihr System auf der Reifegradleiter steht.
- Ein grundlegender Agent, der Werkzeuge aufruft und unzuverlässig ist, sollte mit der Entwicklung solcher Hilfssysteme beginnen – schließlich liegen dort die meisten Zuverlässigkeitsprobleme.
- Ein solider Einzelagent, der an seine Grenzen gestoßen ist, ist bereit für die Orchestrierung mehrerer Agenten.
Tools sind austauschbar, Ideen nicht
Die Beispiele hinter dieser Diskussion basierten auf AWS Bedrock, LangGraph und LangChain. Das waren praktische Entscheidungen, getroffen, weil es sich um die im Produktivbetrieb verwendete Technologiestack handelte – und es sind nicht die einzigen möglichen Lösungen. Der größte Teil dessen, was wichtig ist, hängt nicht davon ab. Die Authentifizierung muss an der Grenze des Tools in jeder Cloud erfolgen. Im Rahmen jedes Frameworks ist der Algorithmuszyklus wichtiger als die Eingabeanweisung. Die Ebenen des Speichers, die Muster der Multi-Agenten-Koordination, die Kategorien von Angriffen sowie die Matrix zur Abwägung von Umkehrbarkeit und Kosten für die menschliche Überwachung lassen sich auf andere Technologiestacks übertragen.
Deshalb lohnt es sich auch, eine lokale Alternative mit Ollama und Docker zu haben. Dadurch lassen sich die Muster ohne Cloud-Kosten ausführen, und es wird bewiesen, dass die Konzepte von der Implementierung getrennt sein können. Wenn eine Speicherverwaltung mit einem lokalen Modell sowie einem lokalen Vektorlager arbeitet, dann verdankt das Design ursprünglich nichts Bedrock. Es wurde vielmehr das zugrundeliegende Problem erfasst, das auf jeder Plattform ähnlich aussieht. Dasselbe gilt für die Orchestrierungsmuster – der Austausch von LangGraph gegen ein anderes Framework ändert zwar die Syntax der Schleifen, nicht aber die Fehlerarten, mit denen man umgehen muss. Ebenso verhält es sich mit den Evaluierungswerkzeugen, die auf jedes dahinterliegende Modell ausgerichtet werden können.
Was das Aufschreiben aufgezeigt hat
Ein Thema klar und geordnet jemandem zu erklären, der nicht dabei war, als man es gelernt hat, zeigt die Lücken im eigenen Verständnis auf. Viele Themen scheinen erst dann wirklich beherrscht zu sein, wenn man versucht, sie aufzuschreiben.
Der ehrliche Zustand dieses Gebiets ist, dass es zugleich aufregend und unreif ist. Heute sind Dinge möglich, die vor zwei Jahren noch nicht möglich waren, und es ist leicht, sich selbst zu täuschen, denn fließende Darstellungen wirken fähiger, als sie tatsächlich sind. Der Unterschied zwischen einem Agenten, der gut demonstriert werden kann, und einem, der zuverlässig in der Produktion funktioniert, ist enorm – und der größte Teil der schwierigen Ingenieurarbeit liegt genau in diesem Unterschied.
Falls es eine Botschaft gibt, die man an den Anfang zurücksenden sollte, dann ist es die, dass die spannende Arbeit nicht darin besteht, KI-Systeme mächtiger zu machen. Modelle sind bereits mächtig und verbessern sich weiter nach einem Zeitplan, den man nicht kontrollieren kann. Die wirklich interessante Aufgabe besteht darin, mächtige Modelle zuverlässig, vorhersehbar, sicher und kostengünstig genug zu machen, damit man ihnen echte Entscheidungen anvertrauen kann. Das ist Ingenieurskunst – keine Magie: Steuerungen, Schleifen, Speicher, Bewertungen sowie alle anderen weniger spektakulären Infrastrukturelemente, die ein leistungsfähiges Modell in etwas verwandeln, dem man vertrauen kann.
Die Intelligenz stammt vom Modell. Die Architektur muss man hingegen selbst entwickeln.
Verwandte Artikel
- Praktische Hinweise: Agentic Architectures, Artikel 12: Sind wir bereit für An: Detaillierte Anleitung zu den Praktischen Hinweisen: Agentic Architectures, Artikel 12: Sind wir bereit für An – einschließlich Verträgen, Überprüfungen sowie Code-Blöcken, die Teams nutzen können, die dieses Muster implementieren.
- Mensch im Kreislauf für KI-Agenten: Genehmigungsmechanismen, Eskalation, Audit-Protokolle: Wenn ein Agent die Zustimmung eines Menschen benötigt, werden vier Muster vorgestellt (Genehmigungsmechanismen, Eskalation, gemeinsame Bearbeitungen, Stichproben), Möglichkeiten zum Anhalten und Wiederaufnehmen mit LangGraph, Zeitlimits, Audit-Logs sowie häufige Fehlerquellen.